Сценарий проверки доступности
Как проверить, действительно ли сайт недоступен
Пошаговый способ отличить реальную недоступность сайта от проблемы DNS, SSL, закрытого порта или ситуации, когда сайт технически отвечает, но всё равно сломан.
Когда сайт не открывается, первый вопрос обычно слишком общий: «он лежит?» На практике сначала нужно понять более узкую вещь. Сбой произошёл до DNS, во время соединения, на этапе TLS или уже после того, как сервер вернул HTTP-ответ? Именно это отличает полезную диагностику от пустой догадки про доступность.
Сначала проверьте весь путь запроса
Проверка сайта даёт самый быстрый обзор, потому что в одном запуске затрагивает DNS, TCP, TLS, редиректы и финальный HTTP-ответ.
Не называйте любой сбой «падением сайта»
Коды 403, 429 или 503 всё ещё означают, что сервер ответил. Это совсем не то же самое, что DNS-ошибка, отказ в соединении или ошибка TLS.
Уточняйте слой отдельными инструментами
DNS, SSL, проверка порта, пинг и трассировка маршрута нужны после первого результата, когда уже видно, где именно начал ломаться путь запроса.
01
Когда эта страница особенно полезна
Этот сценарий рассчитан на первые минуты диагностики, пока вы ещё не полезли менять записи и не начали наугад винить хостинг.
Сайт не открывается именно у вас
Нужно понять, видна ли проблема с публичного сервера или она может быть ограничена вашим браузером, VPN, офисной сетью или провайдером.
Клиент пишет, что сайт не работает
Нужен быстрый и технически внятный ответ до эскалации. Один отчёт, который разделяет HTTP, DNS, SSL и сетевой слой, полезнее абстрактного «да» или «нет».
Мониторинг уже прислал алерт
Хочется получить второе мнение с публичной диагностической страницы и понять, больше это похоже на проблему приложения, маршрута или доверия к HTTPS.
02
Практичный первый сценарий
Задача — быстро перейти от общего симптома к конкретному слою, не прыгая в низкоуровневые инструменты раньше времени.
Запустите Проверку сайта на том URL, который действительно не работает
По возможности используйте реальное имя хоста и схему. Вам нужна цепочка редиректов, итоговый URL, тайминги и видимый HTTP-результат в одном отчёте.
Смотрите не только на заголовок результата, но и на точку отказа
DNS-ошибка, TLS-предупреждение, тайм-аут и HTTP 503 ощущаются как «сайт лежит», но это разные причины и разные следующие действия.
Подтвердите нужный слой профильным инструментом
Если первый результат указывает на сертификат, откройте Проверку SSL. Если дело в резолвинге — Проверку DNS. Если соединение вообще не открывается — Проверку порта, а затем Пинг или Трассировку маршрута, если есть подозрение на маршрут.
Решите, доказывает ли результат глобальную проблему
Одна или две публичные точки могут доказать, что сбой виден из конкретных мест. Они не могут доказать, что то же самое происходит у всех пользователей и во всех регионах.
03
Что обычно означают типичные результаты
Именно эти интерпретации важнее всего, когда нужно честно ответить на вопрос, доступен сайт или нет.
Есть HTTP-ответ с кодом статуса
Запрос дошёл до приложения или пограничного сервиса. Сайт всё ещё может быть непригодным, но имя хоста уже разрешилось и кто-то ответил по HTTP.
DNS не разрешается или не возвращает полезную запись
Проблема началась ещё до веб-сервера. В первую очередь нужно смотреть A, AAAA, CNAME, NS и поведение резолвера, а не SSL или код приложения.
Есть ошибка TLS или сертификата
Хост достижим настолько, что HTTPS успел начаться, но доверие или согласование протокола сорвались. Пользователь может видеть предупреждение безопасности, хотя сервер формально жив.
Соединение закрыто, отклонено или ушло в тайм-аут
Веб-сервис не принял рабочее соединение из активной точки проверки. Часто это сетевая политика, неработающая служба на порту, проблема исходного сервера или фильтрация по пути.
04
Какой инструмент открыть следующим
Открывайте ту страницу, которая совпадает с первым понятным сигналом, а не пытайтесь объяснить всё по одному расплывчатому сообщению.
Лучший первый шаг для случая «сайт не открывается», потому что он показывает весь путь запроса и первую точку сбоя.
Проверка сайтаНормализованный DNS-ответОткрывайте, когда проблема похожа на DNSПодходит после NXDOMAIN, пустых ответов, старых IP-адресов или несоответствия между именем хоста и ожидаемой инфраструктурой.
Проверка DNSСертификат и TLSИспользуйте, когда упираетесь в HTTPSЛучший выбор для истёкших сертификатов, несовпадения имени хоста, самоподписанных цепочек и видимой поддержки версий TLS.
Проверка SSLTCP-достижимостьИспользуйте, когда сервис может просто не слушать портЧистая проверка порта помогает отделить ошибки веб-приложения от ситуации, когда соединение на 80 или 443 вообще не устанавливается.
Проверка порта05
Ошибки, которые только тратят время
Эти сокращения мешают нормальной диагностике, потому что смешивают разные слои в один бессодержательный вывод.
- Считать любой ответ не-200 доказательством того, что «сайт лежит целиком».
- Проверять только главную страницу, хотя реальная проблема проявляется на редиректе, входе, оплате или API-пути.
- Сразу запускать трассировку маршрута, не убедившись, что сайт вообще отвечает по HTTP или слушает ожидаемый порт.
- Думать, что один серверный сбой автоматически доказывает глобальную проблему для всех пользователей.