Ошибка 503 Service Unavailable: что значит и как починить

Ошибка 503 — самая «честная» из серверных ошибок: сервер прямо говорит, что сейчас не может обработать запрос. Пользователь видит страницу «Сервис временно недоступен», а владелец сайта теряет заказы. Особенно коварно, когда 503 отдаёт не само приложение, а балансировщик, у которого не осталось ни одного живого бэкенда.

Коротко: код 503 означает временную недоступность — из-за перегрузки, нехватки ресурсов, сработавшего rate limiting или плановых работ. В отличие от 500 и 502, за 503 обычно стоит не «сломалось», а «не справляюсь». Ниже разберём, кто и почему возвращает 503, как за пару минут найти виноватый слой и как устранить каждую из причин.

Что означает ошибка 503

Код 503 относится к группе 5xx — ошибок на стороне сервера. По спецификации HTTP (RFC 9110) он означает, что сервер временно не может обработать запрос из-за перегрузки или планового обслуживания и, скорее всего, справится с этим через некоторое время. В ответ можно добавить заголовок Retry-After — подсказку, через сколько секунд или в какой момент стоит повторить запрос.

Важно понять, кто именно вернул 503. Это может быть:

• само приложение — когда оно сознательно отказывается обслуживать запросы: исчерпан пул соединений с базой, заняты все воркеры, недоступна критичная зависимость;
• nginx — когда срабатывает rate limiting (limit_req и limit_conn по умолчанию отвечают именно 503) или включён режим обслуживания;
• балансировщик — когда не осталось ни одного здорового бэкенда (HAProxy) или в целевой группе нет зарегистрированных целей (AWS ALB);
• Envoy, Varnish и сервис-меши вроде Istio — когда не удаётся соединиться с бэкендом или нет ни одного здорового экземпляра;
• Kubernetes — когда у сервиса нет ни одного готового пода и Ingress-контроллеру некуда отправить запрос.

Как выглядит ошибка 503

Текст зависит от того, какой слой вернул ошибку:

• «503 Service Temporarily Unavailable» — встроенная страница nginx (в том числе ingress-nginx в Kubernetes) и AWS Application Load Balancer;
• «Service Unavailable» с пояснением «The server is temporarily unable to service your request…» — Apache;
• «No server is available to handle this request» — HAProxy;
• «Error 503 Backend fetch failed» и «Guru Meditation» — Varnish;
• «no healthy upstream» или «upstream connect error or disconnect/reset before headers» — Envoy и сервис-меши на его основе;
• «Сервис временно недоступен», «Ведутся технические работы» — собственные страницы обслуживания;
• в API — просто код 503, JSON с описанием ошибки и, если повезёт, заголовок Retry-After.

Подсказка: по тексту страницы и заголовку Server обычно видно, какой слой сдался. Это первый шаг диагностики.

Чем 503 отличается от 500, 502 и 504

• 500 Internal Server Error — приложение упало при обработке запроса: исключение, ошибка в коде или конфигурации.
• 502 Bad Gateway — прокси получил от бэкенда отказ в соединении или некорректный ответ: процесс не запущен, порт закрыт, соединение оборвалось.
• 503 Service Unavailable — запрос не смогли принять: перегрузка, лимиты, обслуживание или нет живых бэкендов.
• 504 Gateway Timeout — прокси не дождался ответа от бэкенда за отведённое время.

Простая шпаргалка: 502 — «бэкенд ответил плохо», 504 — «бэкенд не ответил вовремя», 503 — «запрос не приняли или его некому передать». Граница при этом размыта: например, nginx, у которого все upstream-серверы помечены недоступными, вернёт не 503, а 502 — в error-логе будет no live upstreams. Подробные разборы — в статьях «Ошибка 502 Bad Gateway» и «Ошибка 504 Gateway Timeout».

Основные причины ошибки 503

Не осталось живых бэкендов

Один из самых частых сценариев в инфраструктуре с балансировщиками: приложение упало, перезапускается или не проходит health check, балансировщик выводит бэкенды из ротации — и запросам больше некуда идти. В Kubernetes 503 от Ingress обычно означает, что у сервиса нет готовых подов: они не проходят readiness-пробу или ещё не запустились. Коварно то, что это часто случается прямо во время деплоя: слишком строгая проба выводит из ротации бэкенд, который просто медленно стартует, а старые поды к этому моменту уже остановлены.

Нехватка воркеров, памяти и соединений

Все воркеры заняты, память на исходе, пул соединений с базой пуст — и приложение отвечает 503, вместо того чтобы держать пользователя в очереди минуту. Это правильное поведение: лучше быстро отказать, чем копить очередь (этот подход называют load shedding). Но за ним всё равно стоит нехватка ресурсов или всплеск нагрузки.

Rate limiting и защита от перегрузки

nginx при срабатывании limit_req и limit_conn по умолчанию возвращает 503, так же могут отвечать WAF и сервисы защиты от DDoS. Если легитимный трафик упирается в лимит, пользователи увидят именно 503.

Плановые работы и деплой

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

Сбой обязательной зависимости

Приложение отвечает 503, когда недоступна критичная зависимость — база данных, платёжный шлюз, внешний API. Сервис честно сообщает «я не готов», а не отдаёт пользователю неполные или неверные данные.

Шаг 1. Найдите слой, который вернул 503

Отправьте запрос и посмотрите на заголовки и текст ответа:

curl -sS -i https://example.com | head -n 30

Заголовок Server, заголовки вроде Via и формулировка ошибки из списка выше подскажут, кто отвечает: приложение, nginx, балансировщик или CDN. Дальше изучайте логи именно этого слоя.

Шаг 2. Если это балансировщик — проверьте бэкенды

Посмотрите статус health check-ов: жив ли хоть один бэкенд. В Kubernetes проверьте, есть ли у сервиса готовые адреса:

kubectl get endpointslices -l kubernetes.io/service-name=my-service
kubectl describe pod <имя-пода>

Пустой список адресов означает, что ни один под не готов, — причину ищите в событиях пода и в readiness-пробе. Если 503 появляется только во время деплоя, трафик снимается со старых бэкендов раньше, чем новые готовы его принять. Настройте graceful shutdown в приложении, корректные readiness-пробы и стратегию обновления (например, maxUnavailable: 0), чтобы балансировщик ни на секунду не оставался без живых бэкендов.

Шаг 3. Если это nginx — проверьте лимиты

Сработавший rate limit виден в error-логе nginx по строке limiting requests, excess: … by zone "…". Если 503 вызвана троттлингом, увеличьте rate или burst либо перенесите ограничения на уровень приложения. Семантически правильный код для троттлинга — 429 Too Many Requests, а 503 лучше оставить для реальной недоступности:

limit_req_status 429;
limit_conn_status 429;

Шаг 4. Сопоставьте сбои с расписанием

Если 503 повторяется в одно и то же время, ищите связь с расписанием: деплои, ночные бэкапы, импорты, тяжёлые cron-задачи, которые совпадают с пиком трафика и забирают ресурсы.

Как исправить ошибку 503

• Не осталось живых бэкендов — откатите релиз или перезапустите упавший сервис, затем ищите причину в логах. На будущее — graceful shutdown и адекватные health-пробы.
• Не хватает ресурсов — увеличьте число воркеров и размер пула соединений (если хватает памяти и база выдержит), настройте автомасштабирование так, чтобы оно срабатывало до пика, а не после него.
• Rate limiting — пересмотрите лимиты и отделите троттлинг (429) от недоступности (503).
• Плановые работы — короткие окна обслуживания, 503 с Retry-After и заранее опубликованные плановые работы на Статус Странице.
• Сбои зависимостей — таймауты, circuit breaker и частичная деградация вместо полного отказа; тяжёлые операции — в фоновые задачи.

Плановые работы: как правильно отдавать 503

На время обслуживания nginx может отдавать 503 со своей страницей и заголовком Retry-After:

server {
    # ...

    if (-f /var/www/maintenance) {
        return 503;
    }

    error_page 503 @maintenance;

    location @maintenance {
        root /var/www;
        add_header Retry-After 600 always;
        rewrite ^ /maintenance.html break;
    }
}

Файл /var/www/maintenance создаётся в начале работ и удаляется после. Обратите внимание на именованный location @maintenance: если указать в error_page обычный путь вроде /maintenance.html, внутренний редирект снова попадёт под условие if, и nginx отдаст свою стандартную страницу — без вашего текста и без Retry-After.

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

Как мониторинг ловит 503 раньше пользователей

503 часто появляется не на главной, а в личном кабинете, на оформлении заказа или в API — там, куда владелец сайта не заглядывает. Поэтому о ней важно узнавать от мониторинга, а не из жалоб.

Мониторинг доступности Pingera проверяет страницы и API из нескольких регионов. По умолчанию проверка считается проваленной при любом ответе с кодом 4xx или 5xx, а для каждой сохраняются код, заголовки и время ответа — сразу видно, какой слой вернул 503. Автоматический повтор проверки отсекает ложные срабатывания, а пошаговые API-проверки и синтетические сценарии на Playwright находят 503 там, где простой GET-запрос её не увидит.

Правила алертов позволяют реагировать на несколько неудачных проверок подряд, а не на разовый всплеск. Уведомления приходят в Telegram, MAX, на почту, по SMS или в вебхук, а Статус Страница может обновиться автоматически — клиенты увидят, что вы уже знаете о проблеме. Проверить, как алерты реагируют на 503, можно без поломки продакшна: адрес https://app.pingera.ru/tools/code/503 всегда отвечает кодом 503 — подробнее в статье об HTTP-инструментах Pingera.

Начать можно на бесплатном тарифе; на тарифах Про (от 1800 ₽/мес) интервал проверок — от 30 секунд.

Часто задаваемые вопросы

Итог

503 Service Unavailable — не «сайт сломался», а «сервер не справляется или его обслуживают». Сначала определите по заголовкам и тексту ошибки, кто её вернул, затем проверьте бэкенды и лимиты, а плановые работы оформляйте коротким окном с Retry-After. И поставьте сайт на мониторинг: Pingera сообщит о 503 в первые минуты — обычно раньше, чем напишет первый недовольный пользователь.