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

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

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

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

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

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

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

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

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

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

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

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

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

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