Перейти к основному содержимому

Руководства / Коды состояния HTTP: разбор

Коды состояния 5xx: когда проблема на стороне вашего сервера

Код состояния 5xx означает, что отказала ваша инфраструктура, а не запрос посетителя. Сервер принял запрос, понял его, а затем не смог сформировать валидный ответ, так что каждый 5xx на вашем сайте - это инцидент, за который отвечаете вы.

Что отличает 5xx от 4xx

RFC 9110 определяет 5xx как "Server Error": сервер осознает, что ошибся, либо неспособен выполнить запрошенный метод. В этом вся разница. 404 говорит "здесь ничего нет". 500 говорит "здесь что-то есть, и я сломался, пытаясь это отдать".

Отсюда следуют два вывода. Во-первых, 5xx обычно допускает повтор, потому что тот же самый запрос вполне может выполниться успешно секундой позже, как только отказавший компонент восстановится. Во-вторых, поисковые системы относятся к 5xx как к временному сигналу и снижают темп обхода, а не деиндексируют немедленно, тогда как устойчивый 5xx на протяжении дней в итоге все же стоит вам проиндексированных страниц.

Какой переход отказал

Читайте код 5xx как карту того, где запрос погиб. Почти на любом современном сайте перед приложением стоит хотя бы один прокси, поэтому код показывает, с какой стороны этой границы произошел сбой.

КодКто его выдалЧто произошло
500 Internal Server ErrorСамо приложениеНеобработанное исключение или непредвиденное состояние внутри приложения
501 Not ImplementedСерверМетод запроса вообще не поддерживается
502 Bad GatewayПрокси, CDN или балансировщик нагрузкиБэкенд ответил, но чем-то невалидным, либо закрыл соединение
503 Service UnavailableСервер или прокси, намеренноПерегружен либо на обслуживании и намеренно отказывает в работе
504 Gateway TimeoutПрокси, CDN или балансировщик нагрузкиБэкенд так и не ответил вовремя
505 HTTP Version Not SupportedСерверВерсия протокола в запросе не поддерживается

502, 503 и 504 несут наибольшую диагностическую ценность, поскольку каждый называет свой сбой одного и того же бэкенда: невалидный ответ, отклоненный ответ, отсутствие ответа. Руководство по 502 Bad Gateway подробно разбирает первый из них, включая строки лога прокси, определяющие точную неисправность.

Распространенные причины ответов 5xx

  • Падения приложения. Необработанное исключение, неудавшееся подключение к базе данных или значение null в неожиданном месте дают 500 на любых маршрутах, затрагивающих сломанный путь кода.
  • Процесс бэкенда не запущен. Остановленный сервер приложения, мертвый пул PHP-FPM или контейнер, провалившийся проверку здоровья, не дают прокси собеседника, что проявляется как 502.
  • Исчерпание ресурсов. Нехватка памяти, файловых дескрипторов, рабочих потоков или соединений с базой данных. Обычно начинается с прерывистых ошибок под нагрузкой, прежде чем стать постоянным.
  • Медленные зависимости. Медленный запрос, медленный сторонний API или холодный старт толкают время отклика за пределы таймаута прокси и превращаются в 504.
  • Деплои и перезапуски. Любое окно, когда старый процесс уже остановился, а новый еще не начал обслуживать запросы, дает всплеск 502 или 503.
  • Ошибки конфигурации. Неверный адрес вышестоящего сервера, плохая настройка TLS между прокси и бэкендом, либо несовпадение протокола, например обращение по HTTP к порту HTTPS.
  • Заполненный диск. Недооцененная причина. Логи или временные файлы заполняют том, сессии или кэши перестают записываться, и приложение начинает отказывать так, что это выглядит случайным.

Как разбирать 5xx

  1. Подтвердите код и его источник. Получите заголовки напрямую и посмотрите, какой компонент подписал ответ:
    curl -sS -o /dev/null -D - https://example.com/
    Заголовок Server: или заголовок CDN на ошибке покажет, сформировала ли ее граница сети или источник.
  2. Проверьте источник напрямую, в обход прокси. Если бэкенд отвечает 200 на своем собственном порту, пока публичный URL отвечает 502, проблема в слое прокси или в связи между ними двумя.
  3. Далее читайте лог ошибок прокси, а не лог приложения. Обратные прокси называют сбой точно, например connect() failed (111: Connection refused) или upstream timed out, что сразу отделяет "бэкенд лежит" от "бэкенд медленный".
  4. Затем читайте лог приложения. Для 500 стек-трейс - это ответ. Для 502 и 504 приложение часто вообще ничего не логирует, и само это отсутствие информативно.
  5. Проверьте ресурсы хоста. Память, диск, число соединений и насыщенность воркеров. Прерывистые 5xx под трафиком почти всегда означают достижение какого-то лимита.
  6. Посмотрите, что изменилось. Деплои, отправки конфигурации, продления сертификатов и обновления зависимостей объясняют большую долю внезапных вспышек 5xx.

Как поймать прерывистые ошибки 5xx

Ошибки 5xx часто прерывисты, из-за чего их сложно поймать вручную: страница, которую вы перезагружаете, работает, а та, что загружал ваш клиент, - нет. Плановая HTTP-проверка работает непрерывно и опрашивает сайт намного чаще, чем можете вы, так что череда ошибок становится видна как паттерн, а не как разрозненные жалобы. Проверка из многих локаций также отделяет настоящий сбой сервера от проблемы маршрутизации или границы сети, затрагивающей лишь часть мира, именно поэтому распределенный мониторинг доступности использует точки проверки, разбросанные по регионам, а не одну точку обзора. Если отказавший код оказывается 403, 404 или 429, значит запрос вообще не дошел до сломанного бэкенда, и правильная отправная точка - руководство по семейству 4xx.

Проверить сейчас

Запустите бесплатную проверку своего сайта - аккаунт не нужен.

HTTP check

Следить за этим постоянно

Получайте оповещение в момент сбоя: HostTracker проверяет более чем из 300 локаций и уведомляет по email, SMS, в Slack, Telegram и не только.

Возможности HostTracker

Ещё в этом разделе: Коды состояния HTTP: разбор