PrepBro
← Назад к вопросам

Какие знаешь статусы ошибки 500?

1.0 Junior🔥 191 комментариев
#Работа с дефектами#Теория тестирования#Тестовая документация

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI6 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Статусы ошибки 5XX: Серверные ошибки

Ошибки с статус-кодом 5XX в протоколе HTTP указывают на то, что сервер не смог выполнить корректный запрос клиента по причине внутренней ошибки на стороне сервера. Самый известный из них — 500 Internal Server Error, который является общим и неспецифичным. Однако спецификация HTTP/1.1 (RFC 7231) и другие RFC определяют ряд более конкретных статусов в этом диапазоне, которые помогают в диагностике. Как инженер по качеству, важно понимать разницу между ними для точного описания дефектов, анализа логов и коммуникации с разработчиками.

Основные статусы 5XX

Вот ключевые статусы, которые можно встретить в современных веб-приложениях и API:

  1. 500 Internal Server Error
    *   **Самый распространённый и общий статус.** Сервер столкнулся с непредвиденной ситуацией, которая не позволяет ему выполнить запрос. Причины могут быть любыми: необработанное исключение в коде (NullPointerException, DivisionByZero и т.д.), сбой в бизнес-логике, ошибка конфигурации сервера, проблема с подключением к базе данных, когда само приложение "упало".
    *   **Для QA:** Часто требует изучения логов приложения (application logs) на стороне сервера. Это отправная точка для исследования.
  1. 501 Not Implemented
    *   Сервер не поддерживает функциональность, необходимую для выполнения запроса. Например, клиент использует неизвестный метод HTTP (не GET, POST, PUT, DELETE) или запрашивает функционал, который ещё не реализован на сервере.
    *   **Пример:** Запрос методом `PATCH` к API, которое его не поддерживает.

```http
PATCH /api/users/123 HTTP/1.1
Host: example.com
...
<!-- Ответ сервера -->
HTTP/1.1 501 Not Implemented
```

3. 502 Bad Gateway

    *   Сервер, выступая в роли **шлюза или прокси**, получил недопустимый ответ от вышестоящего сервера. Типичная ситуация для архитектур с балансировщиками нагрузки (nginx, HAProxy), обратными прокси или микросервисами.
    *   **Причины:** Вышестоящий сервер (бэкенд-приложение) "упал", не ответил в таймаут, отправил некорректные или неполные заголовки.
    *   **Для QA:** Проблема часто не в самом приложении, а в инфраструктуре или доступности зависимого сервиса.
  1. 503 Service Unavailable
    *   Сервер временно не может обработать запрос из-за перегрузки или планового технического обслуживания. Это явное указание на то, что проблема временная.
    *   **Важный нюанс:** В заголовке ответа `Retry-After` сервер может указать, через сколько секунд или до какой даты клиенту стоит повторить запрос.

```http
HTTP/1.1 503 Service Unavailable
Retry-After: 3600
Content-Type: text/html
<html>...Сервер на обслуживании...</html>
```

5. 504 Gateway Timeout

    *   Сервер, выступая в роли **шлюза или прокси**, не дождался ответа от вышестоящего сервера в отведённое время. Это **ошибка таймаута**.
    *   **Ключевое отличие от 502:** При 502 вышестоящий сервер ответил, но ответ был "плохим" (битым). При 504 он просто не ответил вовсе. Частая причина — "подвисшие" (long-running) запросы к базам данных или внешним API.
  1. 505 HTTP Version Not Supported
    *   Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, указанную в запросе. В современной веб-разработке встречается редко, но может возникнуть при попытке использовать устаревшие протоколы.

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

Понимание этих статусов критически важно в работе:

  • Точное описание бага: Вместо "выдаёт ошибку 500" в отчёте можно указать: "При отправке запроса X возвращается статус 502 Bad Gateway, что указывает на недоступность бэкенд-сервиса Y". Это экономит время разработчикам.
  • Анализ логов и мониторинга: Зная разницу между 502 и 504, можно целенаправленно искать проблемы в логах прокси-сервера (nginx) или логах самого приложения.
  • Тестирование отказоустойчивости: При тестировании восстановления после сбоев (recovery testing) ожидаемыми ответами могут быть именно 503 или 504. Мы можем проверять, корректно ли сервер их возвращает и содержит ли полезные заголовки (например, Retry-After).
  • Тестирование API: При негативном тестировании API отправка некорректных данных или вызов нереализованных методов должна возвращать ожидаемые статусы (500 при сбое в логике, 501 для неподдерживаемого метода).

Вывод: Хотя в повседневной речи все эти ошибки могут называться "ошибка 500", для профессионала важно различать Internal Server Error (500), Bad Gateway (502), Service Unavailable (503) и Gateway Timeout (504). Это не просто разные числа — это прямые указатели на разный слой и характер проблемы: код приложения, инфраструктура, временная перегрузка или таймаут зависимостей.