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). При стриминге видео или resumable download.

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 дней →