Ошибка 503 (Service Unavailable): что это значит и как исправить

Автор: Редакция Торох Опубликовано: 14 ноября 2026 8 минут чтения

503 Service Unavailable означает, что сервер принял запрос, но временно не может его обслужить: перегружен, находится на обслуживании или потерял внутренний компонент. Посетителю обычно достаточно подождать и обновить страницу. Владельцу сайта нужно смотреть логи веб-сервера, состояние обработчиков PHP-FPM или приложения и лимиты хостинга.

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

503 Service Unavailable — код состояния HTTP из группы 5xx. Сервер принял запрос и разобрал его, но прямо сейчас не может отдать ответ: перегружен, находится на обслуживании или потерял внутренний компонент — обработчик PHP, приложение, базу данных. Ключевое слово здесь — «временно»: по стандарту 503 описывает именно временную недоступность, и сервер вправе прислать заголовок Retry-After с числом секунд или датой, когда стоит повторить попытку.

В браузере это выглядит по-разному:

• страница самого сервера с крупной надписью «503 Service Unavailable», «Service Temporarily Unavailable», «Сайт временно недоступен»;
• стандартная страница браузера: «Веб-страница недоступна», «HTTP ERROR 503»;
• короткая строка «503» или «503 0» на белом фоне — так часто отвечает CDN, прокси или API;
• страница хостинга с текстом про превышение лимитов тарифа.

В инструментах разработчика (F12 → Network) видно сам код и заголовки ответа. Полезно посмотреть server, retry-after и x-cache: они подсказывают, кто именно ответил — ваш сервер, промежуточный прокси или сеть доставки контента.

Чем отличается от похожих кодов

Граница между 502 и 503 тонкая: если бэкенд вообще не принимает соединения, чаще отдаётся 502, а если сервер сознательно сообщает «я занят» или все узлы в пуле помечены как недоступные — 503. Разбор смежных ситуаций есть в материалах про ошибку 500 и 502 Bad Gateway в nginx.

Почему появляется 503

Со стороны посетителя

На клиенте код возникает редко. Типичные случаи: корпоративный прокси или фильтр трафика, антивирус с перехватом HTTPS, VPN с ограничениями, региональная блокировка на стороне CDN. Если сайт открывается с мобильного интернета, но не открывается по домашнему Wi-Fi, причина в сети и устройствах, а не в сайте.

Со стороны владельца

• Перегрузка: резкий рост трафика, поисковый бот, парсер, DDoS-атака.
• Исчерпание пула обработчиков: pm.max_children в PHP-FPM, MaxRequestWorkers в Apache, worker_connections в nginx.
• Лимиты тарифа хостинга: процессорное время, память, число процессов, операции ввода-вывода. Панель управления может принудительно останавливать сайт.
• Режим обслуживания: файл .maintenance в WordPress, страница обновления в CMS, отключённый бэкенд в балансировщике.
• Упавшее приложение: Node.js, Gunicorn, Tomcat не слушают порт или перезапускаются по кругу.
• Недоступная база данных, Redis или внешний API.
• Ошибка после деплоя: неверный upstream, забытая миграция, синтаксическая ошибка в конфиге.
• Остановленный пул приложений в IIS при веб-публикации.

Что делать посетителю

1. Подождите 30–60 секунд и обновите страницу (Ctrl+F5 или Cmd+Shift+R).
2. Повторите через 5–10 минут: 503 часто связан с коротким пиком или работами.
3. Откройте сайт в другом браузере и с мобильного интернета — так видно, локальная это проблема или общая.
4. Отключите VPN и прокси, проверьте антивирус с фильтрацией HTTPS.
5. Очистите кэш и cookies для домена, если 503 повторяется только у вас.
6. Не отправляйте форму или заказ много раз подряд: первый запрос мог быть принят.
7. Если это игра, банк или онлайн-сервис — проверьте официальную страницу состояния сервиса.

Что делать владельцу сайта

Шаг 1. Понять, кто отдаёт 503

curl -sI https://example.com/
dig +short example.com

Смотрите на server, via, x-cache, retry-after. Если ответил CDN или WAF, искать нужно в их панели, а не в конфиге сервера.

Шаг 2. Прочитать логи nginx

tail -n 200 /var/log/nginx/error.log
grep -c ' 503 ' /var/log/nginx/access.log

Что означают частые записи:

• no live upstreams while connecting to upstream — все бэкенды помечены недоступными после max_fails;
• connect() failed (111: Connection refused) while connecting to upstream — приложение не слушает порт;
• limiting requests, excess: ... by zone — сработал limit_req;
• worker_connections are not enough — исчерпан лимит соединений.

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

Шаг 3. Проверить, слушает ли бэкенд порт

ss -ltnp | grep -E ':(80|443|9000|3000|8080)'
systemctl status nginx php8.2-fpm

Имя юнита PHP-FPM зависит от версии и дистрибутива: php8.1-fpm, php8.2-fpm, php-fpm. Для просмотра журнала: journalctl -u php8.2-fpm -n 100 --no-pager.

Шаг 4. PHP-FPM

grep -E 'pm|max_children|max_requests' /etc/php/8.2/fpm/pool.d/www.conf
tail -n 100 /var/log/php8.2-fpm.log
ps -o rss= -C php-fpm8.2 | sort -n | tail -1

Признак проблемы в логе: WARNING: [pool www] server reached pm.max_children setting (5), consider raising it. Тогда правят пул:

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500
request_terminate_timeout = 60s
slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 5s

pm.max_children считают от свободной памяти и реального размера процесса (RSS из команды выше), а не «на глаз». После правки — systemctl reload php8.2-fpm.

Шаг 5. Apache

apachectl -M | grep -E 'mpm|status'
curl -s http://127.0.0.1/server-status?auto | head

В httpd.conf или конфиге MPM проверяют MaxRequestWorkers, ServerLimit, ThreadsPerChild (для mpm_event и mpm_worker). Если все воркеры заняты долгими запросами, помогает не только повышение лимита, но и устранение медленных скриптов.

Шаг 6. WordPress и другие CMS

ls -la /var/www/example.com/.maintenance
wp maintenance-mode status --path=/var/www/example.com
wp maintenance-mode deactivate --path=/var/www/example.com

Файл .maintenance появляется при обновлении и остаётся, если оно прервалось. Плагины проверяют отключением: переименуйте каталог wp-content/plugins и включайте папки по одной.

Шаг 7. Node.js и другие приложения

pm2 status
pm2 logs app --lines 100 --nostream
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/health

Если процесс в статусе errored или постоянно перезапускается, nginx отдаёт 503, потому что upstream мёртв. Проверьте потребление памяти, настройте --max-old-space-size, запустите несколько инстансов (pm2 start app.js -i max) и добавьте health-эндпоинт:

upstream app {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=10s;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=10s;
    keepalive 32;
}

С единственным узлом в upstream и включённым max_fails nginx после нескольких ошибок пометит его недоступным и начнёт отдавать 503 до истечения fail_timeout.

Шаг 8. База данных, диск, память

mysqladmin ping -h 127.0.0.1
pg_isready -h 127.0.0.1
redis-cli ping
df -h
free -m
uptime

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

Шаг 9. Заглушка на время работ

nginx:

location / {
    if (-f /var/www/example.com/maintenance.flag) {
        return 503;
    }
    try_files $uri $uri/ /index.php?$args;
}

error_page 503 /503.html;
location = /503.html { internal; root /var/www/example.com; }
add_header Retry-After 3600 always;

Apache (нужен mod_rewrite и mod_headers):

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.flag -f
RewriteRule ^ - [R=503,L]
ErrorDocument 503 /503.html
Header always set Retry-After 3600

Код 503 с заголовком Retry-After корректнее белого экрана и временной страницы с кодом 200: поисковые роботы понимают, что сайт вернётся.

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

• Мониторинг доступности. Внешняя проверка health-эндпоинта (UptimeRobot, Zabbix, Prometheus с blackbox_exporter) и оповещение о недоступности в мессенджер.
• Алерты по 5xx. Настройте log_format с $upstream_status и $upstream_response_time и следите за долей ответов 503, а не только за полным падением.
• Расчётные лимиты. Пул PHP-FPM, MaxRequestWorkers, worker_connections, limit_req и limit_conn должны соответствовать реальной нагрузке и памяти сервера.
• Кэширование. proxy_cache или fastcgi_cache в nginx и CDN перед сайтом снимают пики, не пропуская их к приложению.
• Резервирование. Второй сервер в upstream с max_fails и fail_timeout превращает падение одного узла в деградацию, а не в 503.
• Порядок обновлений. Обновляйте CMS и плагины на копии сайта, чтобы не оставлять файл .maintenance и не ловить 503 после деплоя.
• Гигиена сервера. Ротация логов, контроль свободного места и памяти, отключение неиспользуемых модулей.

Ошибка 503 в приложениях и сервисах

• Rust (мобильная версия). Серверы игры обслуживаются разработчиком; надпись «503» или «503 0» означает перегрузку или технические работы. На стороне игрока помогают ожидание, обновление клиента и смена сети.
• iMazing. Программа обращается к серверам Apple и собственным службам. Код 503 обычно говорит о временной недоступности сервиса или об обрыве соединения файрволом, VPN либо антивирусом. Стоит проверить сеть, отключить прокси и повторить позже.
• 1С. Ошибка приходит при обмене с внешними сервисами (ЭДО, банк, облачные сервисы) или при веб-публикации через IIS, Apache, nginx. Смотрите журнал регистрации, настройки прокси и сертификатов, а при публикации — состояние пула приложений или PHP-FPM.
• Госуслуги, банки, интернет-магазины. 503 на портале — почти всегда нагрузка на стороне оператора сервиса; на клиенте остаётся подождать, сменить сеть и проверить официальный статус.

Материал подготовлен редакцией справочника Торох и носит справочный характер: интерфейсы программ и настройки серверов зависят от версии. Нашли неточность? Напишите нам.