Какие HTTP коды ответов вы знаете и как они используются?

«Какие HTTP коды ответов вы знаете и как они используются?» — вопрос из категории Веб-серверы и балансировка, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

HTTP коды состояния — это ключевой инструмент для диагностики работы веб-сервисов и балансировщиков нагрузки. Вот основные, с которыми я постоянно работаю в контексте DevOps:

2xx (Успех):

  • 200 OK: Стандартный ответ на успешный GET, POST и т.д. Балансировщики (Nginx, ALB) считают такие ответы здоровыми (healthy) при проверках жизнеспособности (health checks).
  • 201 Created: Успешное создание ресурса (например, после POST).
  • 204 No Content: Успешный ответ, когда тело ответа не требуется (удаление, обновление). Часто используется для эндпоинтов health check, чтобы минимизировать трафик.

3xx (Перенаправление):

  • 301 Moved Permanently: Постоянный редирект. Важно для SEO и миграций. Балансировщики могут использовать для канонизации URL.
  • 302 Found: Временный редирект.

4xx (Ошибка клиента):

  • 400 Bad Request: Некорректный синтаксис запроса. В логах Nginx/ALB это может указывать на проблемы у клиента или на атаки.
  • 401 Unauthorized: Требуется аутентификация.
  • 403 Forbidden: Доступ запрещен (нет прав). Часто возникает при неправильной настройке WAF (Web Application Firewall) или политик IAM для S3.
  • 404 Not Found: Ресурс не найден. Высокий rate 404 может указывать на битые ссылки или сканирование уязвимостей.
  • 429 Too Many Requests: Клиент исчерпал лимит запросов (Rate Limiting). Часто возвращается приложениями или API-гейтвеями (например, Kong, NGINX с модулем limit_req).

5xx (Ошибка сервера): Наиболее критичны для DevOps.

  • 502 Bad Gateway: Балансировщик (Nginx, ALB) не получил корректный ответ от upstream-сервера (бэкенд упал, не запущен, таймаут). Первое, что проверяю при таком алерте.
  • 503 Service Unavailable: Сервис временно недоступен (например, при плановом обслуживании, graceful shutdown или перегрузке). Можно информировать клиента заголовком Retry-After.
  • 504 Gateway Timeout: Балансировщик не дождался ответа от upstream за отведенное время (proxy_read_timeout в Nginx). Указывает на проблемы с производительностью бэкенда.

В мониторинге я настраиваю алерты на рост rate кодов 5xx и 429, так как они напрямую сигнализируют о проблемах с доступностью и производительностью.