Одна из самых странных проблем с сайтом выглядит так: владелец открывает его на своем компьютере и видит совершенно нормальную страницу, а клиент пишет, что сайт не работает. Через несколько минут приходит еще одно сообщение с той же жалобой. Вы снова обновляете страницу, переходите по меню и не находите никаких проблем.
Первое желание в такой ситуации — решить, что проблема находится у посетителя. Иногда так и есть. Но если сайт открывается у одного человека, это еще не доказывает, что он доступен всему интернету.
Разные пользователи могут получать разные DNS-ответы, подключаться по IPv4 или IPv6, идти к серверу по разным сетевым маршрутам, попадать на разные узлы CDN и даже получать разные ответы от системы защиты сайта.
Поэтому вопрос нужно ставить иначе. Не почему сайт работает у меня, а почему именно мой компьютер может его открыть, а другое устройство не может.
Так гораздо проще найти причину.
Сначала выясните, у кого именно не открывается сайт
Фраза сайт не работает почти ничего не сообщает.
Один пользователь видит сообщение браузера о невозможности найти сервер. У другого появляется ошибка сертификата. Третий получает 403 Forbidden. Четвертый ждет полминуты и видит 504. Пятый вообще открывает старую версию сайта.
Внешне все эти ситуации можно описать одинаково: сайт не открылся. Технически причины у них совершенно разные.
Поэтому первым делом попросите пользователя прислать скриншот ошибки или хотя бы точно описать, что происходит.
Дальше нужно понять масштаб.
Если сайт не открывается только на одном компьютере, а с телефона, другого компьютера и внешних сервисов работает нормально, вероятнее всего проблема локальная.
Если сайт недоступен всем пользователям одного интернет-провайдера или региона, искать нужно уже глубже.
Если он не открывается практически ниоткуда, хотя на вашем компьютере продолжает работать, ваше устройство может использовать старый DNS-кеш, локальную запись hosts или обращаться к серверу каким-то особым способом.
Очень полезен простой эксперимент.
Откройте сайт на смартфоне через Wi-Fi, затем отключите Wi-Fi и повторите проверку через мобильный интернет.
Это уже две разные сети.
Если через домашний интернет сайт работает, а через мобильный нет, браузер и само устройство становятся менее вероятными виновниками. Разница находится где-то между сетями и сервером.
Можно попросить знакомого из другого города открыть тот же адрес. Еще лучше использовать внешний мониторинг или сервис проверки доступности из нескольких точек.
Так вы перестаете судить о состоянии сайта по одному компьютеру.
Для владельца проекта это вообще полезная привычка. Сайт должен контролироваться извне. Если проверять его только из собственной сети, некоторые виды сбоев можно долго не замечать.
Обратите внимание и на точный адрес.
Например, у вас сохранена закладка на https://example.ru, а пользователь вводит https://www.example.ru. Технически это разные имена. Основной домен может быть настроен правильно, а для www отсутствует DNS-запись или SSL-сертификат.
То же самое относится к HTTP и HTTPS.
Нормально настроенный сайт обычно приводит посетителя к единственному основному варианту адреса независимо от того, как он начал переход. Но при ошибках конфигурации один вариант работает, а другой нет.
Почему сайт может открываться только у части пользователей
Причин довольно много, но начинать лучше с наиболее вероятных.
DNS еще не обновился у всех
Классический сценарий возникает после переноса сайта на другой хостинг или изменения DNS.
Вы поменяли IP-адрес домена и уже видите новый сервер. У другого пользователя DNS-резолвер пока хранит старое значение.
Если прежний сервер продолжает работать, человек может увидеть старую версию сайта. Если старый хостинг уже отключен, для него сайт окажется недоступным.
Именно поэтому старую площадку после переноса не стоит выключать сразу.
DNS-ответы кешируются на разных уровнях, и обновление не обязано стать заметным всему интернету одновременно.
Но не нужно любую сетевую проблему списывать на распространение DNS.
Если настройки не менялись несколько недель, а сайт внезапно перестал открываться у части посетителей, бесконечно ждать обновления DNS бессмысленно.
Нужно проверить, какие значения фактически возвращают DNS-серверы.
Забыли про IPv6
Это менее очевидная, но очень интересная причина.
У домена может существовать A-запись для IPv4 и AAAA-запись для IPv6.
Представим, что IPv4 настроен правильно, а AAAA осталась от старого сервера или указывает на адрес, где сайт не работает.
Пользователь из сети без IPv6 обращается по IPv4 и прекрасно открывает сайт. Другой пользователь имеет полноценное IPv6-подключение и пытается использовать проблемный адрес.
В результате владелец говорит у меня все работает, а посетитель совершенно справедливо отвечает у меня нет.
При переносе сайта поэтому стоит проверять не только A, но и AAAA.
Если IPv6 вам вообще не нужен и сервер его не обслуживает, случайно оставленная AAAA-запись пользы не приносит.
Проблема находится в конкретной сети
Интернет не является одним проводом от посетителя до вашего сервера.
Между ними находится инфраструктура операторов связи, маршрутизаторы и множество промежуточных узлов. Пользователи разных провайдеров могут идти к одному серверу разными маршрутами.
Поэтому теоретически возможна ситуация, когда из одной сети сайт доступен нормально, а из другой соединение не устанавливается или работает нестабильно.
Именно здесь полезна проверка через мобильный интернет и несколько независимых внешних точек.
Если проблема четко повторяется только у абонентов определенной сети, это важная информация для технической поддержки хостинга.
Фраза сайт иногда не работает дает специалисту мало информации. Формулировка из трех независимых сетей сайт доступен, а через такого-то оператора соединение не устанавливается уже намного полезнее.
Система защиты блокирует часть посетителей
На сервере могут работать firewall, защита от DDoS, антибот, CDN или другие механизмы фильтрации.
Они способны ограничивать запросы по IP-адресу, стране, частоте обращений и другим признакам.
Иногда блокировка совершенно оправданна. Например, с адреса идет автоматическая атака.
Но правила могут сработать и ошибочно.
Особенно подозрительна ситуация, когда пользователь стабильно не может открыть сайт из одной сети, а после переключения на мобильный интернет все сразу начинает работать.
IP-адрес при этом меняется, и система защиты может воспринимать новое соединение иначе.
Если используется CDN или внешний сервис защиты, проверять нужно не только настройки самого хостинга.
Запрос посетителя может вообще сначала приходить на промежуточную инфраструктуру и только затем передаваться исходному серверу.
Проблема с SSL проявляется не у всех одинаково
Ошибки HTTPS тоже способны создавать странное впечатление выборочной недоступности.
Например, сертификат установлен для основного домена, но не подходит для www. Или сервер отдает неправильную цепочку сертификатов.
Разные браузеры и устройства могут реагировать на ошибки немного по-разному, хотя рассчитывать на это как на нормальное поведение нельзя.
Если один человек сообщает о проблеме безопасности, проверьте сертификат извне и убедитесь, что он корректен для всех используемых вариантов домена.
Особенно внимательно проверяйте HTTPS после переноса сайта, изменения DNS, подключения CDN или замены сертификата.
На сервере настроены ограничения по IP
Иногда причина находится в конфигурации самого сайта или веб-сервера.
Доступ может быть разрешен или запрещен для определенных IP-адресов и сетей. Такие правила используют для административных разделов, тестовых площадок и служебных систем.
Проблема появляется, когда ограничение случайно применяется шире, чем планировалось.
Похожий эффект способны создавать плагины безопасности CMS. После нескольких неудачных входов или подозрительной активности они могут заблокировать IP.
Владелец сайта находится в другой сети и ничего необычного не замечает.
У одного пользователя проблема только в браузере или компьютере
Если жалуется один человек, не нужно сразу перестраивать DNS.
Попросите его открыть сайт в другом браузере или приватном режиме. Затем попробовать другое устройство и другую сеть.
Иногда мешают расширения браузера, локальный антивирус, защитное программное обеспечение, прокси или поврежденный кеш.
На компьютере может находиться и вручную добавленная запись в файле hosts.
Она позволяет локально указать, на какой IP должен вести домен, не меняя публичный DNS. Такой способ используют разработчики при переносе и тестировании сайтов.
Если запись забыли удалить, конкретный компьютер продолжит обращаться не туда, куда направлен домен для остальных пользователей.
Получается обратная ситуация: весь интернет видит проблему, а у разработчика сайт прекрасно открывается, потому что его компьютер принудительно отправляет запрос на правильный сервер.
Как найти причину, если у вас сайт работает
Главное правило диагностики — не менять все настройки одновременно.
Если начать удалять DNS-записи, перевыпускать SSL, отключать CDN и редактировать конфигурацию сервера за один вечер, к исходной проблеме легко добавить несколько новых.
Двигайтесь от простого к сложному.
Сначала откройте сайт со своего компьютера и запомните точный адрес, по которому он работает.
Затем проверьте этот же URL через мобильный интернет.
После этого используйте другое устройство или попросите человека из другой сети выполнить проверку.
Если сайт работает везде, кроме одного компьютера, начинайте с этого компьютера.
Проверьте другой браузер, локальный DNS-кеш, файл hosts, антивирус и сетевые настройки.
Если сайт не работает в целой сети, но доступен через другие подключения, зафиксируйте это и продолжайте проверку с учетом IP и маршрута.
Если проблема возникает в нескольких независимых сетях, проверьте DNS.
Сравните A и AAAA. Убедитесь, что они ведут туда, куда должны. Если сайт недавно переезжал, проверьте старый и новый сервер.
Затем посмотрите, какой ответ фактически возвращает сервер.
Здесь важно отличать невозможность установить соединение от HTTP-ошибки.
Если браузер уже получил 403, 500, 502 или 504, он добрался до определенного элемента инфраструктуры и получил от него ответ. Это совсем другая ситуация, чем отсутствие DNS-разрешения или невозможность установить соединение.
Код 403 заставляет искать ограничения доступа. Ошибки 500 указывают на серверную часть приложения. 502 и 504 часто появляются в инфраструктуре с прокси и вышестоящими серверами.
Посмотрите журналы.
Если пользователь сообщает точное время ошибки и свой IP-адрес, в логах можно проверить, дошел ли его запрос до сервера.
Это очень полезное разделение.
Запроса вообще нет в журналах — проблема могла возникнуть раньше по пути к серверу.
Запрос есть и сервер ответил 403 — смотрим правила доступа.
Запрос дошел и завершился 500 — изучаем приложение и журнал ошибок.
Если перед сервером находится CDN, картина становится сложнее, поскольку исходный сервер может видеть запрос уже от инфраструктуры CDN. Тогда пригодятся журналы и диагностические инструменты самого сервиса.
Для сайта, добавленного в Яндекс Вебмастер, можно дополнительно проверить ответ сервера инструментами сервиса. Это позволяет увидеть сайт не с вашего компьютера, а с внешней стороны.
Такой тест особенно полезен, если владелец уверен, что все работает, а поисковый робот сообщает обратное.
Что делать, чтобы не узнавать о проблеме от клиентов
Если сайт важен для бизнеса, его доступность лучше проверять автоматически.
Внешний мониторинг через определенные интервалы обращается к сайту и фиксирует результат. При недоступности владелец получает уведомление.
Важно именно слово внешний.
Система должна проверять проект не из того же сервера, на котором он находится, а через интернет. Тогда она лучше отражает ситуацию обычного посетителя.
Для важных проектов полезны проверки из нескольких географических точек или сетей. Один проверяющий узел тоже может столкнуться с локальной сетевой проблемой, которая не затрагивает остальных.
После переноса сайта не выключайте старый хостинг в ту же минуту, когда поменяли DNS.
Оставьте его доступным на время перехода и убедитесь, что новый сервер стабильно обслуживает запросы.
Проверьте A и AAAA, если используется IPv6.
Отдельно откройте основной домен, www и HTTPS. Все варианты, которые могут вводить пользователи, должны либо нормально работать, либо корректно перенаправлять на основной адрес.
После подключения CDN или защиты от DDoS проверьте сайт из разных сетей. Не ограничивайтесь собственным офисным интернетом.
Следите и за журналами ошибок. Если сервер периодически возвращает 5xx, но каждый раз успевает восстановиться до того, как вы откроете сайт вручную, внешне проект будет казаться исправным.
И наконец, не относитесь к единичной жалобе клиента как к доказательству неисправности хостинга, но и не отмахивайтесь от нее только потому, что у вас сайт открылся.
Один пользователь действительно может столкнуться с локальной проблемой. Но он также может оказаться первым человеком, который заметил неправильную AAAA-запись, ошибочное правило firewall, проблему CDN или недоступность сервера из определенной сети.
Правильная реакция состоит не в споре работает сайт или нет, а в сравнении условий.
С какой сети выполняется подключение? Какой адрес открывается? Какой IP получает пользователь? Работает ли IPv4 и IPv6? Что показывает браузер? Какой код возвращает сервер? Доходит ли запрос до логов?
Когда эти вопросы заданы по порядку, загадочная ситуация у меня работает, а у других нет обычно превращается в вполне конкретную техническую проблему.
А конкретную проблему уже можно исправить.
