Какие коды ответа мы получаем от веб-сервера

Коды состояния HTTP от веб-сервера

Коды состояния HTTP (HTTP Status Codes) — это стандартизированные трехзначные числа, которые веб-сервер возвращает клиенту (браузеру, мобильному приложению, другой службе) в ответ на его запрос. Они являются неотъемлемой частью протокола HTTP и служат для информирования клиента о результате обработки его запроса. С точки зрения DevOps Engineer, понимание этих кодов критически важно для мониторинга, отладки, обеспечения отказоустойчивости и построения эффективных пайплайнов CI/CD.

Коды сгруппированы по первой цифре в пять классов:

1xx: Информационные коды (Informational)

Эти коды указывают, что запрос получен и обработка продолжается. Они отправляются до финального ответа.

• 100 Continue: Сервер получил заголовки запроса, клиент может продолжать отправлять тело запроса.
• 101 Switching Protocols: Сервер согласен сменить протокол (например, на WebSocket).

2xx: Коды успеха (Success)

Запрос был успешно получен, понят и обработан.

• 200 OK: Стандартный ответ на успешные GET, PUT или POST запросы. Тело ответа содержит запрошенные данные.

  curl -I https://api.example.com/resource
  # HTTP/2 200
  # content-type: application/json
  

• 201 Created: Запрос выполнен, в результате создан новый ресурс (часто в ответ на POST). Ответ должен содержать заголовок Location с URI нового ресурса.
• 202 Accepted: Запрос принят на обработку, но обработка еще не завершена (асинхронные операции).
• 204 No Content: Сервер успешно обработал запрос, но в ответе нет содержимого (например, после успешного DELETE).

3xx: Коды перенаправления (Redirection)

Для завершения запроса требуются дополнительные действия.

• 301 Moved Permanently: Ресурс навсегда перемещен на новый URI. Все последующие запросы должны использовать новый адрес.
• 302 Found (или 307 Temporary Redirect): Ресурс временно доступен по другому URI.
• 304 Not Modified: Используется для кеширования. Клиент уже имеет актуальную версию ресурса (на основании заголовков If-Modified-Since, ETag), и сервер указывает не отправлять данные повторно.

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

Запрос содержит ошибку (неправильный синтаксис, неавторизованный доступ, несуществующий ресурс).

• 400 Bad Request: Сервер не может обработать запрос из-за некорректного синтаксиса (например, невалидный JSON в теле POST).

  {"error": "Invalid request body: expected field 'username' of type string"}
  

• 401 Unauthorized: Для доступа к ресурсу требуется аутентификация. Клиент должен предоставить корректные учетные данные.
• 403 Forbidden: Сервер понял запрос, но отказывается его авторизовать (нет прав, IP заблокирован).
• 404 Not Found: Наиболее известный код. Запрашиваемый ресурс не найден на сервере.
• 429 Too Many Requests: Клиент отправил слишком много запросов за заданный период времени (rate limiting). Важно для защиты от DDoS и обеспечения fairness.

5xx: Ошибки сервера (Server Error)

Сервер не смог выполнить корректный запрос из-за внутренней ошибки. Для DevOps это наиболее критичная группа, требующая немедленного реагирования.

• 500 Internal Server Error: Общая ошибка сервера, когда иная, более специфичная ошибка 5xx не подходит (например, необработанное исключение в коде приложения).
• 502 Bad Gateway: Сервер, выступающий в роли шлюза или прокси, получил недействительный ответ от вышестоящего сервера (частая проблема с балансировщиками нагрузки или бэкенд-сервисами).
• 503 Service Unavailable: Сервер временно не может обработать запрос из-за перегрузки или планового технического обслуживания. Ответ может включать заголовок Retry-After.
• 504 Gateway Timeout: Шлюз или прокси не дождался ответа от вышестоящего сервера в отведенное время.

Практическое значение для DevOps

1. Мониторинг и алертинг: Настройка систем мониторинга (Prometheus, Grafana, Datadog) на отслеживание rate кодов 4xx и, особенно, 5xx. Рост 5xx ошибок — прямой сигнал к инциденту.
2. Логирование и анализ (ELK Stack, Loki): Детальный анализ логов с кодами состояния помогает выявлять паттерны сбоев, проблемы пользователей и уязвимости.
3. Настройка балансировщиков нагрузки (Nginx, HAProxy, AWS ALB): Балансировщики должны правильно обрабатывать коды состояния от бэкендов (например, исключать инстанс из ротации при 503) и сами возвращать корректные коды (504 при таймауте).
4. Resilience и Retry Logic: При проектировании взаимодействия микросервисов важно понимать, на какие коды имеет смысл повторять запрос (503 с Retry-After, 429), а какие указывают на фатальную ошибку (400, 404).
5. Тестирование и CI/CD: Написание интеграционных и E2E-тестов должно включать проверку ожидаемых HTTP-кодов ответа для различных сценариев.

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