HTTP-статус-коды для разработчиков — что значит каждый код

Зачем понимать HTTP-статус-коды#

Ваш e-commerce-сайт возвращает 500 на checkout. Клиенты видят «Что-то пошло не так». Но что именно пошло не так? Сервер работает. БД жива. Проблема совсем в другом — но 500 не говорит, в чём.

API-эндпоинт возвращает 429, и мобильное приложение крашится вместо показа сообщения о повторе. Пользователи думают, что приложение сломано, хотя на самом деле просто ваш rate limiter делает свою работу.

Статус-страница говорит «Все системы работают», но клиенты сообщают, что страницы загружаются как 403 Forbidden. Мониторинг это не поймал, потому что проверяет только главную.

HTTP-статус-коды — сигналы. Они говорят, что пошло не так и куда смотреть. Но только если вы понимаете, что значит каждый код.

Это руководство объясняет каждый HTTP-статус-код, с которым вы столкнётесь, что его триггерит и что делать, когда видите.

---

HTTP-статус-коды: полная картина#

HTTP-ответы делятся на пять классов:

• 1xx (100–199): информационные — «Запрос получен, обрабатываю»
• 2xx (200–299): успех — «Всё сработало»
• 3xx (300–399): редирект — «Попробуй где-то ещё»
• 4xx (400–499): ошибка клиента — «Это вы накосячили»
• 5xx (500–599): ошибка сервера — «Это мы накосячили»

Каждый класс говорит, где проблема. Если получаете 4xx — проблема в запросе (неверный URL, неверная аутентификация, отсутствуют данные). Если 5xx — проблема на вашем сервере.

---

Коды 2xx (всё прошло хорошо)#

200 OK#

Что значит: Запрос успешен. Тело ответа содержит запрошенные данные.

Когда видите:

• Браузер грузит веб-страницу
• API возвращает JSON
• Отправка формы успешна

Пример:

GET /api/users/123
Response: 200 OK
Body: {"id": 123, "name": "John", "email": "john@example.com"}

Действие: ничего. Всё работает корректно.

201 Created#

Что значит: Запрос успешен и создан новый ресурс. Ответ включает только что созданный ресурс.

Когда видите:

• POST для создания пользователя возвращает 201 Created
• Создание заказа — 201 Created
• Загрузка файла — 201 Created

Пример:

POST /api/users
Request: {"name": "Jane", "email": "jane@example.com"}
Response: 201 Created
Body: {"id": 456, "name": "Jane", "email": "jane@example.com", "created_at": "2026-02-20T10:00:00Z"}

Действие: ничего. Ресурс создан успешно.

202 Accepted#

Что значит: Запрос принят к обработке, но ещё не обработан. Используется для асинхронных операций.

Когда видите:

• Отправка долгой задачи (видеокодирование, генерация отчёта)
• Batch-обработка
• Задачи, которые будут обработаны в фоне

Пример:

POST /api/batch-emails/send
Request: {"recipient_ids": [1,2,3,...,10000]}
Response: 202 Accepted
Body: {"job_id": "job_12345", "status": "queued"}

Действие: задача в очереди. Проверьте позже по job ID.

204 No Content#

Что значит: Запрос успешен, но контента в ответе нет.

Когда видите:

• DELETE-запросы (успешно удалено, нечего возвращать)
• Успешный PATCH без тела ответа
• Подтверждения вебхуков

Пример:

DELETE /api/users/123
Response: 204 No Content
Body: (пусто)

Действие: ничего. Действие успешно.

---

Коды 3xx (попробуй где-то ещё)#

301 Moved Permanently#

Что значит: Ресурс навсегда переехал на новый URL. Поисковики обновляют индекс, браузеры используют новый URL для будущих запросов.

Когда видите:

• Сайт мигрировал с www.oldsite.com на newsite.com
• Старый API-эндпоинт заменён новым
• Изменилась структура URL

Пример:

GET /old-page.html
Response: 301 Moved Permanently
Header: Location: /new-page.html

Действие:

• Для пользователей: браузер автоматически следует редиректу (прозрачно)
• Для SEO: используйте 301 для постоянных изменений (Google переносит page rank)
• Для API: клиенты должны обновиться на новый URL

302 Found (временный редирект)#

Что значит: Ресурс временно переехал на другой URL. Оригинальный URL ещё валиден, поэтому браузеры НЕ кэшируют новый URL.

Когда видите:

• Временные редиректы во время обслуживания
• Редиректы на страницу логина
• A/B-тестирование (временный редирект части пользователей на новую версию)

Пример:

GET /products/discount-flash-sale
Response: 302 Found
Header: Location: /products/2026-flash-sale

Действие: браузер временно следует редиректу, но всё ещё считает оригинальный URL основным.

304 Not Modified#

Что значит: Ресурс не менялся с прошлого запроса. Используйте кэшированную версию.

Когда видите:

• Браузер проверяет, менялась ли страница с последнего визита (по дате модификации/ETag)
• API возвращает 304, если данные не менялись с последнего запроса
• Снижает трафик, не отправляя неизменённые данные

Пример:

GET /api/user-profile
Request Header: If-Modified-Since: 2026-02-19 10:00:00
Response: 304 Not Modified
Body: (пусто — используйте кэш)

Действие: браузер/клиент использует локальный кэш.

307 Temporary Redirect#

Что значит: Как 302, но гарантирует, что HTTP-метод сохраняется при редиректе.

Техническая разница:

• 302 разрешает смену метода (POST → GET после редиректа)
• 307 сохраняет метод (POST → POST после редиректа)

Когда видите:

• Отправка формы редиректит на страницу подтверждения (POST → POST)
• API-редиректы, требующие сохранения метода

Почему это важно: Старые браузеры иногда конвертировали POST-редиректы в GET, что могло терять данные формы. 307 это предотвращает.

---

Коды 4xx (это вы накосячили)#

400 Bad Request#

Что значит: Запрос некорректно сформирован. Сервер не смог его понять.

Когда видите:

• Некорректный JSON в теле запроса
• Отсутствуют обязательные поля
• Неверный формат параметра
• Синтаксическая ошибка в query string

Пример:

POST /api/users
Request Body: {"name": "Jane" "email": "jane@example.com"}
                              ↑ нет запятой
Response: 400 Bad Request
Body: {"error": "Invalid JSON syntax"}

Действие:

• Проверьте формат запроса
• Валидируйте JSON-синтаксис
• Убедитесь, что обязательные поля присутствуют
• Проверьте, что типы параметров соответствуют документации API

401 Unauthorized#

Что значит: Аутентификация провалилась или отсутствует. Вы не доказали, кто вы.

Когда видите:

• Не предоставлен токен аутентификации
• Токен невалиден или просрочен
• Неверные логин/пароль
• Отсутствует API-ключ

Пример:

GET /api/user-profile
(нет заголовка Authorization)
Response: 401 Unauthorized
Body: {"error": "Authentication required"}

Действие:

• Предоставьте валидную аутентификацию (логин, API-ключ, токен)
• Обновите просроченные токены
• Проверьте корректность учётных данных

403 Forbidden#

Что значит: Аутентификация прошла, но у вас нет прав на этот ресурс.

Когда видите:

• Пользователь пытается удалить чужой аккаунт
• Пользователь пытается зайти на admin-only эндпоинт
• Пользователь пытается зайти на ресурс другой организации
• Недостаточно прав/роли

Пример:

DELETE /api/users/999
(аутентифицирован как user 123, пытается удалить user 999)
Response: 403 Forbidden
Body: {"error": "You can only delete your own account"}

Действие:

• Используйте корректный аккаунт с нужными правами
• Запросите повышение прав, если нужно
• Убедитесь, что обращаетесь к правильному ресурсу

404 Not Found#

Что значит: Ресурс не существует, или сервер не понимает, как обработать этот эндпоинт.

Когда видите:

• Опечатка в URL (/users/ vs /users)
• Эндпоинт не существует
• Удалённый ресурс
• Неверная версия API

Пример:

GET /api/users/nonexistent-id-12345
Response: 404 Not Found
Body: {"error": "User not found"}

Действие:

• Проверьте написание URL
• Убедитесь, что эндпоинт существует
• Проверьте документацию API
• Попробуйте другой ID/ресурс

405 Method Not Allowed#

Что значит: Эндпоинт существует, но не поддерживает этот HTTP-метод.

Когда видите:

• POST на эндпоинт, который принимает только GET
• DELETE на эндпоинт без поддержки удаления
• PATCH, когда разрешён только PUT

Пример:

DELETE /api/domains/123
(если DELETE не поддерживается на эндпоинте domains)
Response: 405 Method Not Allowed
Header: Allow: GET, POST, PUT

Действие: используйте корректный HTTP-метод. В ответе обычно есть заголовок Allow с валидными методами.

408 Request Timeout#

Что значит: Сервер ждал слишком долго, пока клиент отправит запрос, и сдался.

Когда видите:

• Медленный клиент загружает большой файл
• Сетевое соединение оборвалось посреди запроса
• Запрос длится дольше серверного таймаута (обычно 30–300 секунд)

Пример:

POST /api/upload
(загрузка 500MB на медленном соединении занимает 10 минут)
Response: 408 Request Timeout

Действие:

• Повторите запрос
• Разбейте крупные запросы на части
• Проверьте сетевое соединение
• Увеличьте клиентский таймаут, если уместно

429 Too Many Requests#

Что значит: Вы делаете слишком много запросов. Превышен rate-лимит.

Когда видите:

• Достигли rate-лимита API (например, 100 запросов/минуту)
• Шлёте письма слишком быстро
• Делаете брутфорс логинов
• Скрейпер слишком сильно бьёт сервер

Пример:

GET /api/users/123
(100-й запрос за последнюю минуту)
Response: 429 Too Many Requests
Header: Retry-After: 60
Body: {"error": "Rate limit exceeded. Try again in 60 seconds"}

Действие:

• Подождите перед повтором (см. заголовок Retry-After)
• Внедрите экспоненциальный backoff
• Используйте пагинацию для больших выдач
• Кэшируйте результаты локально вместо повторных запросов

---

Коды 5xx (это мы накосячили)#

500 Internal Server Error#

Что значит: Что-то пошло не так на сервере, и сервер не может дать больше деталей.

Когда видите:

• Необработанное исключение в коде
• Сбой подключения к БД
• Out of memory
• Неожиданное состояние

Пример:

POST /api/checkout
Response: 500 Internal Server Error
Body: {"error": "Something went wrong"}

Почему так размыто: Серверы не раскрывают детали внутренней ошибки клиентам по соображениям безопасности. Подробные ошибки помогают атакующим.

Действие:

• Смотрите серверные логи для реальной ошибки
• Если это сторонний сервис — обратитесь в поддержку
• Если ваш сервис — смотрите логи ошибок, перезапустите при необходимости, откатите недавний деплой

501 Not Implemented#

Что значит: Сервер не поддерживает этот HTTP-метод или фичу.

Когда видите:

• Сервер не поддерживает фичи HTTP/2
• WebSocket не поддерживается
• Определённые HTTP-методы не реализованы

Пример:

OPTIONS /api/users
(сервер не поддерживает OPTIONS)
Response: 501 Not Implemented

Действие: обычно ничего — используйте другой метод или сервис. Редко в современных API.

502 Bad Gateway#

Что значит: Сервер получил невалидный ответ от upstream-сервера.

Реальные сценарии:

1. Reverse proxy (Nginx) не может достучаться до бэкенда

   Клиент → Nginx (gateway) → Node.js Backend
                   ↑
            Бэкенд лежит или не отвечает
   

2. Балансировщик не может достучаться ни до одного здорового бэкенда

   Клиент → Load Balancer → Backend Servers
                         ↑
              Все бэкенды лежат или медленные
   

3. API Gateway не может достучаться до микросервиса

   Клиент → API Gateway → Auth Service (лежит)
                       → User Service
                       → Order Service
   

Почему случается:

• Бэкенд-сервер крашнулся
• Потеряна сетевая связность
• Upstream-сервер медленный и таймаутит
• Upstream возвращает невалидный ответ

Пример:

GET /dashboard
Response: 502 Bad Gateway

За кулисами:

Nginx получил запрос
Попытался переслать на Node.js на localhost:3000
Connection refused (сервер не запущен)
Nginx вернул: 502 Bad Gateway

Действие:

• Проверьте, что бэкенд-сервисы запущены: docker ps, pm2 status, статус systemd
• Проверьте сетевую связность с бэкендом
• Смотрите логи бэкенда на крэши
• Перезапустите бэкенд-сервис при крэше
• Проверьте, что балансировщик корректно маршрутизирует

503 Service Unavailable#

Что значит: Сервер временно не может обрабатывать запросы (обслуживание, перегрузка, лежащие зависимости).

Когда видите:

• Сервер перезапускается
• Сервер под высокой нагрузкой (все соединения заняты)
• БД лежит или мигрируется
• Сторонняя зависимость лежит
• Идёт деплой (трафик на паузе)

Пример:

GET /api/users
Response: 503 Service Unavailable
Header: Retry-After: 600
Body: {"error": "Server is undergoing maintenance. Try again in 10 minutes"}

Почему серверы возвращают 503 во время обслуживания:

• Говорит клиентам «это временно, попробуйте позже»
• Браузеры и клиенты знают, что нужно автоматически повторять
• Поисковики не штрафуют 503 (в отличие от 500, который выглядит как баг)

Действие:

• Подождите и повторите (см. Retry-After)
• Проверьте статус-страницу на окна обслуживания
• Если внутренний сервис: дождитесь окончания деплоя, смотрите логи

504 Gateway Timeout#

Что значит: Сервер не получил ответ от upstream-сервера вовремя.

Когда видите:

• Бэкенд-сервер слишком медленный
• Слишком высокий сетевой latency
• Запрос к БД занимает слишком долго
• Upstream-сервер виснет

Пример:

Запрос к бэкенду:
GET /api/heavy-report
Ждём 30 секунд...
Таймаут!
Response: 504 Gateway Timeout

Реальная причина:

Клиент → Nginx (таймаут 30с) → Node.js Backend (запрос 60с)
                              ↑
              Nginx сдаётся через 30с
              Бэкенд всё ещё выполняет запрос

Действие:

• Проверьте перформанс бэкенда
• Ищите медленные SQL-запросы
• Оптимизируйте код
• Добавьте индексы БД
• Увеличьте таймаут, если операция легитимно занимает дольше
• Разбейте долгие операции на async-задачи

---

Справочная таблица HTTP-статус-кодов#

Код	Имя	Категория	Значение
200	OK	Success	Запрос успешен
201	Created	Success	Ресурс создан
202	Accepted	Success	Запрос в очереди
204	No Content	Success	Успех, тела нет
301	Moved Permanently	Redirect	Использовать новый URL навсегда
302	Found	Redirect	Временно по другому URL
304	Not Modified	Redirect	Используйте кэш
307	Temp Redirect	Redirect	Сохранить HTTP-метод
400	Bad Request	Client Error	Некорректный запрос
401	Unauthorized	Client Error	Нужна аутентификация
403	Forbidden	Client Error	Доступ запрещён
404	Not Found	Client Error	Ресурса нет
405	Method Not Allowed	Client Error	Неверный HTTP-метод
408	Request Timeout	Client Error	Запрос длился слишком долго
429	Too Many Requests	Client Error	Rate-лимит
500	Internal Server Error	Server Error	Общая ошибка сервера
501	Not Implemented	Server Error	Фича не поддерживается
502	Bad Gateway	Server Error	Ошибка upstream-сервера
503	Service Unavailable	Server Error	Сервер временно недоступен
504	Gateway Timeout	Server Error	Upstream слишком медленный

---

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

Шаг 1: определите статус-код#

В браузере:

1. Откройте DevTools (F12)
2. Перейдите в Network
3. Посмотрите на сбойный запрос
4. В колонке Status — код

В терминале:

curl -i https://example.com/endpoint
# Первая строка показывает: HTTP/1.1 200 OK

В приложении:

• Смотрите логи ошибок
• Смотрите объект ответа
• Большинство фреймворков отдают статус-код

Шаг 2: разберитесь, что значит#

По категориям:

• 2xx? Работает как задумано
• 3xx? Проверьте назначение редиректа
• 4xx? Проверьте формат запроса и права
• 5xx? Смотрите серверные логи и upstream-зависимости

Шаг 3: посмотрите на тело ответа и заголовки#

Тело ответа: Большинство API включают детали ошибки:

{
  "error": "User not found",
  "message": "No user with ID 12345",
  "code": "USER_NOT_FOUND"
}

Заголовки ответа: Важные:

• Retry-After — сколько ждать перед повтором (429, 503)
• Allow — валидные HTTP-методы (405)
• Location — куда редиректить (3xx)
• WWW-Authenticate — как аутентифицироваться (401)

Шаг 4: действуйте по классу кода#

4xx Client Error:

• Отправили не те данные? Почините запрос
• Опечатка в URL? Исправьте
• Нет прав? Запросите доступ
• Не тот эндпоинт? Смотрите документацию

5xx Server Error:

• Сервер запущен? Проверьте uptime
• Логи показывают ошибки? Чините
• Upstream лежит? Ждите восстановления
• Деплоилось? Откатывайте при необходимости

---

Реальный пример: отладка 502 Bad Gateway#

Сценарий:

GET /api/checkout
Response: 502 Bad Gateway
Клиенты не могут завершить покупки

Шаг 1: подтвердите, что это 502 ✓ Заголовок ответа HTTP/1.1 502 Bad Gateway

Шаг 2: проверьте, что значит 502 ✓ Upstream-сервер не отвечает корректно

Шаг 3: диагностируйте проблему

Запущены ли бэкенд-сервисы?

docker ps
# Output: checkout-service не запущен

✗ Сервис checkout крэшнулся

Шаг 4: найдите корневую причину

Смотрите логи:

docker logs checkout-service
# Out of memory error!
# Java heap space exhausted

Шаг 5: исправьте

Увеличьте память:

docker-compose up -d --build

Или перезапустите:

docker restart checkout-service

Шаг 6: проверьте

curl -i https://api.example.com/api/checkout
# HTTP/1.1 200 OK ✓

---

Мониторинг статус-кодов в реальном времени

Зачем мониторить

• Ловить простой до того, как сообщат клиенты
• Ловить 5xx-ошибки, затрагивающие только определённые эндпоинты
• Отслеживать 4xx, чтобы находить злоупотребление API
• Мониторить 429, чтобы понять, когда масштабироваться

Что мониторить

Критично (поднимать пейджер):

• Любые 5xx на критичных эндпоинтах (checkout, login, payment)

Важно (расследовать):

• Скачок 429 (rate-лимит — близко к ёмкости)
• Растущие 502/504 (деградация upstream)
• Рост 403/401 (возможный брутфорс)

Информационно (отслеживать тренды):

• 404-ошибки (запрашивают неверные URL?)
• 400-ошибки (клиенты шлют некорректные запросы?)

Использование Nova Uptime для мониторинга статус-кодов#

Uptime-мониторинг от Nova Uptime отслеживает HTTP-статус-коды в реальном времени:

1. Возвращается 200? Сайт работает ✓
2. Возвращается 404? Неверный URL или эндпоинт удалён ✗
3. Возвращается 429? Вас rate-лимитят ⚠️
4. Возвращается 502/503? Проблема бэкенда ✗
5. Возвращается 504? Таймаут, нужна оптимизация ⚠️

Nova Uptime показывает:

• Какие статус-коды возвращаются
• Когда начали появляться
• Какие эндпоинты затронуты
• Тренд во времени

---

HTTP-статус-коды и SEO#

Поисковики используют статус-коды, чтобы решать, как индексировать страницы:

200 OK: индексировать (нормально)

301 Moved Permanently: обновить индекс на новый URL

302 Found: держать старый URL в индексе, не следовать редиректу

304 Not Modified: не перекраулить, последняя версия актуальна

401/403: не индексировать (доступ запрещён)

404 Not Found: удалить из индекса (страница пропала)

410 Gone: удалить из индекса (страница пропала и не вернётся)

429/503/504: повторить позже (временная проблема)

5xx-ошибки: возможна проблема сайта; Google замедляет краулинг

Важно для здоровья сайта:

• Используйте 301 для постоянных смен URL (сохраняет SEO)
• Используйте 410, чтобы явно сказать Google, что страница пропала
• Быстро чините 5xx (Google понижает приоритет сломанных сайтов)
• Внедрите robots.txt, чтобы не было 404 на неиндексируемом контенте

---

Итог: быстрый справочник по HTTP-статус-кодам#

Всё в порядке:

• 200 OK — обычный успех
• 201 Created — новый ресурс создан
• 204 No Content — успех, ответ не нужен

Редирект куда-то ещё:

• 301/302 — следуйте редиректу на новый URL
• 304 — используйте кэш

Вы ошиблись:

• 400 Bad Request — почините формат запроса
• 401 Unauthorized — предоставьте аутентификацию
• 403 Forbidden — у вас нет прав
• 404 Not Found — неверный URL
• 429 Too Many Requests — притормозите, вас rate-лимитят

Мы ошиблись:

• 500 Internal Server Error — смотрите серверные логи
• 502 Bad Gateway — бэкенд-сервис лежит
• 503 Service Unavailable — сервер временно лежит
• 504 Gateway Timeout — бэкенд слишком медленный

Мониторинг с Nova Uptime: HTTP-мониторинг от Nova Uptime ловит эти ошибки мгновенно и оповещает до того, как заметят клиенты. Мониторьте критичные эндпоинты, отслеживайте тренды статус-кодов и получайте алерты при скачках 5xx-ошибок.

---

Последнее обновление: 20 февраля 2026 Nova Uptime мониторит HTTP-статус-коды по 50+ типам проверок и оповещает о 5xx-ошибках в реальном времени