Реальный случай из технического SEO-аудита: сайт работал через Wi-Fi и VPN, но не открывался у части пользователей мобильного интернета. Причина оказалась на уровне TCP и MTU.
При техническом SEO-аудите обычно проверяют скорость загрузки сайта, SSL-сертификат, DNS, robots.txt и другие стандартные параметры. Но иногда проблема находится значительно глубже и остаётся незаметной даже для опытных специалистов.
Именно такой случай был выявлен во время технической проверки одного из коммерческих проектов. Сайт исправно работал на компьютерах, открывался через Wi-Fi, успешно проходил проверки сервисов мониторинга, однако часть пользователей мобильного интернета вообще не могла открыть страницы сайта.
Как проявлялась проблема
Первые жалобы поступили от пользователей iPhone. При открытии сайта через мобильный интернет Safari бесконечно ожидал ответ сервера или сообщал, что сервер недоступен.
При этом одновременно наблюдалась довольно необычная картина:
- сайт без проблем открывался с компьютеров;
- корректно работал через Wi-Fi;
- моментально открывался при использовании VPN;
- успешно проходил проверки внешних сервисов мониторинга;
- SSL-сертификат был действительным;
- сервер отвечал без ошибок.
На первый взгляд всё выглядело так, словно проблема находится на стороне мобильного оператора или конкретного устройства пользователя.
Почему стандартная диагностика не помогла
В ходе проверки были последовательно исключены практически все наиболее распространённые причины подобных ошибок:
- DNS-записи;
- SSL-сертификаты;
- настройки Nginx;
- редиректы HTTP → HTTPS;
- iptables и UFW;
- ограничения ISPmanager;
- работа Apache и PHP;
- ответы сервера через curl;
- логи веб-сервера.
Ни одна из этих проверок не показала очевидной причины недоступности сайта.
Что удалось обнаружить
После более глубокой диагностики выяснилось, что проблема находилась значительно ниже уровня веб-сервера.
Часть мобильных сетей некорректно обрабатывала передачу TCP-пакетов определённого размера, из-за чего соединение зависало ещё до получения первой страницы сайта.
Именно этим объяснялось странное поведение:
- через VPN сайт открывался;
- через домашний интернет также работал;
- у одних мобильных операторов проблема отсутствовала;
- у других пользователей сайт вообще не загружался.
Что было сделано
Для проверки гипотезы была включена функция автоматического определения оптимального размера TCP-пакетов:
net.ipv4.tcp_mtu_probing = 1
После применения настройки сайт начал корректно открываться на устройствах, где ранее соединение зависало ещё до загрузки первой страницы.
Дополнительно были проверены:
- поддержка HTTP/2;
- настройки TLS 1.2 и TLS 1.3;
- работа SSL;
- HTTP-редиректы;
- доступность сайта по IP-адресу;
- ответы сервера и журналы ошибок.
Почему это может быть критично для SEO
Представим обычную ситуацию.
Пользователь вводит запрос в поисковой системе, находит ваш сайт, переходит по ссылке... и страница не открывается.
В этот момент большинство посетителей не будут выяснять, связано ли это с мобильным оператором, особенностями сети или настройками сервера. Для пользователя всё выглядит одинаково — сайт просто не работает.
Фактически это один из самых неблагоприятных сценариев для любого коммерческого проекта: вы уже получили переход из поисковой системы, но из-за технической проблемы пользователь даже не увидел содержимое страницы и практически сразу ушёл обратно в поиск, где откроет сайт конкурента.
Для владельца сайта это означает сразу несколько негативных последствий:
- потерю потенциального клиента;
- снижение количества заявок и продаж;
- потерю рекламного бюджета при переходах из контекстной рекламы;
- рост числа быстрых отказов;
- ухудшение пользовательского опыта.
Хотя поисковые системы не публикуют информации о влиянии подобных сетевых проблем непосредственно на ранжирование, доступность сайта является одним из базовых требований качественного веб-ресурса. Если часть пользователей регулярно не может открыть страницы сайта, это неизбежно отражается на эффективности поискового продвижения и общей конверсии проекта.
Как проверить подобную проблему
Самое сложное заключается в том, что большинство сервисов мониторинга покажут, что сайт полностью работоспособен.
Поэтому рекомендуется дополнительно проверить:
- открытие сайта через разных мобильных операторов;
- работу через VPN и без VPN;
- доступность сайта на iPhone и Android;
- ответы сервера по HTTPS;
- настройки MTU;
- TCP-параметры операционной системы;
- поддержку HTTP/3 и HTTP/2;
- логи веб-сервера.
Обновление: проблема повторилась на другом сервере
В сентябре 2026 года мы второй раз столкнулись практически с такой же проблемой — на этот раз уже при переносе собственного сайта PrimLead на новый VPS.
После переноса сайт и сервер в целом работали корректно: страницы открывались с компьютеров и через обычное интернет-соединение, DNS и SSL были настроены, веб-сервер отвечал без ошибок. Однако при проверке через мобильный интернет снова проявилась проблема с доступностью сайта.
Ситуация оказалась очень похожа на случай, описанный выше. Поэтому одной из первых серверных настроек, которую мы проверили, стал TCP MTU Probing:
sysctl net.ipv4.tcp_mtu_probing
Для корректной работы в нашем случае использовалось значение:
net.ipv4.tcp_mtu_probing = 1
После применения этой настройки проблема с открытием сайта через мобильные сети была устранена.
Почему второй случай особенно интересен
Это уже второй независимый проект, на котором мы столкнулись с одинаковым поведением: сайт работает через Wi-Fi и обычные проводные подключения, но у части пользователей возникают проблемы именно через мобильную сеть.
В обоих случаях сайты размещались на VPS инфраструктуре FirstVDS, а проблема устранялась включением net.ipv4.tcp_mtu_probing = 1.
Сам по себе этот факт не означает, что причина находится непосредственно на стороне хостинг-провайдера. На прохождение TCP-трафика влияют маршрутизация, настройки сети, мобильный оператор, промежуточное сетевое оборудование и параметры операционной системы сервера. Однако после второго аналогичного случая мы считаем проверку TCP MTU Probing обязательным этапом диагностики, если сайт на VPS открывается через Wi-Fi, но нестабильно работает через мобильный интернет.
Что стоит проверить в первую очередь
Если после переноса сайта на новый сервер появляется похожая ситуация, необязательно сразу искать проблему в CMS, PHP или базе данных. Сначала имеет смысл сравнить доступность сайта через Wi-Fi, мобильную сеть и VPN, а затем проверить системную настройку:
sysctl net.ipv4.tcp_mtu_probing
Если значение равно 0, для диагностики проблемы можно временно включить TCP MTU Probing:
sysctl -w net.ipv4.tcp_mtu_probing=1
Если после этого сайт начинает стабильно открываться через мобильную сеть, настройку можно сохранить в конфигурации Linux, чтобы она не сбрасывалась после перезагрузки сервера.
Обновлено 8 сентября 2026 года. После второго аналогичного случая мы дополнили статью практическими результатами повторной диагностики. Это хороший пример того, почему проверять доступность сайта необходимо не только через серверные сервисы и Wi-Fi, но и через реальные мобильные сети.
Вывод
Проблемы доступности сайта далеко не всегда связаны с CMS, DNS или SSL-сертификатами. Иногда причина скрывается на уровне сетевого взаимодействия между сервером и мобильными операторами, поэтому обнаружить её стандартными средствами практически невозможно.
В нашем случае последовательная техническая диагностика позволила выявить проблему, которая оставалась незаметной при обычных проверках, и восстановить корректную работу сайта для пользователей мобильного интернета.
Этот кейс ещё раз показывает, что техническое SEO — это значительно больше, чем оптимизация метатегов и скорости загрузки страниц. Даже одна системная настройка сервера способна устранить проблему, которая напрямую влияет на доступность сайта, пользовательский опыт, количество обращений и, как следствие, общую эффективность поискового продвижения.