Коды состояния HTTP
Полный справочник HTTP-статусов с человеческими пояснениями: что код значит и когда встречается на практике. Ищи по номеру или названию, кликай по коду, чтобы получить прямую ссылку.
Ничего не нашлось. Попробуй другой номер или слово.
1xx — Информационные
Запрос принят, обработка продолжается. Промежуточные ответы.
Сервер получил начало запроса и просит клиента продолжать отправку тела. Встречается при заголовке Expect: 100-continue, когда клиент сначала спрашивает разрешения, прежде чем слать большое тело.
Сервер согласен переключить протокол по запросу клиента из заголовка Upgrade. Классический пример — апгрейд HTTP-соединения до WebSocket.
Устаревший код из WebDAV: сервер принял запрос и ещё его обрабатывает, чтобы клиент не отвалился по таймауту. На практике почти не используется, его место занял 103.
Сервер заранее отдаёт заголовки (обычно Link с preload/preconnect), пока готовит основной ответ. Позволяет браузеру начать подгружать критичные ресурсы раньше.
2xx — Успешные
Запрос успешно получен, понят и обработан.
Запрос успешно выполнен, и в теле ответа есть полезные данные. Самый частый код для GET и для любых операций, которые возвращают результат.
Запрос успешен и привёл к созданию нового ресурса — типичный ответ на POST. Хорошим тоном считается вернуть заголовок Location со ссылкой на созданный ресурс.
Запрос принят, но обрабатывается асинхронно и ещё не завершён. Используется для фоновых задач и очередей, когда результат будет позже.
Ответ успешен, но метаданные были изменены посредником (например, прокси), а не пришли напрямую от исходного сервера. Встречается крайне редко.
Запрос успешен, но тела в ответе нет — возвращать нечего. В отличие от 200, его удобно отдавать на DELETE или на PUT/PATCH, когда клиенту не нужны данные обратно.
Запрос успешен, и клиенту предлагается сбросить отображение формы или представление, с которого пришёл запрос. На практике встречается почти никогда.
Сервер отдаёт только часть ресурса в ответ на заголовок Range. Лежит в основе докачки файлов и перемотки видео/аудио.
Из WebDAV: тело ответа содержит несколько отдельных статусов для разных операций сразу (обычно в виде XML). Полезно, когда один запрос затрагивает много ресурсов.
WebDAV-код: элемент уже был перечислен в предыдущей части ответа Multi-Status, поэтому повторно его не дублируют. Узкоспециализированный, вне WebDAV не встретишь.
Сервер выполнил запрос и вернул результат дельта-кодирования (RFC 3229) вместо полного ресурса. Экзотика, в обычной веб-разработке практически не попадается.
3xx — Перенаправления
Для завершения запроса нужны дополнительные действия — обычно переход по другому адресу.
У запрошенного ресурса несколько вариантов представления, и клиенту предлагается выбрать. На практике используется редко, обычно сервер сам решает за клиента.
Ресурс навсегда переехал на новый URL из заголовка Location. В отличие от 302, поисковики переносят на новый адрес ссылочный вес (link equity), поэтому 301 используют для постоянной смены адреса.
Временное перенаправление: ресурс сейчас доступен по другому URL, но позже вернётся на старый. В отличие от 301, вес для SEO не передаётся; исторически браузеры меняли метод на GET, поэтому для строгого сохранения метода берут 307.
Перенаправляет клиента забрать результат по другому URL уже через GET, независимо от исходного метода. Классика паттерна POST/Redirect/GET, чтобы обновление страницы не повторяло отправку формы.
Ресурс не изменился с момента, указанного клиентом (через ETag или If-Modified-Since), поэтому тело не передаётся — используй кэш. Экономит трафик при условных запросах.
Указывает, что к ресурсу нужно обращаться через прокси из заголовка Location. Признан небезопасным и устаревшим, современные браузеры его игнорируют.
Временное перенаправление, как 302, но со строгой гарантией: метод и тело запроса сохраняются (POST остаётся POST). Берут, когда нельзя допустить превращения запроса в GET.
Постоянное перенаправление, как 301, но с сохранением метода и тела запроса. Это «301 для POST»: адрес сменился навсегда, а метод не должен превратиться в GET.
4xx — Ошибки клиента
Проблема на стороне клиента: запрос составлен неверно или не разрешён.
Сервер не понял запрос из-за ошибки на стороне клиента: битый синтаксис, невалидный JSON, отсутствие обязательных полей. Общий ответ «ты прислал что-то не то».
Клиент не аутентифицирован: токен отсутствует, истёк или неверен — система не знает, кто ты. В отличие от 403, проблема в том, что ты не представился; залогинься и повтори.
Зарезервирован под будущие платёжные сценарии и долго был почти неиспользуемым. Сейчас иногда встречается у API, требующих оплаты или превысивших лимиты тарифа.
Сервер понял, кто ты, но доступ запрещён — прав не хватает. В отличие от 401, повторный логин не поможет: ты аутентифицирован, но эта операция тебе не разрешена.
Ресурс по этому адресу не найден, и сервер не сообщает, существовал ли он когда-либо. В отличие от 410, ничего не утверждается о судьбе ресурса — может, его и не было.
Ресурс существует, но HTTP-метод к нему не применим (например, POST туда, где только GET). Сервер обязан перечислить разрешённые методы в заголовке Allow.
Сервер не может отдать ответ в формате, который клиент запросил через заголовок Accept. Например, просят XML, а есть только JSON.
Как 401, но аутентифицироваться нужно перед прокси-сервером, а не перед целевым ресурсом. Прокси ждёт заголовок Proxy-Authorization.
Клиент слишком долго формировал запрос, и сервер устал ждать и закрыл соединение. Можно спокойно повторить запрос заново.
Запрос конфликтует с текущим состоянием ресурса: например, правка устаревшей версии или попытка создать уже существующую запись. Часто используется для оптимистичных блокировок и дублей.
Ресурс существовал, но удалён навсегда и не вернётся. В отличие от 404, это явное «было и сплыло» — сигнал поисковикам убрать страницу из индекса.
Сервер отказывается принимать запрос без заголовка Content-Length. Встречается, когда серверу нужно заранее знать размер тела.
Одно из условий из заголовков (If-Match, If-Unmodified-Since и т.п.) не выполнилось, поэтому запрос отклонён. Защищает от перезаписи изменённых кем-то данных.
Тело запроса больше, чем сервер готов принять (старое название — Payload Too Large). Типично при загрузке слишком тяжёлых файлов.
URL запроса длиннее, чем сервер согласен обрабатывать. Обычно из-за GET с огромным числом параметров в строке запроса — стоит перейти на POST.
Сервер не умеет обрабатывать формат тела, указанный в Content-Type. Например, прислали XML туда, где принимают только JSON.
Запрошенный диапазон через заголовок Range выходит за пределы размера ресурса. Возникает при докачке, когда указали смещение больше длины файла.
Сервер не может выполнить требование из заголовка Expect (обычно Expect: 100-continue). На практике встречается нечасто.
Я — чайник, и сварить кофе не могу. Шуточный код из первоапрельского RFC 2324 (HTCPCP); иногда его используют как пасхалку или ответ-заглушку.
Запрос пришёл на сервер, который не настроен на него отвечать (не тот хост за этим соединением). Актуально для HTTP/2 при переиспользовании соединений между доменами.
Синтаксис запроса верный, но данные не проходят по смыслу — провалилась валидация бизнес-правил. В отличие от 400 (битый запрос), здесь запрос понятен, но семантически некорректен; популярен в API и Laravel.
Ресурс заблокирован (код из WebDAV) и недоступен для изменения, пока блокировку не снимут. Вне WebDAV почти не встречается.
Запрос не выполнен, потому что провалился другой запрос, от которого он зависел (WebDAV). Узкоспециализированный код.
Сервер не готов обрабатывать запрос, отправленный слишком рано (early data в TLS 1.3), из-за риска повтора атаки. Просит повторить запрос после полного рукопожатия.
Сервер отказывается работать по текущему протоколу и требует перейти на другой через заголовок Upgrade (например, на TLS). Сопровождается заголовком Upgrade.
Сервер требует, чтобы запрос был условным (например, с If-Match), чтобы избежать гонки при одновременном изменении. Защита от «потерянного обновления».
Клиент шлёт слишком много запросов за отведённое время — сработал rate limiting. Сервер обычно добавляет заголовок Retry-After, подсказывая, когда можно повторить.
Заголовки запроса в сумме или по отдельности слишком большие, и сервер отказывается их принимать. Частая причина — раздувшиеся cookie.
Доступ к ресурсу закрыт по юридическим причинам — цензура, блокировка по требованию властей, DMCA. Номер выбран как отсылка к роману «451 градус по Фаренгейту».
5xx — Ошибки сервера
Запрос корректен, но сервер не смог его выполнить.
Что-то сломалось на стороне сервера, и он не знает, как это объяснить конкретнее — общий код любой непредвиденной ошибки. Чаще всего за ним стоит необработанное исключение в коде.
Сервер не умеет обрабатывать такой тип запроса в принципе — функциональность не реализована. В отличие от 405, метод не отключён для ресурса, а вообще не поддерживается сервером.
Сервер, работающий шлюзом или прокси, получил некорректный ответ от вышестоящего сервера. Классика, когда nginx стоит перед приложением, а оно отдало мусор или упало.
Сервер временно не может обслужить запрос — перегрузка или техобслуживание. Обычно сопровождается Retry-After; состояние временное, скоро должно пройти.
Шлюз или прокси не дождался ответа от вышестоящего сервера за отведённое время. В отличие от 502, ответ не пришёл вовсе, а не пришёл битым.
Сервер не поддерживает версию протокола HTTP, указанную в запросе. На практике встречается крайне редко.
Ошибка конфигурации сервера в механизме согласования содержимого: выбранный вариант сам пытается согласовываться, создавая зацикливание. Экзотика.
Серверу не хватило места для хранения, чтобы выполнить запрос (код из WebDAV). Встречается при операциях записи, когда диск или квота заполнены.
Сервер обнаружил бесконечный цикл при обработке запроса (WebDAV) и прервал его. Узкоспециализированный код.
Серверу нужны дополнительные расширения для выполнения запроса, которых нет в самом запросе. Практически не используется.
Клиенту нужно пройти аутентификацию в сети, чтобы получить доступ. Классический пример — captive portal, экран входа в публичный Wi-Fi.
Что такое коды состояния HTTP. Код состояния HTTP — это трёхзначное число, которым сервер отвечает на каждый запрос, сообщая его исход. Первая цифра задаёт класс: 1xx — информация, 2xx — успех, 3xx — перенаправление, 4xx — ошибка клиента, 5xx — ошибка сервера. Знать коды важно при отладке API, настройке редиректов и чтении логов: по номеру сразу понятно, на чьей стороне проблема и что делать дальше.
Частые вопросы
В чём разница между 301 и 302?
301 — перенаправление навсегда: адрес сменился окончательно, и поисковики переносят на новый URL ссылочный вес. 302 — временное: ресурс пока доступен по другому адресу, но вернётся, и вес для SEO не передаётся. Для постоянной смены адреса всегда бери 301.
Чем 401 отличается от 403?
401 Unauthorized значит «я не знаю, кто ты» — ты не аутентифицирован, нужно залогиниться. 403 Forbidden значит «я знаю, кто ты, но тебе сюда нельзя» — прав не хватает, и повторный вход не поможет.
Что значит ошибка 429?
429 Too Many Requests — ты отправил слишком много запросов за короткое время, и сработал rate limiting. Обычно сервер добавляет заголовок Retry-After с указанием, через сколько можно повторить.
Код 418 — это серьёзно?
Нет, 418 «I'm a teapot» — шуточный код из первоапрельского RFC про управление кофейниками. В реальных API не используется, но иногда встречается как пасхалка или заглушка.
Полный справочник кодов состояния HTTP с понятными объяснениями на русском. Каждый статус — от 100 Continue до 511 Network Authentication Required — снабжён описанием того, что он означает и в каких ситуациях встречается на практике. Есть поиск по номеру и названию и прямые ссылки на каждый код.
Справочник разбирает популярные пары, которые часто путают: 301 и 302 (постоянное и временное перенаправление и их влияние на SEO), 401 и 403 (не аутентифицирован против запрещено), 302, 307 и 308 (сохранение метода запроса), 404 и 410 (не найдено против удалено навсегда). Это помогает выбрать правильный код при проектировании API.
Коды состояния HTTP нужны при отладке REST API, настройке редиректов и nginx, чтении серверных логов и работе с веб-хуками. Справочник полезен бэкенд- и фронтенд-разработчикам, тестировщикам и DevOps — быстро понять, что значит конкретный статус и на чьей стороне искать проблему.