HTTP-коды состояния объяснены: что 200, 404, 502 значат для мониторинга

Кратко: HTTP-код состояния - трёхзначное число, которым сервер отвечает на каждый запрос. Группа говорит категорию: 2xx = OK, 3xx = redirect, 4xx = ошибка клиента, 5xx = ошибка сервера. С точки зрения uptime-мониторинга нас интересуют прежде всего аномалии 5xx и 4xx.

Категории ответов

• 1xx Informational - переходные ответы, клиент обычно не замечает.
• 2xx Success - запрос прошёл успешно. 200 OK - default.
• 3xx Redirection - клиент должен идти в другое место. 301 permanent, 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 следовать redirect (follow) или считать redirect ошибкой. Некоторые DNS hijack атаки проявляются как неожиданные 302.

4xx: ошибка на стороне клиента

400 Bad Request - синтаксическая ошибка в запросе. Malformed JSON, отсутствующий header и т. д.

401 Unauthorized - отсутствующие или плохие credentials. Клиент должен аутентифицироваться.

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

404 Not Found - URL не существует. Для мониторинга не важно, для SEO да (утекает link equity).

405 Method Not Allowed - URL существует, но не принимает данный метод (например, POST на endpoint, ожидающий GET).

408 Request Timeout - сервер ждал запрос слишком долго и закрыл соединение.

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

410 Gone - resource удалён навсегда. Лучше, чем 404 для Google (сигнал не пытаться переиндексировать).

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; alert если тот же endpoint падает 2× подряд
• Следить за восходящим трендом: долгосрочный рост 4xx может означать broken link, scraper attack или сломанный frontend
• Игнорировать для alerting'а: 200-399 в пределах ожидаемого (следите за response time вместо кода)

Код состояния + response time = полная картина

Следить только за кодом состояния недостаточно - сервер может возвращать 200, но за 30 секунд, что с точки зрения клиента - сбой. Качественный мониторинг комбинирует:

1. Ожидаемый код состояния (типично 200)
2. Максимальный response time (типично 5-10 секунд)
3. Keyword match в контенте (ключевое слово, которое должно быть в HTML)
4. SSL валиден + не перед концом действия

Падение любого = alert.

Мониторинг с точной классификацией ошибок

ePulz.io различает код состояния, response time, keyword match и SSL состояние. Логи для каждой проверки.

Попробовать на 7 дней →