Когда сайт перестаёт работать, причина часто ощущается как чёрный ящик. Посетители видят крутящийся индикатор, загадочный код ошибки или пустую страницу. Для людей, отвечающих за поддержание сайта в сети, первый вопрос всегда один и тот же: что сломалось?
Правда в том, что нет одного единственного способа, как сайт «падает». Запрос от браузера проходит через несколько шагов — разрешение DNS, подключение по TCP, согласование TLS и ответ HTTP. Каждый шаг зависит от предыдущего. И на каждом шаге может произойти разный сбой.
Именно поэтому умный мониторинг доступности не просто сообщает, что сайт «вне сети». Он говорит вам, где в цепочке произошёл сбой. Ошибки DNS указывают на одно. Ошибки TCP — на другое. Ошибки TLS/SSL свидетельствуют о другой коренной причине, чем HTTP 5xx. Если вы знаете, какой уровень отказал, вы знаете, к какой команде или провайдеру обращаться, и можете существенно сократить время на устранение.
В этой статье рассмотрены все типы ошибок в том порядке, в котором браузер действительно загружает сайт: DNS, TCP, TLS и HTTP. Для каждого мы объясним, что делает шаг, что может пойти не так и как мониторинг может поймать проблемы прежде, чем их заметят ваши клиенты.
Ошибки DNS
DNS — это место, с которого начинается любой веб-запрос. Когда пользователь вводит ваш домен в браузере, первым делом происходит запрос для разрешения этого домена в IP-адрес. Если этот шаг терпит неудачу, всё остальное теряет смысл — соединение не может быть установлено, сертификат не может быть проверен и HTTP-ответ никогда не придёт. Поэтому ошибки DNS часто являются самыми ранними и самыми критичными сигналами отказа.
Типичные ошибки DNS
Ниже перечислены некоторые распространённые сбои DNS:
- NXDOMAIN — это означает, что доменное имя просто не существует. На практике это обычно связано с истёкшей регистрацией, неправильно настроенными зонами или опечатками в записях. Истёкший домен может мгновенно вывести весь сайт из сети, тогда как ошибочно введённая запись может повлиять только на один поддомен или сервис.
- SERVFAIL — ошибка сервера, указывающая на то, что авторитетный DNS-сервер не смог обработать запрос. Часто это говорит о повреждённых файлах зон, отсутствующих glue-записях или проблемах валидации DNSSEC. SERVFAIL часто появляются внезапно после изменений конфигурации, поэтому они служат полезным ранним предупреждением о проблемных деплоях.
- Таймауты — когда в ожидаемые сроки не приходит ответ, клиент в конце концов сдаётся. Таймауты часто вызываются перегруженными именными серверами, сбоями сети или DDoS-атаками, насыщенными резолвер. Поскольку DNS-запросы происходят до вступления в действие кэша, даже небольшие всплески задержки здесь могут привести к более медленной загрузке страниц у вашей аудитории.
Как мониторить DNS
Мониторинг состояния DNS выходит за рамки простого однократного теста разрешения домена. Нужно проверять пути разрешения так, как их испытывают реальные пользователи:
- Глобальные проверки: агенты синтетического мониторинга должны выполнять DNS-запросы из множества географий и сетей. Запись может корректно разрешаться из вашего офиса, но падать в Азии или Южной Америке из-за проблем anycast-маршрутизации или региональных сбоев у провайдера.
- Учет TTL: у каждой записи есть значение time-to-live (TTL), контролирующее кэширование. Длинные TTL ускоряют обычный просмотр, но могут замедлить распространение изменений. Мониторинг должен проверять, что новые значения действительно отражаются в живых запросах и что устаревший кэш не сохраняется.
- Оповещения об аномалиях: наиболее полезные сигналы приходят из трендов. Внезапный всплеск ответов NXDOMAIN или SERVFAIL или пик задержки разрешения часто является первой подсказкой о проблеме — ещё до того, как клиенты начнут жаловаться.
Когда мониторинг DNS даёт сбой, он также даёт уверенность в том, что не является проблемой. Если запросы не разрешаются, то проверки TCP, TLS и HTTP даже не выполнялись. Это быстро сужает круг поиска. В большинстве случаев исправления касаются вашего DNS-хостинга, регистратора или того, кто управляет файлом зоны. Зрелые команды выстраивают отношения и пути эскалации с этими поставщиками, чтобы проблемы можно было быстро поднять и решить.
Сбои TCP-подключения
После того как DNS разрешил IP-адрес, следующий шаг — TCP-хендшейк. Это цифровой эквивалент рукопожатия: клиент отправляет SYN, сервер отвечает SYN-ACK, и клиент подтверждает ACK. Только после этого обмена устанавливается канал связи.
Если TCP терпит неудачу, браузер знает, где должен быть сервер, но не может с ним говорить. Результат ощущается как чёрная дыра — страницы зависают, сокеты не открываются, и пользователи видят бесконечные крутилки. В отличие от ошибок DNS, которые обычно быстры и очевидны, сбои TCP часто создают запутанные частичные простои, когда сайт доступен для одних пользователей, но недоступен для других.
Типичные TCP-ошибки
- Connection refused — клиент дошёл до хоста, но на ожидаемом порту ничего не слушает. Это часто происходит, когда сервисы падают, контейнеры завершают работу или балансировщики нагрузки неправильно сконфигурированы. Веб-сервер, забывший привязать порт 443, невидим даже при нормальной работе машины.
- Connection timed out — пакеты теряются где-то по пути. Это может быть брандмауэр, тихо блокирующий трафик, ошибка маршрутизации или перегрузка у провайдера. Таймауты особенно раздражают, потому что не дают обратной связи — только тишина, пока клиент не сдастся.
- Connection reset — хендшейк завершается, но соединение тут же разрывается. Сбросы обычно указывают на перегруженные прокси, агрессивные таймауты простоя или промежуточные устройства (например, WAF), которые разрывают сессии, считая их подозрительными.
Как мониторить TCP
Простейшие проверки доступности здесь недостаточны. ICMP-пинги могут проходить, в то время как TCP-хендшейки падают, создавая ложное ощущение здоровья системы. Правильный TCP-мониторинг сосредоточен на поведении подключения:
- Проверка хендшейка: инструменты должны явно пытаться выполнить обмен SYN/SYN-ACK/ACK на реальном порту сервиса. Это гарантирует, что слушатель доступен и отвечает.
- Анализ пути: traceroute или MTR из разных регионов могут показать, где затыкаются соединения — внутри вашего дата-центра, на краю CDN или у верхнего ISP.
- Паритет протоколов: если вы поддерживаете IPv4 и IPv6, мониторьте оба. Многие реальные инциденты касаются только одного из протоколов, создавая видимые проблемы для клиентов, которые проскальзывают, если тестируется только другой.
TCP-мониторинг даёт уверенность, что серверы не просто «живы», но и готовы принимать трафик. И он сужает круг поиска: если TCP падает, DNS-разрешение уже прошло, значит проблема в хосте или сетевом пути. Такая ясность не позволяет командам гнаться за ложными следами в слое приложения, когда реальная причина — правило брандмауэра или пул балансировщика, который тихо потерял последний здоровый узел.
Ошибки TLS/SSL
Сегодня почти все сайты работают по HTTPS (в отличие от прошлых лет, когда SSL-защищённые сайты были менее распространены). Это означает, что после TCP-хендшейка браузер и сервер должны согласовать TLS-сессию (Transport Layer Security). TLS выполняет две задачи одновременно: шифрует данные в пути и подтверждает, что сервер — это тот, за кого он себя выдаёт, с помощью цифровых сертификатов.
Это доверие приносит с собой сложность. Если сертификаты истекли, не соответствуют имени хоста или не могут быть валидированы, пользователи увидят предупреждения браузера — или страница вообще откажется загружаться. На практике ошибки TLS — одни из самых заметных и постыдных инцидентов, потому что они останавливают пользователя у входа, показывая предупреждение, которое нельзя безопасно обойти.
Типичные ошибки TLS/SSL:
- Истёкший сертификат — срок действия сертификата истёк. Это один из самых частых видов простоев, потому что нет автоматизации или обновление не распространилось повсеместно.
- Несоответствие имени хоста — сертификат выдан для www.example.com, а пользователь посетил api.example.com. Такое часто происходит после добавления новых поддоменов или переноса сервисов за CDN.
- Ненадёжный центр сертификации (CA) — браузер не распознаёт выдавшую CA, обычно потому, что сертификат самоподписан или связан с приватным корневым сертификатом, не установленным на устройствах клиентов.
- Сбой хендшейка — криптографическая переговорка не проходит. Причины варьируются от неподдерживаемых наборов шифров, устаревших версий протоколов до повреждённой цепочки сертификатов.
Как мониторить TLS:
TLS-мониторинг должен быть проактивным и непрерывным. Сертификаты не «ломаются» постепенно — один день они работают, а на следующий блокируют доступ. Хороший мониторинг должен:
- Отслеживать срок действия сертификатов и подавать тревогу задолго до истечения — желательно с несколькими порогами (30 дней, 7 дней, 1 день).
- Проверять полную цепочку сертификатов из нескольких регионов, так как отсутствие промежуточных сертификатов или региональные проблемы с CA могут по-разному ломать доверие в разных частях мира.
- Проверять поддержку протоколов и наборов шифров, чтобы сайт оставался совместимым по мере того, как браузеры отказываются от старых версий, таких как TLS 1.0 и 1.1.
- Следить за всплесками ошибок хендшейка, которые часто совпадают с неправильной конфигурацией балансировщика или развёртыванием в CDN.
Когда в мониторинге появляются сбои TLS, они также дают контекст: DNS-разрешение прошло, TCP-связь была в порядке, но безопасный канал не удалось установить. Это сразу сужает область поиска. Исправление обычно связано с обновлением сертификатов, конфигурацией балансировщика или терминсацией на краю, а не с кодом приложения.
Для многих команд операционный урок прост: относитесь к сертификатам как к коду. Автоматизируйте выдачу и обновление, мониторьте срок действия так же агрессивно, как мониторите диск, и репетируйте ротации, чтобы истекающие сертификаты не превращались в серьёзные публичные простои.
HTTP-ошибки
Наконец, после успешных DNS, TCP и TLS браузер отправляет HTTP-запрос. Сервер отвечает HTTP-статусом — 200, если всё в порядке, или кодом ошибки, если нет.
Мониторинг HTTP — то, о чём большинство людей думает, говоря «мониторинг доступности». Но без контекста предыдущих шагов HTTP-ошибки рассказывают лишь часть истории.
Типичные HTTP-ошибки:
- 404 Not Found – ресурс не найден. Это может быть битая ссылка, удалённая страница или неверно маршрутизированный запрос.
- 500 Internal Server Error – сервер столкнулся с непредвиденным состоянием. Обычно это баги в коде или конфигурации.
- 502 Bad Gateway – прокси или балансировщик не смог получить корректный ответ от upstream-сервера.
- 503 Service Unavailable – сервер перегружен или на обслуживании.
- 504 Gateway Timeout – upstream-сервис слишком долго формировал ответ.
Как мониторить HTTP:
- Запускайте синтетические GET-запросы с глобальных агентов для проверки ответов.
- Фиксируйте коды ответов и оповещайте при любых значениях вне диапазона 200–299.
- Мониторьте рабочие сценарии, а не только отдельные страницы (вход в систему, затем добавление в корзину, затем оформление заказа).
- Устанавливайте пороги по времени ответа, а не только по доступности.
HTTP-мониторинг сигнализирует, что слой приложения сломан. В отличие от проблем DNS/TCP/TLS, HTTP-ошибки зачастую находятся в зоне ответственности команд разработки или эксплуатации, а не внешних провайдеров.
Соединяя воедино: многоуровневая стратегия мониторинга ошибок
Ценность разбиения ошибок по типам — это ясность. Каждый отказ происходит в последовательности. Если DNS ломается, ничего дальше не происходит. Если TCP ломается, DNS был в порядке. Если TLS ломается, DNS и TCP работали. Если HTTP ломается, все предыдущие шаги прошли успешно.
Многоуровневый подход к мониторингу отражает эту последовательность:
- Начните с проверок DNS.
- Добавьте мониторинг TCP-соединений.
- Наложите мониторинг сертификатов TLS.
- Завершите мониторингом HTTP-ответов.
Эта модель по уровням позволяет быстро определить коренную причину:
- Ошибка DNS? Свяжитесь с вашим DNS-провайдером.
- Ошибка TCP? Подключите хостинг или ISP.
- Ошибка TLS? Исправьте сертификат или конфигурацию на краю.
- Ошибка HTTP? Обратитесь к вашей веб-команде.
Вместо расплывчатого оповещения «сайт недоступен» вы получаете точную карту того, что сломано и кто должен это исправить. Это снижает среднее время восстановления (MTTR) и предотвращает взаимные обвинения между командами.
Заключение
Сайты не падают каким-то одним единственным образом — они падают по слоям. DNS, TCP, TLS и HTTP вносят каждый свои риски и свои подписи ошибок. Мониторинг по типу ошибки превращает эту сложность в ясность.
С правильной стратегией мониторинга (и инструментом вроде Dotcom-Monitor) вы не только узнаёте, что сайт упал — вы понимаете, почему он упал. Вы понимаете, следует ли эскалировать к вашему DNS-хосту, сетевому провайдеру, команде безопасности или разработчикам. И вы получаете это понимание быстро, не ожидая тикета в саппорт или жалобы клиента.
В конце концов, мониторинг по типу ошибок — это не только про доступность. Это про ответственность и скорость. В следующий раз, когда ваш сайт сломается, не соглашайтесь на «что-то сломалось». Узнайте точно, какой слой отказал, что это значит и как это исправить.