Ошибки HTTP 500, 502 и 503

Что означает HTTP 500

HTTP 500 Internal Server Error означает, что сервер получил запрос, но приложение не смогло его корректно обработать. Это общий статус для внутренних ошибок: исключение в коде, неправильная конфигурация, ошибка подключения к базе, недоступный внешний API, проблема с правами на файлы или несовместимость после деплоя.

Начинать диагностику 500 нужно с логов приложения. Важно смотреть не только сам stack trace, но и контекст: какой URL вызвал ошибку, какой пользовательский сценарий был затронут, был ли перед этим деплой, миграция базы, изменение переменных окружения или обновление зависимостей.

• проверьте error logs backend-приложения
• сопоставьте ошибку с последним деплоем
• проверьте подключение к базе данных и внешним API
• посмотрите, возникает ли 500 на всех URL или только на части страниц

Что означает HTTP 502

HTTP 502 Bad Gateway обычно появляется на уровне прокси, балансировщика или gateway. Например, nginx принял запрос от пользователя, попытался передать его приложению, но upstream не ответил корректно. Это может быть падение контейнера, неправильный порт, timeout, ошибка DNS внутри docker-сети или несовместимый ответ от приложения.

При 502 полезно проверить цепочку: пользователь → CDN или Caddy/nginx → backend → база и внешние зависимости. Если приложение не слушает порт, перезапускается, зависло на старте или отдаёт некорректный ответ, прокси часто покажет именно 502.

• проверьте статус контейнера или процесса приложения
• убедитесь, что upstream слушает нужный порт
• посмотрите логи nginx, Caddy или другого reverse proxy
• проверьте timeout между proxy и приложением

Что означает HTTP 503

HTTP 503 Service Unavailable говорит, что сервис временно недоступен. Это может быть осознанный maintenance mode, перегрузка, исчерпанный пул соединений, лимит хостинга, очередь запросов, недоступность базы данных или остановленный backend. В отличие от 500, 503 часто связан не с ошибкой конкретного запроса, а с состоянием сервиса в целом.

Если 503 появляется во время пиков нагрузки, проверьте CPU, RAM, диск, количество соединений, очереди задач и лимиты web-сервера. Если 503 появился после релиза, проверьте healthcheck, readiness, миграции и запуск приложения.

• проверьте нагрузку сервера и лимиты
• посмотрите readiness/healthcheck приложения
• проверьте пул подключений к базе данных
• оцените, не включён ли maintenance mode

Почему важно смотреть частоту и длительность 5xx

Одна ошибка 500 в логах может быть пользовательским edge case. Серия 5xx за несколько минут — уже инцидент. Для сайта важны не только коды, но и количество затронутых запросов, длительность, время восстановления и повторяемость по дням.

Мониторинг HTTP-статусов помогает увидеть проблему снаружи, а не только в логах. Это важно, потому что backend может логировать ошибку, но команда узнает о ней поздно. Внешняя проверка фиксирует то, что видит пользователь: статус, доступность и задержку ответа.

• смотрите серию ошибок, а не одиночный статус
• разделяйте критичные страницы и второстепенные URL
• сравнивайте 5xx с деплоями и нагрузкой
• фиксируйте время восстановления

Как построить диагностику 500, 502 и 503

Удобный порядок диагностики такой: сначала проверить внешний HTTP-статус и TTFB, затем открыть логи proxy, потом логи приложения, после этого посмотреть метрики сервера и базы данных. Если ошибка появилась после релиза, отдельно проверьте миграции, конфигурацию и переменные окружения.

Не стоит ограничиваться перезапуском сервиса. Перезапуск может временно убрать симптом, но не объяснит причину. Если ошибка повторяется, нужна история: когда началась, сколько длилась, какой статус был первым, какие метрики изменились рядом с инцидентом.

• внешний checker показывает, что видит пользователь
• логи proxy помогают понять проблему с upstream
• логи приложения показывают внутреннюю ошибку
• серверные метрики объясняют перегрузку и деградацию

Как снизить риск повторения 5xx

После устранения ошибки стоит превратить разбор в профилактику. Для 500 полезны тесты критичных сценариев, проверка миграций и валидация конфигурации перед деплоем. Для 502 важны healthcheck приложения, корректные readiness-проверки и понятные таймауты между proxy и upstream. Для 503 нужны лимиты, очереди, контроль ресурсов и graceful degradation.

Мониторинг помогает увидеть, сработала ли профилактика. Если после исправления 5xx исчезли, но TTFB остался высоким, проблема решена не полностью. Если ошибка вернулась в тот же час или при той же нагрузке, нужно смотреть глубже: базу, фоновые задачи, внешние API и ресурсные ограничения.

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

• добавьте healthcheck и readiness для backend
• проверяйте миграции и конфигурацию до релиза
• смотрите не только 5xx, но и TTFB после исправления
• разбирайте повторяющиеся ошибки как системную проблему