Какие знаешь HTTP статус-коды?

Обзор HTTP статус-кодов

HTTP статус-коды — это стандартизированные трехзначные числа, которые сервер возвращает клиенту (например, браузеру или вашему приложению) в ответ на его запрос. Они являются фундаментальной частью протокола HTTP и служат для мгновенного информирования о результате операции. Понимание этих кодов критически важно для DevOps-инженера, так как они являются первичным инструментом диагностики проблем в веб-инфраструктуре, API и микросервисах.

Статус-коды разделены на пять классов, обозначаемых первой цифрой:

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

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

• 100 Continue: Сервер удовлетворен начальной частью запроса, клиент может продолжать отправлять оставшееся тело запроса (используется, например, при отправке больших файлов).
• 101 Switching Protocols: Сервер соглашается сменить протокол, как запросил клиент (например, переход с HTTP/1.1 на WebSocket).

2xx: Успешные (Success)

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

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

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

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

• 301 Moved Permanently 🔄: Запрошенный ресурс был навсегда перемещен на новый URI. Все будущие запросы должны использовать новый адрес.
• 302 Found (или Moved Temporarily) 🔄: Ресурс временно находится по другому URI. Клиент должен использовать исходный URI для будущих запросов.
• 304 Not Modified: Используется для кэширования. Если клиент выполнил условный GET (с заголовками If-Modified-Since или If-None-Match), и ресурс не изменился, сервер возвращает этот код без тела ответа.

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

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

• 400 Bad Request 🔴: Сервер не может обработать запрос из-за синтаксической ошибки клиента (невалидный JSON, некорректные параметры).
• 401 Unauthorized 🔐: Для доступа к ресурсу требуется аутентификация, и она не предоставлена или не прошла.
• 403 Forbidden ⛔: Сервер понял запрос, но отказывается его авторизовать. Доступ запрещен, даже при наличии аутентификации (недостаточно прав).
• 404 Not Found ❌: Сервер не нашел запрошенный ресурс. Самый известный статус-код.
• 429 Too Many Requests 🚦: Клиент отправил слишком много запросов за короткое время (реализация rate limiting). Часто содержит заголовок Retry-After.

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

Сервер не смог выполнить заведомо корректный запрос. Проблема на стороне сервера — это прямой сигнал для DevOps-инженера.

• 500 Internal Server Error 💥: Общий код на случай непредвиденной ошибки сервера, когда нет более подходящего сообщения. Частая причина — необработанное исключение в коде приложения.
• 502 Bad Gateway 🚧: Сервер, выступая в роли шлюза или прокси, получил недействительный ответ от вышестоящего сервера. Классическая проблема при падении upstream-сервера (например, бэкенда за nginx).
• 503 Service Unavailable 🛑: Сервер временно не может обрабатывать запросы из-за перегрузки или планового технического обслуживания. Клиенту может быть предложено повторить попытку позже.
• 504 Gateway Timeout ⏰: Сервер, выступая в роли шлюза или прокси, не дождался своевременного ответа от вышестоящего сервера.

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

Для DevOps-инженера эти коды — не просто теория. Мы работаем с ними ежедневно:

• Мониторинг и алертинг: Настраиваем системы (Prometheus, Grafana, ELK) для отслеживания rate ошибок 5xx и 4xx. Резкий рост 5xx — срочный инцидент, рост 4xx — возможная проблема в клиентском приложении.
• Настройка балансировщиков (Nginx, HAProxy): Определяем, какие статусы считать "успешными" для проверки здоровья бэкенда (health check). Обычно это 2xx и 3xx.

  # Пример health check в Nginx
  location /health {
      proxy_pass http://backend;
      proxy_intercept_errors on;
      error_page 500 502 503 504 =200 /unhealthy;
  }
  

• Анализ логов: Фильтруем логи веб-сервера по кодам состояния для поиска проблем.

  # Поиск всех 5xx ошибок в access.log Nginx
  tail -f /var/log/nginx/access.log | grep ' 5[0-9][0-9] '
  

• Дизайн и отладка API: Понимаем, какой код должен возвращать наш микросервис в той или иной ситуации (например, 409 Conflict при попытке создать дублирующий ресурс).

Понимание смысла каждого статус-кода, особенно разницы между 401 и 403, 502, 503 и 504, позволяет быстро изолировать проблему: находится ли она на уровне сети, балансировщика, бэкенд-приложения, базы данных или является проблемой клиента. Это ключевой навык для эффективного troubleshooting в распределенных системах.