Как диагностировать ошибку «Не удаётся получить доступ к сайту»

Сообщение «Не удаётся получить доступ к сайту» (или его эквивалент в вашем браузере) намеренно расплывчато: за ним может стоять что угодно — от опечатки в URL до полностью упавшего сервера или сбоя сети на вашей стороне. Чтобы разобраться быстро, сначала проверяйте самое дешёвое и быстрое.

Начните с обычного DNS-запроса

Прежде чем считать, что сервер недоступен, разрешите домен отдельно, независимо от браузера. Если вернулся нормальный IP-адрес, дело не в DNS, и можно переходить к проверке самого соединения (открыт ли порт, согласуется ли TLS, отвечает ли сервер). Если вернулся NXDOMAIN, тайм-аут или частный/заведомо недоступный адрес, проблема локализована именно в DNS, и это сразу исключает целую категорию другой диагностики.

Что говорит каждый результат

Поэтому быстрый инструмент поиска без регистрации действительно полезен посреди инцидента: он за секунды даёт ответ на уровне DNS, не требуя открывать терминал и вспоминать синтаксис dig/nslookup, так что вы сразу понимаете, имеете ли вы дело с проблемой DNS, прежде чем тратить время на что-то ещё.

После DNS: что проверять дальше, по порядку

1. TCP-соединение с полученным IP на ожидаемом порту (обычно 443): файрвол или полностью упавший сервер откажут или зависнут именно здесь, даже при идеальном DNS.
2. Действительность TLS-сертификата: просроченный или не соответствующий сертификат вызывает в браузере тревожное предупреждение безопасности, которое никак не связано ни с DNS, ни с доступностью сервера.
3. Ответ на уровне HTTP: сервер, который принимает соединение, но возвращает ошибку 5xx, работает и доступен, но сбоит на уровне приложения — на несколько шагов дальше всего, что мог бы вызвать DNS.

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

Почему именно такой порядок

Каждый уровень в этой последовательности полностью зависит от успеха предыдущего, поэтому проверка по порядку (а не прыжок к самой вероятной причине) и оказывается эффективной. Нет смысла изучать TLS-сертификат, если TCP-соединение вообще не установилось, и нет смысла смотреть коды ответа HTTP, если согласование TLS не удалось. Начинать с DNS — того, что должно произойти самым первым, чтобы всё остальное было возможно, — и двигаться наружу по одному уровню значит никогда не тратить время на расследование симптома, который на самом деле вызывала более простая проблема на раннем уровне.