Коди стану HTTP: що означають 200, 301, 404, 429, 500 та інші

Щоразу, коли браузер, застосунок чи скрипт звертається до вебсервера, сервер відповідає тризначним кодом стану HTTP. Здебільшого ви його не бачите, бо сторінка просто відкривається. Але коли щось іде не так, саме код найшвидше підказує, що сталося і хто має це виправити: ви, сайт чи щось посередині.

У цьому посібнику пояснено, як групуються коди, що означають ті, які трапляються насправді, і як діяти відвідувачу, власнику сайту чи розробнику, що працює з API.

Як читати код стану

Перша цифра показує клас відповіді:

• 1xx – інформаційні. Запит отримано, обробка триває. Видно рідко.
• 2xx – успіх. Запит виконано.
• 3xx – переспрямування. Ресурс в іншому місці або копія в кеші ще актуальна.
• 4xx – помилка клієнта. Щось не так із запитом: адреса, вхід, права доступу чи надіслані дані.
• 5xx – помилка сервера. Запит може бути правильним, але збій стався на сервері або шлюзі перед ним.

Просте правило: при коді 4xx змініть запит, перш ніж повторювати; при коді 5xx той самий запит може спрацювати пізніше.

Код можна побачити самостійно

У Chrome, Edge чи Firefox натисніть F12, відкрийте вкладку Network («Мережа») і перезавантажте сторінку. У стовпці Status видно код для сторінки та кожного зображення, скрипта й запиту до API. У терміналі можна запросити лише заголовки:

curl -I https://versuss.space/
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Ключ -L змушує curl іти за переспрямуваннями й показувати кожен крок — це зручно, коли сторінка «стрибає» між адресами.

2xx: успішні відповіді

• 200 OK – звичайна відповідь для сторінки чи успішного читання з API.
• 201 Created – POST створив новий ресурс; його адреса часто є в заголовку Location.
• 204 No Content – успіх без тіла відповіді, типово після DELETE чи збереження налаштувань.
• 206 Partial Content – надіслано лише частину файлу; так працюють потокове відео й докачування.

3xx: переспрямування та кеш

• 301 Moved Permanently – адреса змінилася назавжди. Браузери це запам’ятовують, а пошукові системи переносять позиції на нову URL. Використовуйте при перейменуванні сторінки чи переході з http:// на https://.
• 302 Found і 307 Temporary Redirect – тимчасове переспрямування, наприклад на сторінку входу. Пошуковики зберігають початкову адресу.
• 308 Permanent Redirect – як 301, але клієнт має повторити той самий метод і тіло запиту; це важливо для POST у API.
• 304 Not Modified – браузер запитав «чи змінилося щось від моєї копії в кеші?», і сервер відповів «ні». Це добре: нічого не завантажується повторно. Саме на цьому тримається кеш браузера.

Цикл переспрямувань. Якщо браузер пише «забагато переспрямувань», два правила відправляють відвідувача туди-сюди — зазвичай правило HTTPS на сервері конфліктує з іншим правилом у CMS чи проксі. Відвідувачу інколи допомагає очищення cookie, але справжнє виправлення — на боці сайту.

4xx: проблеми із запитом

• 400 Bad Request – сервер не зрозумів запит: зіпсований JSON, неправильний рядок параметрів чи завеликий cookie. Якщо 400 з’явилася раптово, відвідувачу часто допомагає очищення cookie цього сайту.
• 401 Unauthorized – ви не автентифіковані: логін, токен чи API-ключ відсутній, прострочений або хибний. Див. API-ключ чи OAuth.
• 403 Forbidden – сервер знає, хто ви (або це не має значення), і все одно відмовляє. Типові причини: немає прав, блокування за IP чи країною, правило файрвола, неправильні права на файли.
• 404 Not Found – за цією адресою нічого немає. Перевірте написання; якщо посилання на сайті веде на 404, власник має виправити посилання або додати переспрямування.
• 405 Method Not Allowed – адреса існує, але не для цього методу, наприклад POST на ресурс лише для читання. Див. методи REST API.
• 408 Request Timeout – клієнт надто довго надсилав запит, часто через повільне чи нестабільне з’єднання.
• 409 Conflict – запит суперечить поточному стану, наприклад створення користувача, який уже існує, чи збереження застарілої версії.
• 410 Gone – ресурс видалено навмисно, і він не повернеться. Пошуковики прибирають сторінки з 410 швидше, ніж з 404, тож це правильна відповідь для видаленого вмісту.
• 413 Payload Too Large – завантаження перевищує ліміт сервера.
• 415 Unsupported Media Type – тіло у форматі, який ресурс не приймає; часто бракує заголовка Content-Type: application/json.
• 422 Unprocessable Content – формат правильний, але дані не пройшли перевірку, наприклад хибна адреса email.
• 429 Too Many Requests – ви вперлися в ліміт запитів. Зачекайте час із заголовка Retry-After і зменште темп. Детальніше — у статті ліміти запитів API.

5xx: проблеми на сервері

• 500 Internal Server Error – загальний збій застосунку: помилка в коді, зламаний плагін, заповнений диск чи проблема з базою даних. Справжню причину видно в журналі помилок сервера.
• 502 Bad Gateway – проксі, балансувальник чи CDN звернувся до застосунку за собою і отримав некоректну відповідь — зазвичай застосунок упав або перезапускається.
• 503 Service Unavailable – сервер перевантажений або на обслуговуванні. Коректні сервіси додають Retry-After.
• 504 Gateway Timeout – проксі надто довго чекав на застосунок. Часті причини — повільні запити до бази та довгі скрипти.

Відвідувач не може виправити помилку 5xx. Оновіть сторінку за хвилину, перевірте сторінку статусу сервісу, якщо вона є, і спробуйте пізніше. Власнику сайту варто почати з журналу помилок і з того, що змінювалося останнім: оновлення, новий плагін, правка конфігурації.

Коди стану й пошукові системи

Пошуковики сприймають коди буквально. Сторінку з 200 можна індексувати; 301 передає сигнали сторінки на нову адресу; сторінки з 404 і 410 з часом видаляються; повторювані помилки 5xx змушують робота сповільнитися й можуть тимчасово прибрати сторінки з видачі. Дві помилки трапляються особливо часто:

• М’яка 404 (soft 404) – сторінка пише «не знайдено», але повертає 200. Пошуковик вважає її неякісним дублем. Відсутні сторінки мають повертати справжній 404 або 410.
• Ланцюжки переспрямувань – http://www → https://www → https:// → нова URL. Кожен крок забирає час; ведіть старі адреси одразу на кінцеву.

Обробка кодів стану у власному коді

Звертаючись до API, не вважайте успіх гарантованим. Простий і безпечний шаблон:

const res = await fetch(url, { headers: { Accept: 'application/json' } });
if (res.status === 429 || res.status >= 500) {
  // тимчасова помилка: зачекати й повторити з експоненційною затримкою
} else if (!res.ok) {
  // 4xx: записати тіло в лог, виправити запит, не повторювати наосліп
  throw new Error(`HTTP ${res.status}: ${await res.text()}`);
}
const data = await res.json();

Повторюйте лише тимчасові збої (429, 502, 503, 504 і мережеві помилки), збільшуйте паузу між спробами й обмежте їхню кількість. Повтор запиту з 400 чи 401 лише швидше повторює ту саму помилку.

Коротка таблиця для діагностики

• 401 / 403 – перевірте вхід, токен, права й обмеження за IP.
• 404 – перевірте URL; власнику варто додати 301, якщо сторінка переїхала.
• 429 – зменште темп і дотримуйтеся Retry-After.
• 500 – читайте журнал помилок сервера.
• 502 / 504 – перевірте, що застосунок за проксі працює і відповідає досить швидко.
• Забагато переспрямувань – шукайте два правила, що ведуть у протилежні боки.

Головне

• Перша цифра показує, де проблема: 4xx — у запиті, 5xx — на сервері.
• Для постійного переїзду — 301, для назавжди видаленого вмісту — 410.
• Повторюйте лише тимчасові помилки й із затримкою; для інших 4xx виправляйте запит.
• Вкладка Network у браузері та curl -I показують справжній код за секунди.