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

Ошибка 503 означает, что сервер получил запрос, но временно не может его обработать: он перегружен, закрыт на обслуживание или за ним не осталось ни одного живого бэкенда. Это не поломка браузера или интернета у посетителя. Обычно помогает повторить запрос через минуту, а владельцу сайта нужно найти звено, которое отвечает 503: nginx, балансировщик, PHP-FPM или само приложение.

Что значит код 503 Service Unavailable

По RFC 9110 §15.6.4 статус 503 Service Unavailable означает, что сервер сейчас не в состоянии обработать запрос из-за временной перегрузки или планового обслуживания и, скорее всего, сможет сделать это позже. В отличие от 500 это не исключение в коде: причина известна серверу и обычно временная. Краткое описание есть и в справочнике MDN.

Вместе с 503 сервер может отправить заголовок Retry-After — через сколько секунд (или после какой даты) стоит повторить запрос. Стандарт не делает его обязательным, но на практике он нужен: без него клиенты, API-библиотеки и роботы ретраят вслепую и добивают и без того перегруженный сервер. Поисковые роботы Google и Яндекса воспринимают 503 как временную проблему и не удаляют страницы из индекса сразу.

Коротко о терминах: «Service Unavailable» и «Service Temporarily Unavailable» — один и тот же код 503, просто разные серверы подписывают его по-разному. Русские формулировки «сервис временно недоступен» и «ошибка сервиса 503» — перевод той же фразы.

Как выглядит 503: тексты сообщений и кто их выдаёт

По тексту на странице почти всегда можно понять, какой компонент ответил. Это экономит время: чинить нужно именно его, а не всё подряд.

Ошибка 503 на сайте: что делать посетителю

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

• Подождать минуту-две и обновить страницу (F5). Перегрузка и короткое обслуживание часто проходят сами.
• Не нажимать обновление каждую секунду: при перегрузке это только добавляет запросов.
• Проверить, отвечает ли сайт извне, через проверку HTTP-заголовков: если там тоже 503, сайт недоступен для всех, а не только для вас.
• Если ошибка держится часами — написать владельцу сайта или в поддержку сервиса.

Если 503 выдаёт программа или приложение (например, iMazing при загрузке данных, мобильный банк, клиент API), это ответ удалённого сервиса, к которому программа обращается. Исправить его на своём компьютере нельзя: остаётся повторить позже, обновить программу и посмотреть страницу статуса сервиса.

Причины 503 ошибки сервера

1. Перегрузка сервера — CPU/RAM исчерпан, все worker'ы заняты. Бывает при всплеске трафика, распродаже или атаке.
2. Maintenance mode — админ выключил сайт на обновление или деплой.
3. PHP-FPM пул исчерпан — все children заняты, новые запросы стоят в очереди. Apache в этом случае отдаёт 503, nginx — чаще 502 или 504.
4. Rate limiting — nginx limit_req/limit_conn, WAF или CDN ограничили трафик. По умолчанию nginx отвечает на превышение лимита именно кодом 503.
5. Healthcheck fail в Kubernetes — pod не готов, readinessProbe failed, у Service нет endpoints.
6. Upstream overload за load balancer — все backend'ы помечены как unhealthy, балансировщику некуда отправить запрос.
7. Лимиты хостинга — на виртуальном хостинге сайт упирается в ограничение числа процессов или нагрузки тарифа.
8. Остановленный сервис — упал пул приложений IIS, служба 1С или контейнер приложения.

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

Коды 5xx часто путают, хотя они указывают на разные места поломки. 503 — единственный из них, который по смыслу обещает «попробуйте позже».

Подробные разборы соседних кодов: 502 Bad Gateway и 504 Gateway Timeout.

Как проверить, кто отдаёт 503

Начните с внешней проверки: HTTP Header Checker от Enterno.io покажет код ответа, заголовок Retry-After и заголовок Server, по которому видно, ответил nginx, Apache или CDN. Если Retry-After нет, сервер не настроил 503 правильно. Чтобы не ловить проблему вручную, поставьте сайт на мониторинг доступности — он зафиксирует время начала и конца сбоя.

Дальше — на сервере:

curl -I https://example.com
# HTTP/2 503
# Retry-After: 120
# Content-Type: text/html

# Сервер: проверьте нагрузку
top -bn1 | head -20
free -m
ss -s

# PHP-FPM status
systemctl status php8.4-fpm
curl http://127.0.0.1/fpm-status

# Сколько ответов 503 в access.log (формат combined, код — 9-е поле)
awk '$9 == 503' /var/log/nginx/access.log | tail -20

# Сработали ли лимиты nginx
grep -E "limiting (requests|connections)" /var/log/nginx/error.log | tail -20

В Windows проверить ответ можно в PowerShell: curl.exe -I https://example.com (именно curl.exe, потому что curl в Windows PowerShell — псевдоним Invoke-WebRequest). Как читать и где искать логи nginx, подробно описано в статье «Логи nginx».

503 Service Temporarily Unavailable в nginx

Сам nginx отдаёт 503 в трёх случаях: сработал limit_req (ограничение частоты запросов), сработал limit_conn (ограничение одновременных соединений) или в конфиге явно написано return 503. Если же все серверы в upstream недоступны, nginx пишет в лог no live upstreams и отвечает 502, а не 503. Поэтому при 503 от nginx в первую очередь смотрите лимиты и флаги обслуживания.

limit_req и limit_conn

В error.log превышение лимита выглядит как limiting requests, excess: ... by zone "api" или limiting connections by zone "perip". Если под лимит попадают обычные посетители, увеличьте rate или burst, а отказы отдавайте кодом 429, чтобы не путать их с настоящей недоступностью:

limit_req_zone $binary_remote_addr zone=api:10m rate=60r/m;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;  # лучше 429 чем 503 для rate limit
    proxy_pass http://backend;
}

Для rate limiting используйте 429 Too Many Requests, не 503. Для лимита соединений аналогично работает limit_conn_status 429; — обе директивы описаны в документации nginx. Подробнее о защите API — в статье «Защита API от перегрузки».

nginx: правильный 503 для maintenance

server {
    # Maintenance toggle
    if (-f /var/www/maintenance.flag) {
        return 503;
    }

    error_page 503 @maintenance;
    location @maintenance {
        root /var/www/maintenance;
        rewrite ^(.*)$ /503.html break;
        add_header Retry-After 300 always;
    }
}

После правок конфигурации всегда проверяйте синтаксис и перечитывайте конфиг без остановки: nginx -t && systemctl reload nginx. Забытый файл maintenance.flag — частая причина того, что сайт «висит» в 503 после окончания работ.

503 в Apache и PHP-FPM

Apache отвечает 503, когда модуль mod_proxy не может подключиться к бэкенду. Для PHP-FPM через proxy_fcgi в error.log появляется строка с failed to make connection to backend, для HTTP-бэкенда — attempt to connect to ... failed. Проверьте, запущен ли бэкенд и совпадает ли адрес сокета в конфиге:

grep -i "proxy" /var/log/apache2/error.log | tail -20
systemctl status php8.4-fpm
ls -l /run/php/

# Пул упёрся в max_children?
grep "max_children" /var/log/php8.4-fpm.log | tail

Сообщение server reached pm.max_children setting (50), consider raising it означает, что все процессы пула заняты. Тогда увеличьте пул:

PHP-FPM: увеличение worker пула

# /etc/php/8.4/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

Рассчитывайте max_children как (RAM_MB - 500) / 30, где 30MB — ориентировочный размер PHP worker. Реальный размер лучше измерить: ps -o rss= -C php-fpm8.4 покажет потребление каждого процесса в килобайтах. Если памяти не хватает на нужное число процессов, ищите медленные запросы (request_slowlog_timeout и slowlog в том же файле пула), а не просто поднимайте лимит.

PHP: 503 во время деплоя

<?php
if (file_exists(__DIR__ . '/maintenance.flag')) {
    header('HTTP/1.1 503 Service Unavailable');
    header('Retry-After: 300');
    header('Content-Type: text/html; charset=utf-8');
    readfile(__DIR__ . '/503.html');
    exit;
}

В WordPress тот же механизм встроен: во время обновления в корне сайта создаётся файл .maintenance, и все посетители получают 503. Если обновление прервалось, файл остаётся — удалите его вручную (rm .maintenance в корне сайта), и сайт откроется.

No server is available to handle this request (HAProxy)

Эта фраза — встроенная страница ошибки HAProxy. Она появляется, когда балансировщику некуда отправить запрос: все серверы бэкенда помечены DOWN по результатам health check, переведены в maintenance или запрос простоял в очереди дольше timeout queue. В логе HAProxy такой запрос отмечен как <NOSRV> вместо имени сервера.

# Состояние серверов (нужен stats socket в конфиге HAProxy)
echo "show stat" | socat stdio /run/haproxy/admin.sock | cut -d, -f1,2,18

# Проверить бэкенд напрямую тем же запросом, что и health check
curl -I http://10.0.0.11:8080/health

# Проверить конфиг перед перезагрузкой
haproxy -c -f /etc/haproxy/haproxy.cfg

Типичные причины: health check ходит на URL, который перестал отвечать 200 (например, /health требует авторизации после обновления), бэкенды упали или не слушают порт, слишком маленький maxconn на серверах при всплеске трафика. Путь к сокету зависит от директивы stats socket в вашем конфиге.

no healthy upstream и 503 в Kubernetes

Ответ no healthy upstream с кодом 503 отдаёт Envoy (и Istio, который на нём построен), когда в кластере апстрима нет ни одного здорового экземпляра. В логах доступа Envoy такой ответ помечен флагом UH. Похожая ошибка upstream connect error or disconnect/reset before headers означает, что экземпляры есть, но подключиться к ним не удалось. ingress-nginx в той же ситуации отвечает «503 Service Temporarily Unavailable».

# Есть ли у сервиса готовые поды
kubectl get endpointslices -l kubernetes.io/service-name=<service>
kubectl get pods -l app=<app>

# Почему под не проходит readiness
kubectl describe pod <pod>
kubectl logs <pod> --previous

Частые причины: селектор Service не совпадает с метками подов, readinessProbe проверяет не тот порт или путь, приложение стартует дольше, чем initialDelaySeconds, поды падают в CrashLoopBackOff. Пример корректной пробы:

Kubernetes readinessProbe

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3

503 в 1С, IIS и при запросах к API

1С: код 503 в веб-клиенте и HTTP-сервисах

При работе с опубликованной базой 1С код 503 обычно возвращает веб-сервер (Apache или IIS) с модулем расширения 1С, когда тот не может получить сеанс у сервера 1С. Проверьте, запущена ли служба агента сервера 1С и рабочие процессы в консоли администрирования кластера, хватает ли лицензий и нет ли блокировки начала сеансов для информационной базы. На IIS дополнительно убедитесь, что пул приложений публикации запущен.

IIS: HTTP Error 503. The service is unavailable

IIS отдаёт такую страницу, когда пул приложений остановлен. Часто его останавливает защита Rapid-Fail Protection после нескольких падений процесса подряд. Посмотрите состояние и запустите пул в PowerShell (модуль WebAdministration), а причину падения ищите в журнале событий Windows «Приложение» и «Система»:

Import-Module WebAdministration
Get-WebAppPoolState -Name "DefaultAppPool"
Start-WebAppPool -Name "DefaultAppPool"

Код ошибки 503 при запросе к API

Если 503 возвращает чужое API, правильная реакция клиента — повторить запрос позже, а не сразу. Учитывайте Retry-After, если он есть, и увеличивайте паузу между попытками (экспоненциальная задержка). Повторять безопасно только идемпотентные запросы (GET, PUT, DELETE) или запросы с ключом идемпотентности. В curl это выглядит так:

curl --retry 5 --retry-max-time 120 -sS https://api.example.com/v1/status

curl считает 503 временной ошибкой и повторит запрос. Если своё API под нагрузкой отвечает 503 часто, это повод добавить мощности или очередь, а не увеличивать число ретраев у клиентов.

Плановое обслуживание: 503 и Retry-After без потерь в SEO

Правильный maintenance-режим:

• Верните 503 (не 200!)
• Укажите Retry-After в секундах
• Держите maintenance не более 24 часов
• Не меняйте robots.txt на Disallow: /
• Не редиректьте на статичную страницу с 200
• Отдавайте 503 и для robots.txt только если закрываете весь сайт: пока robots.txt отвечает 5xx, Google приостанавливает сканирование

Страница-заглушка с кодом 200 опасна тем, что поисковик может принять её за новое содержимое всех страниц. Код 503 честно говорит «страница есть, но сейчас недоступна». Если же 503 длится несколько дней подряд, поисковые системы начинают исключать страницы из индекса.

Если 503 появляется не по плану, а из-за наплыва ботов или атаки, первые шаги описаны в статье «DDoS-атака на сайт: что делать в первый час».

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

• Проверка HTTP-заголовков — разовая проверка: код ответа, Retry-After, заголовок Server и цепочка редиректов.
• Uptime Monitoring — постоянная проверка с ожидаемым кодом 200: при 503 придёт алерт в Email, Telegram или Slack, а в истории будет видно начало и конец сбоя.

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

503 — это инструмент, а не баг, когда используется правильно. Ключи: всегда возвращайте Retry-After, настройте PHP-FPM пул под реальную нагрузку, используйте 429 для rate limiting, проверяйте health check балансировщика и мониторьте сайт через Enterno.io.

Частые вопросы

Что означает 503 ошибка сервера?

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

503 во время деплоя — это нормально?

Да, если коротко (<30 сек) и с Retry-After. Для zero-downtime deploy используйте blue-green или rolling deployment.

Google деиндексирует сайт при 503?

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

Нужен ли Retry-After?

Стандарт его не требует, но ставить стоит. Без него клиенты и боты агрессивно ретраят, усугубляя нагрузку.

Почему nginx отдаёт 503, хотя сервер не перегружен?

Чаще всего сработал limit_req или limit_conn — ищите в error.log строки «limiting requests» — либо остался файл-флаг обслуживания с return 503.

Как автоматически узнать о 503?

Enterno.io Monitors с ожидаемым кодом 200 шлёт алерт через Email/Telegram/Slack при первой неудачной проверке.