# Как выстроить диагностику недоступности сайта за 30 минут
Когда сайт перестаёт открываться, особенно в разгар рабочих задач, первая задача не «угадать причину», а быстро отделить ложную тревогу от реального сбоя. Ниже — практичный план, который помогает системно проверить, где именно рвётся цепочка доступности сайта.
Как поймать проблему в моменте, не теряя время
Сайт может быть технически доступным, но выглядеть как недоступный для конкретных пользователей. Поэтому лучше проверять не по одному признаку, а по трем зонам: «видим в браузере», «виден в сети», «принимает реальный трафик».
Для первой оценки удобно зафиксировать три факта:
- Что именно не работает: главная страница, отдельная форма, API-эндпоинт, оплата.
- Какой код ответа видит проверка (например, 5xx, 4xx, редиректы).
- Из каких мест проблема воспроизводится: один город, мобильный интернет, домашний Wi-Fi.
Если на этом этапе неясно, не начинать перепроверки сразу по каждому слою — сначала короткая гипотеза, затем поочерёдная диагностика.
Шаг 1. Проверяем, где цепочка обрывается в сети
1.1 DNS и DNS-кэш
Даже если сайт включен, DNS может вернуть разные адреса в разные моменты. Проверьте, на какой IP резолвится домен сейчас и не «перескакивает» ли он между адресами. Если изменение недавно происходило, дайте TTL и кэшу время стабилизироваться.
1.2 Локация клиента
Не редкость: у одной площадки всё отлично в Москве и не отвечает из другого региона или сетей. Это полезный признак проблемы маршрутизации, CDN или провайдера доставки трафика.
Шаг 2. Проверяем транспортный слой
2.1 HTTP-ответы и редиректы
Даже корректный код 200 не гарантирует, что пользователь увидит рабочий контент. Нужна связка: ответ + содержимое страницы. Проверьте:
- Не зацикливаются ли редиректы.
- Нет ли цепочки `http -> https -> http`.
- Есть ли служебная страница, которая маскирует реальный сбой.
2.2 Время ответа и порог доступности
Временные всплески тоже считаются проблемой, если сайт долго отвечает только после нескольких попыток. Зафиксируйте первые и повторные проверки: один «провал» может быть кратковременным пиком, серия провалов — признаком деградации.
Шаг 3. Проверяем приложение и серверные уровни
3.1 Где ломается логика после отдачи страницы
Иногда HTML загружается, но ключевая часть (платёжная кнопка, API, поиск) не работает. Тогда «сайт доступен», но бизнес-функция недоступна. И это надо фиксировать отдельно от полного падения.
3.2 SSL и внутренние ошибки
Если проблема касается сертификата или цепочки TLS, проверка часто не сводится к одному сообщению в браузере. Смотрите, когда ошибка появляется: сразу после истечения срока, после смены хостинга, после переноса правил на уровне CDN. Если нужно углублённо восстановить, можно использовать профессиональную поддержку через `/support/` или контакты на `/contacts/`.
Практические сценарии, которые встречаются чаще всего
Сценарий: сайт доступен у вас, но не у клиентов
1) Соберите примеры URL и сетей, где проблема воспроизводится. 2) Убедитесь, что DNS возвращает один и тот же адрес для этих точек. 3) Проверьте поведение HTTP/HTTPS и редиректов для каждого примера. 4) Проверьте, нет ли кода ошибки только на страницах с личным кабинетом/платежами.
Сценарий: сайт то открывается, то не открывается
1) Фиксируйте время каждого провала. 2) Пройдите проверку нескольких страниц, не только главной. 3) Проверьте изменения инфраструктуры в эти интервалы. 4) Если после перезапуска узла проблема исчезает на короткое время, это часто указывает на нестабильность слоя приложения.
Сценарий: после изменения конфигурации часть сайта перестала отвечать
1) Отключите новые правила по одной и смотрите, когда восстановление возвращается. 2) Вернитесь к прошлой рабочей конфигурации как диагностический шаг, а не как решение. 3) Зафиксируйте список изменений и симптомы на уровне времени.
Что сделать в первые 30 минут до публикации изменений
- Зафиксировать симптомы с примерами ссылок, IP/доменов и браузеров.
- Проверить DNS, HTTP, HTTPS и редиректы по нескольким точкам.
- Оценить, затрагивает ли проблема ключевые бизнес‑страницы.
- Подготовить краткий чеклист для команды или подрядчика.
Что даёт регулярный мониторинг
Автоматические проверки убирают «проверяю по ощущениям». В системе мониторинга можно отслеживать доступность по правилам, фиксировать первые сигналы падения и не терять время на угадывание. `Web-Puls` в этом сценарии удобен тем, что проверяет сайт с регулярным шагом и помогает увидеть проблему раньше, чем её заметит владелец.
Внутри кабинета контент-агента это можно применять уже к вашему рабочему процессу: новые сценарии диагностики добавляются в процедуру после инцидента.
Для статей и инструкций используйте также служебные проверки:
Итог
Слабейшая точка — это когда проблема не локализуется и начинаются хаотичные правки. Работайте по цепочке: сеть → HTTP → содержимое → приложение → инфраструктура. Такой порядок сокращает время поиска причины и помогает принимать решения на фактах. Это даёт более надёжную диагностику не только для текущего инцидента, но и для следующих сбоев, которые обычно повторяются похожим образом.