Service Unavailable 503 — HTTP-статус, означающий временную недоступность сервера. В отличие от 500 (Internal Server Error), 503 явно сигнализирует, что сервер жив и понимает запрос, но сейчас не может его обработать — из-за перегрузки, технического обслуживания или исчерпания ресурсов.
Как работает
503 возникает в нескольких сценариях:
- Перегрузка upstream: Nginx не может подключиться к PHP-FPM/Node.js — все воркеры заняты
- Maintenance mode: намеренный 503 при обновлении сайта
- Rate limiting: превышен лимит соединений (хотя правильнее возвращать 429)
- Нет upstream: бэкенд-сервис упал, Nginx не может к нему подключиться
PHP-FPM возвращает 503 при исчерпании пула воркеров (pm.max_children). Настройка в /etc/php/8.2/fpm/pool.d/www.conf: увеличение pm.max_children решает проблему перегрузки, но требует достаточного объёма RAM.
Для плановых работ 503 — правильный выбор. Nginx может отдавать статическую страницу обслуживания:
error_page 503 /maintenance.html;
location /maintenance.html {
root /var/www/maintenance;
internal;
}История
503 определён в RFC 7231. До широкого распространения load balancers 503 был относительно редким. С микросервисами и облачными архитектурами 503 стал обычным явлением: один из сервисов в цепочке перегружен — весь запрос возвращает 503 пользователю. Circuit breaker паттерн помогает изолировать сбойные сервисы.
На что обращать внимание
Важный HTTP-заголовок при 503: Retry-After — указывает клиенту, через сколько секунд повторить запрос. Поисковые роботы Googlebot и Yandex Bot уважают 503 с Retry-After — не исключают страницу из индекса при кратковременной недоступности.
Мониторинг 503 через Grafana — обязателен для продакшн. Всплеск 503 — сигнал о перегрузке или сбое. Проверьте journalctl и логи приложения. Превентивная мера — мониторинг утилизации CPU и RAM с алертами до достижения критических порогов.
503 при деплое и Rolling Update
При деплое новой версии приложения важно избегать 503. Стратегии zero-downtime deploy:
- Blue-Green: поднять новую версию параллельно, переключить трафик через Nginx upstream, старую отключить
- Rolling update: последовательно обновлять экземпляры по одному, остальные принимают трафик
- Canary: направить 5% трафика на новую версию, постепенно увеличивать процент
Для single-server деплоя (распространённый случай на VPS) помогает правильная последовательность: скопировать файлы → запустить миграции БД → перезапустить приложение с systemctl reload (graceful reload без разрыва активных соединений) → проверить статус.
Nginx upstream с несколькими бэкендами автоматически исключает недоступный бэкенд из ротации при получении 503 — это базовый health check. Параметры max_fails=3 fail_timeout=30s определяют, сколько ошибок подряд нужно для исключения и на сколько секунд.
SEO-аспект: Google Search Console фиксирует 503 при краулинге. Кратковременный 503 с заголовком Retry-After: 3600 не причинит вреда позициям — бот вернётся через час. Но если сайт возвращает 503 несколько дней подряд, страницы начнут выпадать из индекса. Мониторинг доступности с алертами на email/Telegram — обязательный элемент для любого коммерческого сайта.