Что обещает 503, а что нет
503 — это сервер, говорящий «я существую, я тебя понял, зайди попозже». В отличие от 500, он не утверждает, что что-то сломалось, а в отличие от 502 — речь не о неудавшемся разговоре с машиной где-то дальше. Это отказ с подразумеваемым «пока что».
Именно это «пока что» делает 503 правильным кодом для планового обслуживания и для перегрузки — и неправильным для чего-то постоянного. Поисковики считают его временным и обязательно зайдут снова, а это именно то, что нужно во время деплоя, и именно то, что не нужно на странице, которую вы вывели из эксплуатации, — для неё нужен 410 или 301.
Причина 1 — у origin закончилась ёмкость
У каждого сервера есть потолок одновременной работы: воркеры PHP-FPM, воркеры приложения, соединения с базой данных. Когда потолок достигнут, грамотно настроенный стек быстро отказывает в новой работе через 503, вместо того чтобы принять её и уйти в таймаут. Это система, которая правильно ведёт себя под давлением, даже если со стороны это похоже на сбой.
Как распознать. 503 следует за трафиком: появляется на пиках и пропадает, когда пик проходит. Ваш origin всё это время жив и мгновенно отвечает на запрос, сделанный в спокойный момент.
Что реально помогает. Увеличение числа воркеров сдвигает потолок и обычно переносит узкое место на память или базу данных. Долговременное решение — вообще перестать посылать на origin повторяющуюся работу: кэшируйте страницы, которые можно кэшировать, дайте им достаточно долгий TTL, и пусть пик поглощает edge. Кампания, которая «плавит» origin на 200 запросах в секунду, часто на деле — 195 запросов одной и той же горстки страниц.
Причина 2 — режим обслуживания
Инструменты деплоя и плагины CMS прячут сайт за страницей обслуживания и возвращают 503, пока идёт работа. Это правильное поведение, и код выбран верно.
С этим ломаются две вещи. Первая — режим обслуживания, который никогда не снимают: неудавшийся деплой оставляет файл-флаг на месте, и сайт отдаёт 503 ещё долго после того, как работа завершилась. Вторая — страница обслуживания, отданная с кодом 200: это говорит краулерам, что уведомление об обслуживании и есть ваш настоящий контент, который стоит индексировать.
Если режим обслуживания включён дольше нескольких минут, добавьте заголовок Retry-After. Это одна строка, а разница — между краулером, который вежливо отступает, и краулером, который решает, что ваш сайт ненадёжен.
Причина 3 — запрос отклонил rate limiting
Rate limiting отказывает запросам, которые приходят чаще настроенного порога. В зависимости от софта и его настроек отказ приходит либо как 429 Too Many Requests, либо как 503 — например, nginx по умолчанию отказывает превысившим лимит запросам именно через 503, если ему явно не сказали использовать другой код.
Это важно при чтении логов: всплеск 503 у одного клиента, одного пути или одного user agent, пока всё остальное отдаётся нормально, — это rate limiting, который делает свою работу, а не проблема с ёмкостью. Разбираться нужно с тем, кто именно упирается в лимит. Если это скрапер — лимит работает как надо. Если это ваше собственное мобильное приложение, опрашивающее эндпоинт каждую секунду, — лимит верный, а неправо приложение.
Причина 4 — у edge нет origin для этого хоста
Это та причина, что съедает целый день, и она вообще не имеет отношения к вашему серверу.
Когда DNS хоста указывает на edge CDN, но сам хост ещё не настроен на этом edge — аккаунт ещё не создан, хост доставки не добавлен, или опечатка отправила запись не на то имя, — edge просто некого спросить. Вернуть 502 он не может, потому что никакого несостоявшегося разговора не было. Он возвращает 503 со страницей о том, что для этого домена не настроен ни один сервис.
Последовательность, которая к этому приводит, всегда одна и та же: кто-то сначала меняет DNS, а настройку в панели заканчивает позже, либо меняет DNS для www, пока хост был добавлен как голый домен. Сайт «падает» в момент, когда DNS распространился, origin при этом абсолютно здоров, а решение занимает минуту, как только вы перестаёте смотреть не на ту машину.
Как распознать мгновенно. Читайте страницу ошибки, а не только код ответа. Страница CDN «сервис не настроен» узнаётся безошибочно и прямо называет проблему. Затем проверьте, что хост в вашей панели в точности совпадает с именем в DNS-записи, включая www.
Что отправлять и что должны видеть посетители
Если 503 отдаёте именно вы, две вещи сильно снижают цену этого решения.
Отправляйте Retry-After. Либо число секунд, либо дату по HTTP. Краулеры его учитывают, аккуратно написанные клиенты — тоже, и отказ превращается в расписание.
Покажите что-то человеческое. Страница ошибки прокси по умолчанию ничего не говорит посетителю и выглядит сломанной. Брендированная страница с одним предложением о том, что происходит, — совсем небольшая работа ради большой разницы в том, как переживается инцидент.
И если контент кэшируемый, CDN может продолжать отдавать закэшированную копию, пока origin отказывает, — а это разница между «сайт десять минут тормозил» и «сайт десять минут не работал».
Частые вопросы
503 — это лучше или хуже, чем 502?
Информативнее. 503 — это осознанный отказ, а значит, что-то на пути запроса работает достаточно хорошо, чтобы принять решение. 502 означает, что не удался разговор с машиной позади. На практике 503 чаще связан с ёмкостью или конфигурацией, которую вы контролируете, а 502 — чаще со сломанным origin.
Вредит ли 503 позициям в поиске?
Нет, если он действительно временный. Поисковики воспринимают 503 как «зайти попозже», поэтому это правильный код во время обслуживания. 503, который держится днями, — другое дело: страницы в итоге выпадут из индекса. Добавьте Retry-After, чтобы краулер знал, чего ждать.
Я получаю 503 сразу после того, как направил DNS на CDN. Что делать?
Проверьте страницу ошибки. Если там написано, что для домена не настроен сервис, хост ещё не настроен на edge — origin тут вообще ни при чём. Добавьте в панели точный хост, с www или без него — так, чтобы он совпадал с DNS-записью, — и 503 исчезнет, как только конфигурация дойдёт до edge-узлов.
Можно ли кэшировать 503?
Не стоит — разве что на несколько секунд. Закэшированный 503 продолжает отказывать посетителям уже после того, как причина исчезла. Отдавайте ответы с ошибками с очень коротким TTL и очищайте кэш для этого пути сразу после исправления.
Как остановить 503 под нагрузкой без более мощного сервера?
Уменьшите то, что доходит до origin. Кэшируйте всё, что можно кэшировать, с TTL, который переживёт всплеск трафика, убедитесь, что ключ кэша не дробится параметрами отслеживания, и держите rate limiting на эндпоинтах, которые притягивают автоматический трафик. Более мощный сервер поднимает потолок; кэширование убирает большинство запросов, которые в этот потолок упирались.