HTTP-коды ошибок: 400, 401 и 403, 404, 409, 500 — шпаргалка

Вячеслав Степанов — проджект-менеджер, ментор · 9 октября 2026

«Фронт получает 403», «на оплате сыплется 502», «после релиза пошли пятисотые» — так в IT-команде описывают проблемы. Проджект-менеджеру не нужно чинить ошибки самому, но по одному коду он должен понять, что случилось и к кому идти. Ниже — шпаргалка по кодам, которые встречаются в работе, разница между 401 и 403, которую путают даже на собеседованиях, и то, как проджект использует коды каждый день. Видео-версия — мой открытый урок, где мы проверяем API в Postman и видим эти коды вживую.

Если видео не открывается — смотри на YouTube (может понадобиться VPN).

Что такое HTTP-код ответа

Когда браузер или приложение обращается к серверу, сервер всегда возвращает код ответа — три цифры, по которым сразу видно итог: получилось, ошиблись в запросе или что-то упало. Вместе с кодом обычно приходят и данные, но код читают первым. Как вообще устроены запросы между фронтендом и бэкендом, я разбирал в статье про API.

Значения кодов закреплены в стандарте протокола HTTP — сейчас это RFC 9110, принятый в 2022 году. Поэтому 404 значит одно и то же на любом сайте мира.

Группы 1xx и 3xx проджекту почти не встречаются: первая — служебная, вторая отвечает за перенаправление на другой адрес, и браузер обрабатывает её сам. В работе важны три остальные.

Шпаргалка: коды, которые встречаются в работе

Есть и шуточный код — 418 I’m a teapot, «я чайник». Его придумали как первоапрельскую шутку в RFC 2324 в 1998 году. Иногда о нём спрашивают на собеседованиях, чтобы разрядить обстановку.

Чем 401 отличается от 403

Путаница идёт из названия: 401 официально называется Unauthorized, «не авторизован», хотя по смыслу речь про аутентификацию — система не знает, кто ты. Поэтому лекарство от 401 — войти заново. С 403 вход не поможет: система тебя узнала, но решила, что этого действия тебе нельзя. Тут нужны права, а их выдаёт администратор или правила продукта.

Две практические оговорки. Некоторые системы на запрос без входа отвечают 403 вместо 401 — так настроены отдельные фреймворки, и в учебном продукте нашего курса запрос без токена тоже возвращает 403. А иногда сервер нарочно отвечает 404 вместо 403, чтобы не выдавать сам факт, что чужая запись существует. Если код ведёт себя не по учебнику, сверяйся с документацией API своей команды.

400, 422 и 409: что не так с запросом

• 400 — запрос сломан по форме: не то поле, не тот тип, кривой формат. Чаще всего это ошибка фронтенда или интеграции.
• 422 — форма правильная, но данные не проходят проверку: пустое обязательное поле, дата в прошлом. Обычно это сценарий, который фронтенд должен показать пользователю понятным сообщением.
• 409 — запрос нормальный, но противоречит текущему состоянию: такая запись уже есть, действие уже выполнено. Часто это защита от двойного нажатия.

Какой код в какой ситуации отдавать, команда договаривается заранее и записывает в системной аналитике по фиче: для каждого эндпоинта — список ошибок и текст, который увидит пользователь.

500, 502, 503 и 504: что сломалось на сервере

Запрос редко идёт напрямую. Обычно между браузером и сервером стоит посредник — шлюз или балансировщик, а сам сервер может обращаться к чужим сервисам: банку, Telegram, почте. 5xx-код подсказывает, на каком звене цепочки проблема.

500 — повод сразу звать бэкенд: упал наш код или база. 503 часто временный — сервис перегружен или идут технические работы. 502 и 504 стоит проверять вместе с DevOps: виноват может быть как наш сервер, так и внешний сервис. Если 5xx посыпались после релиза, это кандидат на разбор на ретро и быстрый откат.

Где увидеть код ответа

• В браузере. Открой инструменты разработчика (F12 или Cmd+Option+I), вкладка Network. Каждый запрос страницы виден со своим кодом — так проджект может сам проверить, что происходит, когда «кнопка не работает».
• В Postman. Программа для ручной отправки запросов: код ответа показан рядом с результатом.
• В Swagger. Документация API команды: для каждого эндпоинта перечислены возможные коды и что они значат.
• В логах и мониторинге. Команда видит, сколько ответов с ошибками отдаёт сервер, и получает оповещение, если их становится много.

Как проджект использует коды

• Сортирует проблемы. Пришла жалоба от поддержки — проджект смотрит код и сразу понимает направление: права и данные пользователя, ошибка фронтенда или поломка на сервере.
• Пишет понятные баг-репорты. «Не работает оплата» превращается в «POST на создание платежа возвращает 502 с 14:20». Такой баг чинят быстрее.
• Закладывает ошибки в аналитику. Для каждой новой фичи заранее описывают коды ошибок и тексты для пользователя. Иначе пользователь увидит «что-то пошло не так» там, где можно было объяснить.
• Не верит одному коду 200. Код 200 значит только, что сервер принял запрос. Тестировщики проверяют результат отдельным чтением: создал запись — запроси её и сверь поля.

Типичные ошибки

• Путать 401 и 403. Команда ищет проблему в правах, а пользователю нужно просто войти заново. Лекарство — 401 «кто ты?», 403 «знаю, кто ты, но нельзя».
• Считать любую ошибку виной бэкенда. 4xx часто означает неверный запрос или данные пользователя. Лекарство — сначала смотреть на первую цифру кода.
• Показывать пользователю голый код. «Ошибка 409» ничего не говорит человеку. Лекарство — для каждого кода в аналитике записать текст для интерфейса.
• Пустой результат отдавать как 404. Если должников нет, это не ошибка: правильный ответ — 200 и пустой список. Лекарство — договориться об этом в аналитике.
• Описывать баг без кода. «Что-то сломалось» отправляет разработчика искать вслепую. Лекарство — в баг-репорте указывать запрос, код ответа и время.

Частые вопросы