Назад до блогу

HTTP-коди стану: що означають 200, 404, 502

· 6 хв читання

HTTP-код стану - це відповідь сервера: 2xx OK, 3xx redirect, 4xx помилка клієнта, 5xx помилка сервера. Що вони означають і за якими стежити.

HTTP-коди стану: що означають 200, 404, 502

Категорії відповідей

  • 1xx Informational - перехідні відповіді, клієнт зазвичай їх не помічає.
  • 2xx Success - запит пройшов успішно. 200 OK - значення за замовчуванням.
  • 3xx Redirection - клієнт має піти в інше місце. 301 постійно, 302 тимчасово.
  • 4xx Client errors - клієнт надіслав щось неправильне. 404, 401, 403, 429.
  • 5xx Server errors - сервер дав збій. 500, 502, 503, 504.

2xx: успіх

200 OK - стандартна OK-відповідь. Це «healthy»-стан, який ви моніторите.

201 Created - типово відповідь на POST, що створив новий resource. Клієнти API її очікують.

204 No Content - успіх, але серверу нічого повертати. Часто використовують DELETE endpoint'и.

206 Partial Content - сервер повернув лише частину (range request). При стрімінгу відео або відновлюваних завантаженнях.

3xx: перенаправлення

301 Moved Permanently - URL змінився назавжди. Google переносить SEO equity на новий URL. Використовуйте при міграції домену, переході з HTTP на HTTPS або переході на www/non-www.

302 Found / 307 Temporary Redirect - тимчасове перенаправлення. Google не переносить ranking. Використовуйте при A/B тестуванні, обслуговуванні або коли URL з часом повернеться.

308 Permanent Redirect - як 301, але зберігає HTTP-метод (POST залишається POST). При 301 клієнт може змінити метод на GET.

304 Not Modified - у клієнта є cache, сервер підтверджує, що контент не змінився. Економить bandwidth.

Для моніторингу: При перевірці 3xx відповідей налаштуйте, чи має monitor слідувати редиректу (follow), чи вважати його помилкою. Деякі DNS hijack атаки проявляються як несподівані 302.

4xx: помилка на стороні клієнта

400 Bad Request - синтаксична помилка в запиті. Malformed JSON, відсутній header тощо.

401 Unauthorized - відсутні або хибні credentials. Клієнт має аутентифікуватися.

403 Forbidden - клієнт аутентифікований, але не має прав. Обережно: деякі сервери повертають 403 замість 401 з міркувань безпеки (щоб не розкривати існування ресурсу).

404 Not Found - URL не існує. При uptime-моніторингу відстежуваних сторінок 404 - це алерт (сторінка зникла); випадкові 404 від сторонніх відвідувачів - радше SEO-проблема (витікає link equity).

405 Method Not Allowed - URL існує, але не приймає даний метод (наприклад, POST на endpoint, що очікує GET).

408 Request Timeout - сервер чекав на запит надто довго і закрив з'єднання.

409 Conflict - запит у конфлікті з поточним станом (наприклад, update версії, яка вже не актуальна).

410 Gone - resource видалений назавжди. Для Google краще, ніж 404 (сигнал не намагатися переіндексувати).

422 Unprocessable Entity - запит синтаксично OK, але містить семантично невалідні дані (failed validation).

429 Too Many Requests - rate limit. Клієнт має сповільнитися. Сервер зазвичай додає header Retry-After.

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

500 Internal Server Error - загальна помилка. Backend кинув exception, який програма не зловила. Завжди тривога для моніторингу.

501 Not Implemented - сервер не знає HTTP-метод (наприклад, старий сервер не підтримує PATCH).

502 Bad Gateway - reverse proxy (nginx, Cloudflare) не отримав відповідь від backend сервера. Типово backend упав або пішов у timeout.

503 Service Unavailable - сервер перевантажений або на обслуговуванні. Часто з header Retry-After. Це планова відповідь, не crash.

504 Gateway Timeout - reverse proxy чекав backend довше, ніж timeout. Backend зазвичай ще працює, лише відповідає повільно.

520-525 Cloudflare errors - специфічні для Cloudflare. 520 = backend повернув щось нечитабельне, 522 = backend не відповів (connection timeout), 524 = backend відповів надто повільно (origin timeout).

Практичні правила alerting'у

  • Alert негайно: 500, 502, 503 (якщо це не дійсно планове обслуговування), 504, будь-який timeout
  • Alert при повторі: одиничний 5xx може бути race condition; алертуйте, якщо той самий endpoint падає 2x поспіль
  • Стежити за висхідним трендом: довгостроковий зріст 4xx може означати broken link, scraper attack або зламаний frontend
  • Ігнорувати для alerting'у: 200-399 у межах очікуваного (стежте за часом відповіді замість коду)

Код стану + час відповіді = повна картина

Стежити лише за кодом стану недостатньо - сервер може повертати 200, але за 30 секунд, що з точки зору клієнта є збоєм. Якісний моніторинг комбінує:

  1. Очікуваний код стану (типово 200)
  2. Максимальний час відповіді (типово 5-10 секунд)
  3. Збіг ключового слова у контенті (ключове слово, яке має бути в HTML)
  4. SSL валідний і не близько до завершення терміну дії

Збій будь-якого з них = alert.

Моніторинг з точною класифікацією помилок

ePulz.io розрізняє код стану, час відповіді, збіг ключового слова та SSL стан. Для кожної перевірки доступні детальні логи.

Спробувати на 7 днів →

Поділитися: Посилання скопійовано

Спробуйте ePulz.io безкоштовно - 7 днів без банківської картки.

Створити обліковий запис