Почему сайт недоступен с мобильного, хотя сервер работает? Реальный кейс
Диагностика проблем с доступом к сайту: от Wi-Fi до мобильного интернета
Представьте: ваш сайт работает как часы, вы проверяете его с ноутбука - всё идеально. Но стоит переключиться на мобильный интернет, как начинается кошмар. Сайт не открывается, SSH отваливается, а скачивание файлов превращается в лотерею. Знакомо?
В этой статье я расскажу, как провести диагностику проблем с доступом к сайту без магии и шаманства. Только терминал, MTR и немного логики. Вы узнаете, как отличить проблемы на сервере от проблем провайдера, как читать отчёты MTR и что делать, если сайт не открывается с телефона, но работает по Wi-Fi.
Меня зовут Александр, я ведущий разработчик с 8-летним опытом. За моими плечами - сотни диагностик, и этот кейс один из самых показательных. Если у вас потеря пакетов на мобильном интернете, то эта статья сэкономит вам часы нервов.
С чего всё началось: проблема, которую я не мог объяснить
У меня был стабильный доступ к серверу и сайту через домашний Wi‑Fi: всё грузилось мгновенно, соединения не рвались, ни одной ошибки в логах. Но стоило переключиться на мобильный интернет - и начинался ад. Сайт не открывается, SSH-сессия рвётся через 30 секунд, а скачивание файлов превращается в лотерею с бесконечными таймаутами.
Первая мысль - «что-то сломал на сервере». Вторая - «надо сменить IP». Третья - «может, TLS поправить?». Я прошёл весь этот путь, перепробовал все стандартные советы из интернета и понял: стандартные методы не работают. Нужен системный подход.
Что такое MTR и зачем он нужен для диагностики сети
MTR (My Traceroute) - это утилита, которая объединяет функциональность traceroute и ping. Она показывает маршрут пакетов до целевого сервера (каждый промежуточный узел или «хоп») и одновременно считает процент потерь пакетов и задержку на каждом шаге.
Это идеальный инструмент для диагностики проблем с доступом к сайту, потому что он позволяет:
Увидеть, на каком именно участке сети теряются пакеты.
Отличить проблемы на стороне клиента от проблем на стороне сервера.
Собрать объективные данные для разговора с техподдержкой.
Если у вас сайт не грузится с телефона, MTR покажет, где обрывается соединение - на первых хопах (ваш мобильный оператор) или ближе к серверу (проблемы хостинга).
Как установить MTR на macOS и Linux (пошаговая инструкция)
До этой истории у меня не было MTR под рукой - пришлось ставить и разбираться. Ниже - подробный гайд для обеих операционных систем.
Установка MTR на macOS
На Mac MTR нет «из коробки». Используйте Homebrew - это пакетный менеджер для macOS.
Шаг 1. Проверьте, установлен ли Homebrew:
brew --versionЕсли вывелась версия - переходите к шагу 2. Если ошибка - установите Homebrew по инструкции с официального сайта.
Шаг 2. Установите MTR:
brew install mtrШаг 3. Проверьте, что всё работает:
mtr --versionВажно! На macOS MTR требует root-прав. Запускайте через sudo:
sudo mtr ваш_IPВыход из интерактивного режима - клавиша q или Ctrl+C.
Установка MTR на сервере (Linux)
В зависимости от дистрибутива:
Debian / Ubuntu:
sudo apt update
sudo apt install mtr-tiny(На этих системах ставят mtr-tiny - версия без GUI, идеальна для сервера.)
CentOS / RHEL / AlmaLinux:
sudo yum install mtrПроверка установки:
mtr --versionКак запустить MTR и правильно прочитать отчёт
Команда для трассировки
Я делал замеры из трёх точек:
С мобильного интернета.
С домашнего Wi-Fi.
Со стороны хостера (попросил их запустить MTR до моего IP).
Пример команды с сохранением отчёта:
sudo mtr -c 20 -r ваш_IP > ~/Downloads/mtr_report.txtРазбор параметров:
-c 20 - отправить 20 пакетов на каждый хоп.
-r - режим отчёта (не интерактивный, сразу выдаёт текст).
> - сохраняет результат в файл.
Что смотреть в отчёте MTR
В логе MTR три ключевых показателя:
Показатель | Что означает | Что делать |
|---|---|---|
Loss% | Процент потерь на каждом хопе | Если потери начинаются с первых хопов - проблема у клиента. Если ближе к концу - на стороне магистралей/хостинга. |
Avg/Best/Worst | Средняя, минимальная и максимальная задержка | Большой разброс (Worst значительно больше Avg) - это джиттер. Он убивает TCP-соединения. |
Last hop | Последний хоп = целевой IP | Если маршрут обрывается раньше - пакеты не доходят до сервера. |
Что я увидел в своём случае:
На Wi‑Fi: Loss% = 0% на всех хопах.
На мобильном: стабильно 70–72% потерь начиная с 3-го хопа.
У хостера до моего IP: Loss% = 0%.
Три точки наблюдения дали однозначную картину: сервер в порядке, проблема на участке мобильного оператора.
Почему стандартные советы не работают: смена IP и TLS
Хостер честно пытался помочь. Сначала предложили сменить IP. Потом - поменять версию TLS в Nginx. Я вежливо, но настойчиво объяснял: смена IP и TLS не лечат потери пакетов на мобильном интернете. Это как лечить головную боль через смену обоев в комнате - не связано.
Чтобы не спорить впустую, я собрал три независимых доказательства:
Мой MTR через Wi‑Fi: 0% потерь, сайт доступен.
Мой MTR через мобильный: стабильно 70–72% потерь.
MTR от хостера: 0% потерь до моего IP, маршрут стабилен.
Это и стало основой для разговора с техподдержкой оператора.
Ключевой эксперимент: проверка из другого региона
Самое важное открытие пришло, когда я проверил доступ к сайту с мобильного в другом регионе. Там сайт открывался стабильно. Это был решающий аргумент: если в одном районе с мобильного сайт не грузится, а в другом - работает, значит, проблема локальная.
Дальше пазл сложился окончательно. Я сопоставил это с тем, как ведут себя операторы при ограничениях мобильного интернета. Часто включается режим «белого списка» - разрешены только отдельные ресурсы (Госуслуги, банки, крупные соцсети), а весь остальной трафик режется на уровне DPI.
Отсюда и потери пакетов: пакеты уходят от вашего устройства, доходят до оператора, но он их просто не пропускает дальше.
Как это проверить без MTR
Если у вас нет доступа к терминалу, используйте простые тесты:
**1. Сравнение curl на Wi-Fi и мобильном:**
curl -I example.comНа Wi-Fi - сразу возвращает заголовки.
На мобильном - висит и падает по таймауту.
2. Проверка «белых» сайтов:
Откройте Госуслуги, Яндекс, Сбербанк. Если они грузятся, а ваш сайт - нет, это сильный маркер фильтрации.
3. Логи сервера (если есть доступ):
Смотрите коды ответов для мобильных User‑Agent’ов. Много 499 (клиент закрыл соединение) и 504 (шлюз не дождался ответа) - типичные следы плохого мобильного канала.
Быстрый способ посмотреть статистику кодов:
grep -i "mobile" access.log | awk '{print $9}' | sort | uniq -c | sort -rnЧто делать пользователям: практические рекомендации
Для проектов, где часть аудитории сидит с мобильного, это важная деталь: часть пользователей в отдельных районах может сталкиваться с недоступностью не из‑за ошибок на сайте, а из‑за фильтрации оператора. Никакие настройки сервера тут не помогут.
Что реально можно сделать:
Для себя (администратора) | Для пользователей |
|---|---|
Использовать Wi-Fi для критичных задач | Добавить на сайт баннер: «Если сайт не грузится с мобильного - попробуйте Wi‑Fi» |
Иметь вторую SIM-карту другого оператора для проверки | Использовать VPN (обход фильтрации) |
Собрать доказательства и отправить в поддержку оператора | Проверить сайт в другом регионе |
Как правильно общаться с техподдержкой (готовый шаблон)
За годы работы с серверами я понял: техподдержка быстрее помогает, когда ты даёшь не эмоции, а данные. Вот как я сформулировал финальный запрос оператору (этот шаблон можно скопировать и адаптировать):
Тема: Проблемы с доступом к сайту через мобильный интернет в [город/район]
Описание проблемы:
У меня проблема с доступом к сайту [URL] через мобильный интернет в районе [название]. При этом:
В другом регионе (например, [город]) с мобильного интернета сайт открывается стабильно.
У меня с мобильного - не открывается, MTR показывает 70–72% потерь, curl уходит в таймаут.
С Wi‑Fi (в том же месте) сайт открывается, потерь 0%, пинг стабильный.
Это указывает на проблему на участке вашей сети в моём районе либо на включение фильтрации/ограничений.
Прошу проверить:
Состояние базовой станции в моём районе.
Наличие ограничений/фильтрации для моего номера или района.
Нет ли аварии или шейпинга на транзитном участке.
При необходимости могу прислать логи MTR и результаты замеров.
Такой текст сразу отсекает шаблонные советы и переводит разговор на уровень инженеров.
Часто задаваемые вопросы (FAQ)
1. Что делать, если MTR показывает потери на последнем хопе?
Если потери видны только на финальном IP (вашем сервере), а на предыдущих хопах всё чисто - проблема на стороне хостинга. Пишите в поддержку хостера с приложенным MTR-отчётом.
2. Может ли антивирус или брандмауэр вызывать потери пакетов?
Да. Некоторые антивирусы с функцией «защиты сети» могут резать трафик. Отключите их на время диагностики, чтобы проверить.
3. VPN помогает при потерях пакетов у оператора?
Часто да. VPN шифрует трафик, и оператор не видит, на какой сайт вы идёте. Это обходит DPI-фильтрацию. Если с VPN сайт открывается - это почти 100% фильтрация.
4. Как часто операторы включают фильтрацию?
Всё чаще. Особенно в густонаселённых районах, на крупных событиях или при тестировании новых систем фильтрации. Это не всегда злой умысел, часто - технические ограничения.
5. Может ли проблема быть в DNS?
Если сайт не открывается с мобильного, но открывается по Wi-Fi - DNS здесь ни при чём. DNS не зависит от типа подключения. Но для чистоты эксперимента можно проверить: nslookup example.com на обоих подключениях. Если IP одинаковый - DNS не виноват.
6. Что такое «джиттер» и почему он убивает SSH?
Джиттер - это разброс задержки. Если пакеты приходят то за 10 мс, то за 500 мс, TCP-соединение начинает «дергаться» и сбрасываться. SSH особенно чувствителен к джиттеру.
7. Как мне проверить доступность сайта, если нет терминала?
Используйте онлайн-сервисы: Pingdom, Dotcom-Tools, или просто попросите друга в другом регионе открыть сайт с телефона.
Полезные советы и лучшие практики для диагностики
1. Всегда делайте замеры из трёх точек: клиент, сервер, внешний наблюдатель. Это исключает субъективность.
2. Сохраняйте все отчёты MTR. Они пригодятся для разговора с поддержкой - у них нет аргументов против цифр.
3. Проверяйте в разное время суток. Если потери появляются вечером, а днём их нет - это перегрузка базовой станции.
4. Не спешите менять настройки сервера. В 80% случаев проблема не в нём. Сначала диагностика, потом действия.
5. Держите под рукой вторую SIM-карту другого оператора. Это моментальный способ проверить, чья это проблема - ваша сеть или сервер.
6. Записывайте всё. Скриншоты MTR, логи curl, время замеров. Это превращает хаос в систему.
7. Будьте настойчивы с техподдержкой. Иногда нужно дойти до второго или третьего уровня инженеров, чтобы получить внятный ответ.
Когда сайт не грузится с телефона, не спешите паниковать и менять конфиги. Соберите данные с разных точек: свой Wi‑Fi, свой мобильный, замеры со стороны хостера, тесты из других регионов. Чаще всего настоящая причина прячется не в коде и не в конфигах, а на участке провайдера.
Теперь у вас есть готовый алгоритм действий: от установки MTR до финального диалога с оператором. Сохраните эту статью в закладки - она пригодится в следующий раз, когда сайт вдруг перестанет открываться с телефона.
Комментарии
Чтобы оставить комментарий, войдите в аккаунт.