Сайт открывается у всех, кроме одного провайдера: разбор

MAATRIX

Приходит сообщение: "у меня сайт не открывается". Вы проверяете с телефона, с рабочего ноутбука, просите коллегу — всё грузится за секунды. Возникает соблазн ответить "у вас что-то со связью" и закрыть тикет. Иногда это правда так. Но за годы эксплуатации серверов накапливается и другая статистика: у пользователя действительно проблема, только не там, где вы подумали, — она лежит на стыке его провайдера и вашей инфраструктуры, и без разбора именно этого стыка тикет не закроется, а недовольный клиент останется недовольным.

Первая гипотеза: "дело не в нас" — и почему с ней нельзя торопиться

Логика понятна: сервер отвечает, мониторинг зелёный, у остальных пользователей нет жалоб — значит, проблема локальная у одного человека. В половине случаев так и есть: разряженный роутер, кривой прокси в браузере, заблокированный файрвол на рабочем месте, опечатка в адресе. Но здесь важна оговорка "у одного провайдера" — если жалуется не один случайный человек, а несколько пользователей одного и того же интернет-провайдера или мобильного оператора, а у клиентов других провайдеров всё в порядке, гипотеза "проблема у него на компьютере" перестаёт объяснять картину. Совпадение по провайдеру — это сигнал, что дело в маршруте или в конкретном узле сети, а не в личном устройстве.

Ошибка, которую стоит избегать: отвечать пользователю "у нас всё работает" на основании только собственной проверки. Ваш собственный провайдер, ваш регион и ваш DNS-резолвер — это всего одна точка наблюдения из тысяч возможных. Сайт может быть полностью доступен из 99% сетей и полностью недоступен из одной конкретной — и с точки зрения владельца сервера это будет выглядеть как "всё работает", а с точки зрения того самого пользователя — как полный отказ.

Как проверить гипотезу, не отмахиваясь от жалобы

Прежде чем разбираться в причинах, нужны данные от самого пользователя — без них любая версия остаётся гаданием.

Что попросить прислать:

• Точный текст ошибки — "не удаётся связаться с сайтом", "тайм-аут", "сброс соединения", ошибка сертификата или страница провайдера-блокировщика — это разные диагнозы.
• traceroute (Windows: tracert, macOS/Linux: traceroute) до вашего домена, а лучше — до IP-адреса напрямую, чтобы исключить проблему с DNS из первого замера.
• mtr в отчётном режиме, если у пользователя есть возможность установить утилиту:

mtr -rwzbc 100 example.com > mtr-report.txt

Это покажет не просто маршрут, а процент потерь пакетов на каждом хопе — по нему видно, на каком именно узле начинаются проблемы.

• Результат nslookup или dig — что именно резолвер пользователя возвращает в ответ на A-запись домена:

nslookup example.com
dig example.com +short
dig example.com A @8.8.8.8 +short

Второй вызов на публичный DNS Google полезен для сравнения: если ответы отличаются, вопрос сразу сужается до DNS.

Параллельно проверьте сайт сами — но не с вашего провайдера, а со стороны, независимой от вас и от жалобщика. Здесь помогают сервисы проверки доступности из разных точек мира, которые в один клик прогоняют HTTP-запрос и traceroute из десятков городов и стран одновременно (check-host.net, dnschecker.org и аналогичные). Если инструмент показывает отказ именно из региона или у оператора, совпадающего с провайдером пользователя, — версия "дело в нём" отпадает, и дальше работаем предметно. Если наоборот — все точки, включая ближайшие к пользователю, зелёные, а у него не грузится — вероятнее локальная причина на его стороне (файрвол, антивирус, кэш браузера), и на этом разбор можно закрывать с чистой совестью.

Отдельно стоит держать под рукой собственный мониторинг доступности сайта с точками наблюдения в разных регионах — тогда для повторных похожих жалоб не придётся каждый раз идти во внешние сервисы вручную.

Причина 1: маршрут трафика для этого провайдера идёт через проблемный транзитный AS

Интернет — это не единая сеть, а множество автономных систем (AS), которые обмениваются маршрутами через BGP. Провайдер вашего клиента выбирает путь до вашего сервера через одного или нескольких транзитных операторов, и этот путь может отличаться от маршрута, которым идут запросы от других провайдеров — даже из того же города. Если на промежуточном участке у транзитного AS перегружен канал, идут технические работы или произошёл частичный сбой пиринга, пакеты начинают теряться или задерживаться именно на этом сегменте — а значит, именно у клиентов провайдеров, чей трафик через него проходит.

В отчёте mtr эта картина видна как рост потерь пакетов (Loss%) начиная с определённого хопа и до конца маршрута — если потери появляются на промежуточном узле и дальше не восстанавливаются, это транзитный участок, а не ваш сервер (последний хоп с большими потерями при этом иногда обманчив: некоторые маршрутизаторы намеренно не отвечают на ICMP и показывают "потери", которых по факту нет — судить нужно по совокупности хопов, а не по последней строке).

Важный нюанс: на маршрутизацию через конкретный AS вы обычно повлиять не можете — это решение провайдера пользователя и его вышестоящих операторов, а не настройка на вашей стороне. Что реально в ваших силах: убедиться, что у вашего хостинга есть достаточное число независимых аплинков (транзитов) и пиринговых соединений, чтобы при проблеме на одном из путей трафик мог пойти в обход через другой. У серверов с одним-единственным аплинком такой манёвр физически невозможен.

Причина 2: блокировка или фильтрация именно на уровне провайдера

Отдельная категория — не сбой, а осознанное решение сети: провайдер фильтрует конкретный IP, диапазон адресов или домен по внутренним спискам (антивирусные фильтры на уровне провайдера, корпоративные политики у операторов для юрлиц, региональные ограничения, попадание вашего IP в чужой блок-лист из-за соседства на том же сервере с ранее заблокированным ресурсом). В этом случае у остальных провайдеров всё работает штатно, а у конкретного — стабильно и воспроизводимо не работает, без флуктуаций во времени, характерных для перегрузки канала.

Отличить это от временного сетевого сбоя помогает время: сетевая перегрузка обычно "плавает" — то отвечает, то нет, потери меняются от минуты к минуте. Блокировка стабильна: сегодня не работает, завтра не работает, через неделю всё так же не работает, и traceroute до сервера может вообще не доходить, обрываясь заметно раньше, чем у корректного маршрута, либо доходить полностью, но HTTP-ответ подменяется страницей-заглушкой самого провайдера.

Если IP сервера пострадал из-за соседей по shared-инфраструктуре — стоит проверить репутацию адреса через публичные чекеры блэклистов и, если он действительно в списках, обратиться в поддержку хостинга за заменой IP или за содействием в делистинге. Если же блокировка целенаправленная на уровне конкретного провайдера — единственный рабочий путь обычно один: обращение в поддержку самого этого провайдера с описанием проблемы и просьбой проверить фильтрацию на их стороне. Здесь честно стоит признать: это зона, которая от вас как от владельца сервера не зависит вообще.

Причина 3: устаревшая DNS-запись, закешированная именно у резолвера этого провайдера

Частый сценарий: сайт переехал на новый IP, вы обновили A-запись у себя в DNS-панели, всё работает — кроме одного провайдера. Причина в том, что DNS-резолвер именно этого оператора закешировал старую запись на срок, указанный в TTL, и продолжает раздавать её своим клиентам, пока кеш не истечёт. Если TTL был выставлен большим (например, 86400 секунд — сутки, а у некоторых регистраторов по умолчанию и больше), резолвер может отдавать старый адрес заметно дольше, чем у резолверов, которые заглянули за записью позже и уже получили новую.

Проверяется просто — сравнением ответа dig/nslookup от резолвера пользователя (см. раздел выше) с ответом от независимого DNS вроде 8.8.8.8 или 1.1.1.1. Если независимый резолвер отдаёт новый IP, а резолвер провайдера — старый, диагноз подтверждён. Дополнительно полезны сервисы вроде dnschecker.org, показывающие состояние распространения записи по резолверам разных стран одновременно — по ним видно, идёт ли обновление вообще или конкретный резолвер завис на старом значении дольше срока TTL (что тоже случается — не все резолверы одинаково честно соблюдают TTL).

Что можно сделать: попросить пользователя вручную сменить DNS на устройстве на публичный (8.8.8.8, 1.1.1.1) — это временный обход, а не исправление проблемы у его провайдера, но он снимает жалобу здесь и сейчас. На будущее — заранее снижать TTL записи (до 300-600 секунд) за день-два перед плановой сменой IP, чтобы кеши устаревали быстро. Подробнее о похожей ситуации, когда сайт открывается по IP, но не по домену, разобрано в статье сайт открывается по IP, но не по домену.

Причина 4: MTU и фрагментация, специфичные для сети конкретного провайдера

Менее очевидная, но реальная причина: провайдер использует туннелирование (PPPoE, VPN-каналы внутри своей сети, мобильный оператор с инкапсуляцией трафика) с уменьшенным MTU, а где-то на пути ICMP-пакеты "Fragmentation Needed" блокируются файрволом — из-за этого крупные пакеты не проходят и не фрагментируются штатно (проблема известна как Path MTU Discovery black hole). Мелкие HTTP-запросы и статичные страницы при этом могут открываться нормально, а вот тяжёлые страницы с большими TLS-хендшейками, крупными ответами или загрузкой файлов — зависать или обрываться на середине.

Характерный симптом: сайт частично грузится (иногда виден HTML-каркас без стилей или картинок), либо соединение устанавливается, но зависает без ответа именно на объёмных запросах. Проверяется через отправку пакетов с запретом фрагментации и разным размером:

ping -M do -s 1472 example.com

(на Linux; 1472 соответствует MTU 1500 минус заголовки IP и ICMP). Если пакет такого размера не проходит, а меньший — проходит, это указывает на проблему MTU именно на пути к серверу. Постепенно уменьшая размер, можно нащупать реальный рабочий MTU в конкретной сети.

На стороне сервера иногда помогает принудительная подрезка MTU для исходящих пакетов через TCP MSS Clamping на файрволе или балансировщике — это не чинит саму сеть провайдера, но снимает конкретно эту проблему для его пользователей, не трогая остальных. Подробный разбор настройки и диагностики такой фрагментации — в статье MTU и фрагментация: откуда загадочные обрывы.

Как локализовать причину: последовательное исключение

Когда данные от пользователя и независимая проверка собраны, полезно двигаться по чек-листу сверху вниз, а не проверять всё сразу вперемешку:

1. DNS совпадает? Сравните ответ резолвера провайдера с публичным DNS. Не совпадает — вероятная причина найдена (см. причину 3), дальше можно не копать.
2. traceroute/mtr доходит до сервера? Если обрывается на промежуточном хопе задолго до вашей сети — смотрите в сторону транзитного AS (причина 1) или блокировки на уровне провайдера (причина 2).
3. Соединение TCP устанавливается, но зависает на передаче данных? Проверьте гипотезу MTU (причина 4) — маленькие запросы против крупных.
4. HTTP-ответ приходит, но это не ваш контент, а страница-заглушка или предупреждение? Это почти всегда фильтрация на уровне провайдера (причина 2), а не сетевая или DNS-проблема.
5. Независимые внешние чекеры видят проблему только из региона/сети провайдера пользователя, а из остальных точек — нет? Подтверждает, что причина локальна для этой сети, и дальше стоит смотреть пункты 1-4 в связке именно с ней.

Такой порядок экономит время: DNS и traceroute проверяются за минуты и сразу отсекают половину версий, а MTU и глубокий разбор маршрутизации имеет смысл разбирать, только когда первые два пункта чистые.

Частые вопросы