Почему сайт недоступен с мобильного, хотя сервер работает? Реальный кейс

mr. Cooper 2 часа назад Технологии
Почему сайт недоступен с мобильного, хотя сервер работает? Реальный кейс

Диагностика проблем с доступом к сайту: от 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 и правильно прочитать отчёт

Команда для трассировки

Я делал замеры из трёх точек:

  1. С мобильного интернета.

  2. С домашнего Wi-Fi.

  3. Со стороны хостера (попросил их запустить 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 не лечат потери пакетов на мобильном интернете. Это как лечить головную боль через смену обоев в комнате - не связано.

Чтобы не спорить впустую, я собрал три независимых доказательства:

  1. Мой MTR через Wi‑Fi: 0% потерь, сайт доступен.

  2. Мой MTR через мобильный: стабильно 70–72% потерь.

  3. 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 до финального диалога с оператором. Сохраните эту статью в закладки - она пригодится в следующий раз, когда сайт вдруг перестанет открываться с телефона.

Комментарии

Пока нет комментариев. Будьте первым, кто напишет.

Чтобы оставить комментарий, войдите в аккаунт.

Похожие статьи