Ошибка 503 Service Unavailable: почему возникает и что делать

HTTP 503 Service Unavailable означает, что сервер сейчас не готов обработать запрос. RFC 9110 описывает этот статус как временную недоступность из-за перегрузки или планового обслуживания. Это отличается от общего 500 Internal Server Error: 503 обычно сообщает не о неизвестной внутренней ошибке, а о временном состоянии, после которого запрос имеет смысл повторить.

Для диагностики недостаточно увидеть число 503. Нужно определить, какой компонент сформировал ответ и почему он решил не обслуживать запрос. В современной инфраструктуре это может быть CDN, балансировщик, Nginx, Kubernetes ingress, само приложение или защитный слой перед ним.

Что означает HTTP 503

Типичная цепочка:

клиент → CDN / load balancer → Nginx / ingress → приложение → БД / внешние API

503 может появиться на разных уровнях. Например, приложение само возвращает его, когда исчерпан пул соединений с БД. В другом случае ingress не видит ни одного готового backend и не может направить запрос.

RFC 9110 также допускает заголовок Retry-After, который сообщает, когда клиенту разумно повторить запрос.

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/html

Retry-After: 120 означает рекомендацию повторить запрос примерно через 120 секунд. Заголовок также может содержать HTTP-дату.

Важно: перегруженный сервис не обязан всегда успевать вернуть 503. При тяжёлом отказе соединение может обрываться, TCP-порт перестать принимать подключения, а промежуточный proxy — вернуть 502 или 504.

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

Код задаёт направление поиска, но не заменяет логи.

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

Перегрузка приложения

Приложение может сознательно отказывать новым запросам, когда достигнут эксплуатационный предел:

• закончились worker-процессы или потоки;
• заполнена очередь запросов;
• исчерпан пул соединений с БД;
• не хватает памяти;
• достигнут лимит файловых дескрипторов;
• контейнер сильно ограничен по CPU;
• внутренний limiter защищает систему от перегрузки.

Характерный признак — корреляция с ростом нагрузки и восстановление после её снижения.

Технические работы

503 подходит для временного maintenance-режима. Если сервис сознательно недоступен, корректнее вернуть настоящий 503, а не HTML-страницу «технические работы» с 200 OK.

Ответ 200 вводит в заблуждение автоматических клиентов и мониторинг: транспортный уровень сообщает об успехе, хотя пользовательская функция недоступна.

Нет готовых backend-инстансов

В Kubernetes или другой оркестрируемой инфраструктуре ingress может остаться без ready backend.

Проверьте:

kubectl get pods
kubectl get endpoints
kubectl describe pod <pod-name>

Смотрите на READY, restarts, failing readiness и события deployment.

Исчерпан пул соединений с БД

CPU может быть низким, а новые запросы всё равно не обслуживаться из-за отсутствия свободных DB connections.

Ищите:

• активные соединения;
• очередь ожидания пула;
• длинные транзакции;
• медленные запросы;
• лимиты БД и приложения.

Простое увеличение pool size без причины способно сильнее перегрузить БД.

Недоступна обязательная зависимость

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

Важно разделять критичные и второстепенные зависимости. Отказ аналитики не должен останавливать checkout, если архитектура позволяет безопасно деградировать.

Диагностика 503 по шагам

Шаг 1. Подтвердите настоящий HTTP-ответ

curl -i https://example.com/

Смотрите статус, Server, Retry-After, CDN-заголовки, тело ответа и request ID.

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

curl -v https://example.com/

Не публикуйте вывод -v без проверки: он может содержать cookies и чувствительные заголовки.

Шаг 2. Определите масштаб

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/login
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/api/health

Если 503 возвращает один endpoint, начинайте с его обработчика и зависимостей. Если почти весь сервис — выше приоритет у общей инфраструктуры, capacity, deployment, БД и readiness.

Шаг 3. Определите компонент, который вернул 503

В production цепочка может выглядеть так:

клиент → CDN → load balancer → Nginx → приложение

Проверяйте заголовки и request ID. Не делайте вывод «это Nginx» только по внешнему виду страницы ошибки.

Шаг 4. Сопоставьте proxy log и application log

Для Nginx:

sudo tail -n 200 /var/log/nginx/access.log
sudo tail -n 200 /var/log/nginx/error.log

Docker:

docker logs --since 10m <container_name>

Kubernetes:

kubectl logs <pod-name> --since=10m

Лучший вариант — один request_id или trace_id на всех уровнях.

Шаг 5. Проверьте upstream напрямую

Если это безопасно:

curl -i http://127.0.0.1:8080/health

• upstream 200, публичный URL 503 — исследуйте proxy/ingress/routing;
• upstream тоже 503 — переходите к приложению и зависимостям;
• соединение не устанавливается — проверяйте процесс, порт, сеть контейнера и firewall.

Не открывайте внутренний порт в интернет ради диагностики.

Шаг 6. Проверьте ресурсы и saturation

Docker:

docker stats

Kubernetes:

kubectl get pods
kubectl describe pod <pod-name>
kubectl get events --sort-by=.lastTimestamp

Проверяйте память, OOM, CPU throttling, worker, queues, connection pools, ready replicas и restarts.

Шаг 7. Сопоставьте первый 503 с изменениями

Проверьте deployment, миграции, конфигурацию, рост трафика, autoscaling, сбой БД и внешних зависимостей. Корреляцию по времени нужно подтверждать логами и метриками.

Почему увеличение timeout обычно не лечит 503

503 означает временную неготовность обслужить запрос. Если gateway слишком долго ждёт upstream, типичный код — 504. Поэтому механическое увеличение proxy_read_timeout часто затрагивает не тот механизм.

Как проверить восстановление

Один успешный запрос недостаточен:

for i in {1..10}; do
  curl -sS -o /dev/null \
    -w '%{http_code} %{time_total}\n' \
    https://example.com/
  sleep 2
done

Нужно увидеть стабильные успешные коды, нормальное время ответа и отсутствие чередования 200/503.

Если за балансировщиком несколько backend, чередование успеха и ошибки часто указывает на одну оставшуюся неисправную реплику.

Как предотвращать повторные 503

• контролировать saturation, а не только CPU;
• задавать реалистичные resource limits;
• иметь осмысленную readiness-проверку;
• контролировать pools и очереди;
• ограничивать тяжёлые операции;
• планировать capacity;
• тестировать rollback;
• проверять критичные URL после deployment.

Автоматическое обнаружение

UpWatch можно использовать для регулярной проверки критичного публичного URL. Это не заменяет server logs, но фиксирует внешний факт сбоя, время его начала и восстановления.

Типичные ошибки

Сразу перезапускать всё

Перезапуск может убрать симптом и одновременно уничтожить часть диагностического контекста. Сначала сохраните логи и ключевые метрики.

Смотреть только на CPU

503 может быть вызван DB pool или отсутствием ready backend при низком CPU.

Увеличивать лимиты без причины

При утечке соединений больший pool лишь отсрочит повторение.

Практический чек-лист

1. Подтвердить 503 через curl.
2. Зафиксировать время, URL и заголовки.
3. Проверить один endpoint или весь сервис.
4. Определить компонент, сформировавший 503.
5. Сопоставить proxy и application logs.
6. Проверить upstream напрямую.
7. Проверить readiness, capacity, pools и зависимости.
8. Сверить проблему с deployment.
9. Исправить корневую причину.
10. Подтвердить восстановление серией запросов.

Источники и спецификации

• RFC 9110: 503 Service Unavailable
• RFC 9110: Retry-After