Ошибки сайтов: типы, причины и как диагностировать

Что такое ошибка сайта и почему важно различать её уровни

Пользователь видит «сайт не открывается» и закрывает вкладку. Технический специалист видит ту же картину, но за ней может стоять истёкший сертификат, неверная DNS-запись, закрытый порт или исключение в коде приложения. Это четыре разные проблемы, четыре разных виновника и четыре разных способа починки.

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

Ошибка сайта vs недоступность сайта: в чём разница

Ошибка — это конкретный сигнал на конкретном уровне: код ответа, отказ в TLS-соединении, отсутствие DNS-записи, таймаут на порту. Это симптом, а не причина. Код 500 говорит, что сервер не смог обработать запрос, но не говорит, почему: упал процесс, кончилась память или ошибка в конфигурации.

Недоступность — крайний случай, когда сайт не открывается вообще. У неё всегда есть источник: домен, сеть, сервер или приложение. Поэтому фраза «сайт не открывается» — это ещё не диагноз, а только начало разбора. Подробнее о том, как отделить проблему сервера от проблемы приложения, — в материале почему сайт не открывается, хотя сервер работает.

Клиент, сервер и инфраструктура: три источника проблем

Проблемы удобно раскладывать на три группы по источнику.

• Клиент. Браузер, устройство, локальная сеть или провайдер пользователя. Часто «ошибка» воспроизводится только у одного человека и не видна из других точек.
• Сервер. Приложение, его конфигурация, нехватка ресурсов. Сюда относятся коды 5xx, падения процессов, ошибки в коде.
• Инфраструктура. DNS, SSL, порты, домен. Сайт может быть полностью исправен, но недоступен из-за истёкшего сертификата или просроченной регистрации.

Категории ошибок сайта

HTTP-коды: язык ответов сервера

HTTP-коды делятся на группы по первой цифре. 1xx — информационные, 2xx — успех, 3xx — перенаправления, 4xx — ошибки на стороне клиента, 5xx — ошибки на стороне сервера. Для диагностики важны две последние группы.

Распространённые 4xx:

• 400 — некорректный запрос.
• 401 — требуется авторизация.
• 403 — доступ запрещён (авторизация есть, прав нет).
• 404 — ресурс не найден.
• 429 — слишком много запросов, сработал лимит.

Распространённые 5xx:

• 500 — внутренняя ошибка сервера.
• 502 — неверный ответ от вышестоящего сервера (часто прокси не дождался бэкенда).
• 503 — сервис недоступен (перегрузка или обслуживание).
• 504 — таймаут шлюза.

Код — это первый ориентир, но не приговор. Один и тот же 502 может означать и упавший процесс, и неверную конфигурацию прокси.

SSL-ошибки: когда браузер блокирует сайт

SSL-ошибки полностью блокируют доступ: браузер показывает предупреждение и не даёт открыть страницу без ручного подтверждения. Причины:

• истёкший сертификат;
• сертификат выписан на другой домен (несоответствие имени);
• не выстраивается цепочка доверия (не хватает промежуточного сертификата);
• устаревшая версия TLS или небезопасный шифр.

Именно поэтому срок действия сертификата — параметр, который нужно держать под контролем постоянно, а не вспоминать о нём, когда пользователи уже пишут в поддержку. Как это устроить — в статье как настроить SSL-мониторинг.

DNS-ошибки: сайт «не существует» для пользователя

Если DNS-запись отсутствует или неверна, для пользователя сайта буквально не существует: браузер не знает, на какой адрес идти. Типичные причины:

• отсутствующие или неверные записи A/AAAA/CNAME;
• просроченный домен;
• проблемы делегирования на уровне NS-серверов.

Отличить DNS-проблему от проблемы сервера помогает простой признак: если имя не резолвится, до сервера дело не доходит вовсе. Подробный разбор — в руководстве по DNS-мониторингу.

TCP и Ping: сетевой уровень

TCP-проверка показывает, открыт ли порт и сколько времени занимает соединение. Закрытый порт, таймаут соединения, недоступный хост — всё это сетевой уровень, который находится ниже HTTP и SSL.

Ping (ICMP) показывает, доступен ли хост на сетевом уровне и каков RTT, а также потерю пакетов. Важно понимать ограничение: ICMP-ответ говорит, что хост отвечает, но ничего не говорит о том, работает ли на нём приложение. Хост может пинговаться и при этом отдавать 500 на все запросы.

WHOIS и SEO-ошибки: скрытые категории

Истечение срока домена — отложенная катастрофа. Пока домен активен, всё работает; в момент истечения сайт пропадает целиком. Это редкая, но критичная причина, которую проще предотвратить, чем расследовать.

SEO-ошибки (проблемы с мета-тегами, ключевыми словами) сайт не блокируют, но вредят видимости в поиске. Их стоит держать в отдельной категории: это не сбой доступности, а деградация качества.

Как последовательно диагностировать ошибку

Принцип «снизу вверх»: DNS → TCP → SSL → HTTP

Порядок важен, потому что каждый следующий уровень зависит от предыдущего. Нет смысла проверять HTTP-код, если имя не резолвится: запрос просто не дойдёт до сервера.

1. DNS. Резолвится ли имя? Если нет — проблема здесь, дальше идти незачем.
2. TCP. Открыт ли порт, устанавливается ли соединение? Если нет — проблема в сети или на порту.
3. SSL. Устанавливается ли TLS-соединение, валиден ли сертификат? Если нет — браузер заблокирует доступ.
4. HTTP. Какой код возвращает сервер, за какое время, есть ли редиректы?

Такая последовательность отсекает уровни один за другим и быстро сужает круг виновников. В Pulsora расширенная диагностика HTTP проходит именно в этом порядке — DNS → TCP → SSL — чтобы найти причину сбоя. А интерактивные пояснения по типам ошибок помогают разобраться, что означает конкретный код.

Как отличить разовую ошибку от системного сбоя

Единичный сбой и повторяющаяся ошибка требуют разной реакции. Разовая ошибка — это, например, один таймаут при всплеске нагрузки. Системный сбой — это повторяющийся код 500, который воспроизводится снова и снова.

Отличить одно от другого помогает история инцидентов и статистика аптайма. Если ошибка повторяется, это видно в истории сбоев и их длительности, а также в графиках аптайма и времени отклика, P95, MTTR и MTBF за любой период. Это напрямую влияет на приоритет: разовый сбой можно зафиксировать и наблюдать, системный требует немедленного вмешательства.

Как узнавать об ошибках раньше пользователей

Мониторинг по типу ошибки

Разные категории ошибок ловятся разными проверками. Ниже — соответствие типа ошибки и проверки, которая её обнаруживает.

HTTP-мониторинг проверяет доступность, коды ответа и время загрузки, а также цепочку редиректов и заголовки. В HTTP-мониторе можно задать ключевое слово — проверка сообщит, найдено ли оно в содержимом страницы. Это помогает заметить подмену контента или ошибку рендеринга.

SSL-мониторинг отслеживает издателя, срок действия, версию TLS и шифр и уведомляет об истечении. DNS-мониторинг проверяет записи A, AAAA, MX, NS, TXT, CNAME с TTL и временем ответа. TCP-мониторинг проверяет порты, время соединения и баннер сервера. Ping-мониторинг даёт ICMP-проверку доступности, RTT и потерю пакетов. WHOIS-мониторинг отслеживает дату истечения домена, регистратора и NS-серверы. SEO-мониторинг анализирует мета-теги страницы.

Отдельно стоит скорость: замер времени ответа сервера, графики и динамика помогают заметить деградацию до того, как она превратится в ошибку. О причинах медленной загрузки — в материале почему сайт медленно загружается.

Оповещения и скорость обнаружения

Скорость обнаружения сбоя зависит от интервала проверки. Сбой обнаруживается в пределах интервала: при текущем интервале 15 секунд — не позже 15 секунд после начала сбоя. Интервал задаётся отдельно для каждого монитора.

Оповещения приходят на email и в Telegram. Можно настроить правила доставки и эскалации при необработанных событиях, а также выбрать, по каким типам мониторов присылать уведомления.

При массовых сбоях помогает публичная страница статуса с realtime-обновлениями и настраиваемым адресом: пользователи видят, что проблема известна, и не пишут в поддержку. А режим обслуживания на время плановых работ не даёт рассылать ложные тревоги.

Важно понимать роль сервиса: Pulsora — наблюдатель. Он не влияет на доступность сайта и не может её гарантировать. Сервис замечает сбой и сообщает о нём в пределах интервала проверки, а доступность своего сайта обеспечивает сам владелец. О том, как выстроить этот процесс, — в статье как узнать о сбое раньше клиента.

Что можно предотвратить, а что — только быстро обнаружить

Часть ошибок предотвращается заранее: продление домена и сертификата, контроль конфигурации, проверка DNS-записей до переключения. Здесь мониторинг работает как напоминание и страховка.

Другую часть предотвратить нельзя — внезапные сбои приложения, сетевые аварии, всплески нагрузки. Их можно только быстро обнаружить и сократить время реакции. Именно для этого нужны история инцидентов и аналитика: они показывают, как часто проблема повторяется и сколько времени занимает восстановление.

Практический старт: проверьте сайт прямо сейчас

Первый шаг при разборе ошибки — диагностика. В Pulsora есть бесплатная проверка без регистрации: мгновенная диагностика по HTTP, SSL, DNS, TCP, Ping, SEO и WHOIS без создания аккаунта. Это быстрый способ понять, на каком уровне проблема, — см. также бесплатная проверка сайта без регистрации.

Дальше стоит настроить мониторинг под те типы ошибок, которые для вас критичны: HTTP-коды и время загрузки, срок действия сертификата, DNS-записи, порты, доступность хоста, дату истечения домена. Каждый монитор настраивается отдельно, а уведомления приходят на email и в Telegram.

Сейчас в период раннего доступа все возможности — мониторинг, уведомления, статус-страницы и аналитика — доступны бесплатно. Промо-лимиты: 100 сайтов, 500 мониторов, 20 status pages, 50 каналов уведомлений, 25 участников организации, интервал проверки от 15 секунд, история 365 дней.

Подключите мониторинг и получайте оповещения раньше пользователей — чтобы разбирать ошибку по факту, а не по жалобам.

Часто задаваемые вопросы