Ошибка 503 — сбой другого рода, чем превышение времени ожидания или отказ в соединении. Сервер на месте, и он ответил. Он сообщил, что в данный момент не может обработать запрос. Стандарт HTTP описывает 503 как временное состояние, обычно перегрузку или плановое обслуживание, и позволяет серверу указать, когда повторить попытку.

Это «временно» — обещание сервера, а не гарантия. Руководство поможет выяснить, какая именно у вас 503 и на что смотреть в первую очередь.

Что говорит ответ

Ответ 503 кто-то выдал. Это может быть приложение, веб-сервер, балансировщик нагрузки, прокси или сеть доставки контента (CDN). Это уже сужает поиск: путь по сети и DNS работают, раз ответ до вас дошёл.

Две подсказки стоит прочитать, прежде чем куда-либо заходить:

  • Сама страница. Простое сообщение от веб-сервера, оформленная страница обслуживания и страница ошибки CDN указывают на разные уровни.
  • Заголовки. Поищите заголовок Retry-After: он говорит, сколько секунд ждать, или называет дату. Сервер, который его отправляет, обычно сообщает, что 503 задумана, например на время обслуживания. Заголовки, называющие прокси или CDN, показывают, какой уровень ответил.

Три частые причины

Причина Как выглядит Что проверить в первую очередь
Плановое обслуживание Страница обслуживания, часто с Retry-After; началось в известное время Не включали ли развёртывание, миграцию или режим обслуживания
Перегрузка Сначала медленные ответы, потом 503; хуже в часы пик Процессор, память и предел одновременных рабочих процессов или соединений
Бэкенд помечен как недоступный Прокси или балансировщик отвечает 503, пока приложение за ним не работает или не проходит проверку работоспособности Состояние приложения за прокси и собственный журнал ошибок прокси

Некоторые сервисы также намеренно отвечают 503, когда клиент отправляет слишком много запросов, вместо более привычной 429. Если вы ограничиваете частоту запросов от посетителей, проверьте, не попадает ли под ограничение ваш собственный трафик.

Сначала проверьте снаружи

Прежде чем что-то менять, посмотрите, что видит посетитель. С любой машины:

curl -sS -o /dev/null -D - https://example.com/

Команда выводит строку статуса и заголовки. Чтобы увидеть, сколько заняла отправка запроса и какой статус вернулся, одной строкой:

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/

Запустите её несколько раз. Если каждый раз возвращается 503, состояние устойчивое. Если ответы чередуются между 200 и 503, скорее всего, один из нескольких серверов за балансировщиком нагрузки нездоров или рабочие процессы время от времени заканчиваются. Попросите также кого-нибудь из другой сети попробовать, чтобы исключить ответ, зависящий от вашего местоположения.

Идите от переднего края к заднему

Следуйте за запросом в том порядке, в котором он проходит:

  1. CDN или прокси впереди. Именно он отвечает? Проверьте его страницу статуса и его журнал ошибок. CDN, который не может достучаться до вашего сервера, часто показывает собственную страницу ошибки.
  2. Балансировщик нагрузки. Показывает ли он все бэкенды здоровыми? Бэкенд, не прошедший проверку работоспособности, исключается, и когда не остаётся ни одного, балансировщик возвращает 503.
  3. Веб-сервер и рабочие процессы приложения. Есть ли свободные рабочие процессы? Если пул заполнен, новые запросы ждут, а некоторые настройки отвечают 503, когда очередь полна. Поищите в журнале строки о достижении предела.
  4. Приложение и его зависимости. Переполненная или недоступная база данных может заставить приложение отказываться от работы. То же верно для нижестоящего сервиса, от которого зависит страница.
  5. Недавние изменения. Развёртывание, смена конфигурации, обновление плагина или всплеск трафика незадолго до первой 503 — самое частое объяснение. Начните вашу хронологию отсюда.

Читайте закономерность

Время говорит не меньше, чем ответ:

  • Всплеск 503 во время развёртывания — обычно сам перезапуск. Исправляйте это, изменив способ развёртывания, а не гоняясь за ошибкой.
  • 503 в один и тот же час каждый день указывает на плановую задачу, резервное копирование или пик трафика, который исчерпывает ресурсы.
  • 503 после растущего времени ответа указывает на перегрузку. Время ответа часто растёт минутами, прежде чем появится первая 503. См. статью время ответа.
  • 503 только у одного посетителя может быть ограничением частоты запросов, заблокированным адресом или правилом безопасности, а не сбоем.

Что может сказать монитор

Монитор, запрашивающий ваш адрес снаружи, не видит, что происходит внутри сервера, но даёт нужную вам хронологию.

UptimeWire считает сбоем любой конечный ответ вне диапазона от 200 до 399, поэтому 503 — это сбой. Неудачная проверка повторяется, и инцидент открывается после трёх неудачных проверок подряд с интервалом около 20 секунд. Причина записывается, например «HTTP 503», вместе со временем начала и длительностью. См. статью инциденты мониторинга.

На практике это помогает: вы видите, была ли 503 коротким всплеском или долгой недоступностью и повторяется ли она в определённое время. Причину это не показывает. UptimeWire не заглядывает внутрь вашего приложения и не измеряет ваш сервер.

На время плановых работ запланированное обслуживание в UptimeWire удерживает оповещения об инцидентах, пока работы идут. Если из-за короткой 503 при каждом развёртывании по-прежнему приходят оповещения, см. статью почему мониторы доступности присылают ложные оповещения.

Чек-лист

  • 503 устойчивая или нерегулярная? Проверьте несколько раз.
  • Кто ответил: приложение, веб-сервер, прокси, балансировщик нагрузки или CDN?
  • Есть ли заголовок Retry-After и сказано ли в нём, когда повторить попытку?
  • Не было ли незадолго до этого развёртывания, изменения или всплеска трафика?
  • Не рос ли показатель времени ответа до первой 503?
  • Все ли бэкенды здоровы и есть ли свободные рабочие процессы?
  • Повторяется ли сбой по расписанию?

Когда 503 — правильный ответ

503 во время настоящего обслуживания — корректное поведение. Она сообщает посетителям и поисковым системам, что нужно вернуться позже, а страница с кодом 200 и надписью «на обслуживании» этого не делает. Если вы планируете простой, отвечайте 503 намеренно и, где можно, добавляйте Retry-After. Главное, чтобы 503 прекращалась, когда заканчиваются работы.