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

Ситуация знакомая: в офисе сайт открывается, мониторинг показывает норму, но клиенты из другого региона или с мобильного интернета видят ошибку. Иногда помогает VPN, другой оператор или смена Wi-Fi. Это не доказывает, что «сайт исправен» или «виноват провайдер». Оно показывает только одно: проблема зависит от пути пользователя до ресурса.

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

Почему один сайт даёт разный результат

Между браузером и приложением находится несколько уровней:

1. Устройство и браузер пользователя.
2. Локальная сеть или мобильное подключение.
3. DNS-резолвер.
4. Сеть оператора.
5. Межсетевые маршруты.
6. CDN, защита от атак или балансировщик.
7. Сервер и веб-приложение.

Сбой на любом уровне может выглядеть одинаково: страница не загрузилась. Поэтому фраза «у меня работает» не является диагностикой.

Сначала уточните симптом

Попросите пользователя прислать не только скриншот, но и минимальный контекст:

• точный адрес страницы;
• время ошибки с часовым поясом;
• регион;
• оператор или провайдер;
• устройство и браузер;
• домашний это интернет или мобильный;
• открываются ли другие страницы того же домена;
• что происходит при смене подключения;
• текст или код ошибки;
• использовался ли VPN.

Не просите человека присылать пароли, cookies, токены или полные технические журналы в публичный чат.

Быстрая матрица проверок

Один и тот же адрес полезно проверить минимум в четырёх вариантах:

• обычное подключение сотрудника;
• мобильный интернет другого оператора;
• внешний мониторинг из другого региона;
• серверная проверка внутри инфраструктуры.

Результаты помогают сузить область:

• не работает нигде — вероятны сервер, приложение, DNS или глобальная конфигурация;
• не работает у одного устройства — проверьте браузер, кэш, hosts, антивирус и локальную сеть;
• не работает у одного провайдера или региона — исследуйте DNS и маршрут;
• открывается главная, но не работает действие — проверяйте приложение, API или интеграцию;
• IP доступен, а домен нет — вероятна проблема DNS или TLS;
• через VPN работает — изменился маршрут, DNS или внешний IP, но это ещё не доказывает конкретную причину.

Уровень 1. Приложение и сервер

Сначала подтвердите, что сервис действительно работает:

• веб-сервер отвечает;
• приложение не выдаёт 5xx;
• база данных и критичные зависимости доступны;
• на диске есть свободное место;
• сертификат действителен;
• домен попадает на нужный виртуальный хост;
• недавний релиз не изменил конфигурацию;
• CDN или WAF не блокирует обычные запросы.

Проверяйте не только главную страницу. Для бизнеса важны сквозные сценарии: форма заявки, вход, оплата, запись, передача лида в CRM.

Уровень 2. DNS

DNS преобразует доменное имя в IP-адрес. Разные пользователи могут обращаться к разным рекурсивным DNS-серверам и некоторое время получать разные ответы после изменений.

Проверьте:

• какие NS обслуживают домен;
• совпадают ли A и AAAA-записи с ожидаемыми адресами;
• нет ли старой записи у части серверов;
• корректны ли CNAME;
• не истекло ли делегирование;
• не появился ли ошибочный IPv6-адрес;
• какое значение TTL использовалось до изменения.

Если вы только что поменяли DNS, не называйте любую проблему «распространением записей». Сравните ответы нескольких резолверов и авторитетных серверов.

Уровень 3. TLS и HTTPS

Сайт может отвечать по сети, но не открываться из-за защищённого соединения. Возможные причины:

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

Запишите точный текст ошибки браузера. «Не открывается» недостаточно, чтобы отличить TLS от DNS или тайм-аута.

Уровень 4. Маршрут и фильтрация

Если сервер доступен из одних сетей и недоступен из других, собирают трассировку. В документации Selectel для недоступности из определённой внешней сети рекомендуют проверять маршрут, порты и сетевой трафик, а трассировку выполнять в двух направлениях.

Для анализа полезны:

• mtr или WinMTR;
• traceroute или tracert;
• проверка TCP-порта 443;
• серверные логи;
• дамп трафика в момент проблемы;
• данные внешнего узла, с которого воспроизводится ошибка.

Один «красный» промежуточный узел в трассировке ещё не доказывает поломку: некоторые маршрутизаторы не отвечают на диагностические пакеты, но пропускают обычный трафик. Важен результат на конечном адресе и сравнение направлений.

Где могут влиять ТСПУ

Российские операторы используют технические средства противодействия угрозам. Их влияние можно рассматривать как одну из гипотез, если HTTP/HTTPS, SSH, VPN или RDP ведут себя по-разному в отдельных сетях.

Но нельзя объявлять ТСПУ причиной только потому, что через VPN сайт открылся. Сначала исключите:

• ошибочный DNS;
• IPv6;
• блокировку на WAF;
• проблемы сертификата;
• географические правила CDN;
• файрвол сервера;
• повреждённый маршрут;
• ограничения конкретного IP.

Диагноз должен опираться на воспроизводимые данные, а не на догадку.

Что проверить в CDN и защите

CDN и WAF могут улучшать доступность, но добавляют ещё один слой. Проверьте:

• статус узлов;
• правила блокировок;
• ограничения по стране и ASN;
• rate limit;
• ошибочные сигнатуры;
• кэш ответа 4xx или 5xx;
• происхождение реального IP пользователя;
• доступ CDN к origin-серверу.

Если фильтр блокирует только один оператор, сохраните примеры IP и идентификаторы запросов, но не публикуйте персональные данные клиентов.

Как собрать доказательства для хостинга

Хороший тикет содержит:

• домен и IP;
• точное время;
• источник проверки и оператор;
• ожидаемый и фактический результат;
• код ошибки;
• результат DNS-запроса;
• трассировку;
• проверку порта;
• примеры из журналов;
• список уже выполненных действий.

Сообщение «у клиентов не работает» заставляет поддержку повторно собирать вводные и замедляет расследование.

Что сообщить пользователям

Не утверждайте, что «проблема точно у провайдера», пока это не подтверждено. Безопасная формулировка:

Мы видим, что доступ нарушен у части пользователей и проверяем DNS, сетевые маршруты и инфраструктуру. Пришлите, пожалуйста, время ошибки, регион, оператора и скриншот. Это поможет найти общий признак.

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

Как уменьшить риск повторения

• Настройте мониторинг из нескольких сетей и регионов.
• Отдельно проверяйте DNS и срок сертификата.
• Храните контакты регистратора, хостинга и CDN.
• Ведите журнал изменений инфраструктуры.
• Настройте централизованные логи.
• Подготовьте шаблон сбора данных у клиента.
• Опишите процедуру инцидента и ответственных.
• Проверяйте сквозные бизнес-сценарии, а не только HTTP 200.

Для системной проверки используйте чек-лист технического аудита. Если нужна диагностика существующего проекта и постоянный контроль, посмотрите формат технической поддержки сайта.

Главное

Когда сайт не открывается у части пользователей, нужно исследовать цепочку целиком: устройство, DNS, маршрут, фильтрацию, CDN, сервер и приложение. Проверка с одного компьютера не подтверждает доступность для бизнеса.

Собирайте точные симптомы, сравнивайте сети, проверяйте DNS и TLS, выполняйте трассировку в обе стороны и сохраняйте время события. Такой подход помогает быстрее найти уровень сбоя и не тратить часы на случайные изменения сайта.

---

Источник первоначального материала: Telegram-канал «Красотуля»

Теги: Сайт не открывается, Доступность сайта, DNS, Хостинг, Сеть, ТСПУ Дата публикации: 15 июня 2026