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

Что такое HTTP-ошибка 503?

503 Service Unavailable означает, что сервер или что-то перед ним сейчас не может обработать ваш запрос: он перегружен, на обслуживании, ограничивает частоту запросов или у него нет исправного бэкенда, куда можно его передать. RFC 9110 определяет это как временное состояние, которое, скорее всего, пройдёт через какое-то время.

Сервер может добавить заголовок Retry-After с указанием, сколько ждать. В отличие от 500, который означает, что что-то сломалось, 503 говорит «не сейчас», поэтому сайты используют его для плановых работ.

Часто отвечает вовсе не ваш веб-сервер, а уровень перед ним: балансировщик нагрузки вроде HAProxy, кэш вроде Varnish, CDN вроде Cloudflare или Kubernetes Ingress. Точный текст сообщения подскажет, какой именно (см. ниже).

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

Сообщение подсказывает, какой уровень ответил. Вот самые частые, с указанием ПО, которое их выводит:

Как бы ни был сформулирован текст, смысл один: этот запрос сейчас не может быть обработан, и смотреть нужно на уровень, указанный в таблице.

Распространённые причины HTTP-ошибки 503

Обычные причины, по которым сервер или уровень перед ним возвращает 503:

• Перегрузка — достигнуты лимиты CPU, памяти или соединений при всплеске трафика, вирусной публикации или агрессивном краулере
• Плановое обслуживание — сайт намеренно отключён на время обновления или миграции; при правильной настройке с заголовком Retry-After
• Нет исправного бэкенда — у балансировщика нагрузки, прокси или Ingress нет работающего сервера, куда можно отправить запрос (приложение упало, проверки работоспособности не проходят, нет готовых подов)
• Лимиты частоты запросов или соединений — limit_req и limit_conn в nginx по умолчанию отвечают 503, поэтому его может вызвать активный клиент или краулер
• Упавшее или остановленное приложение — PHP-FPM, Node.js или Python не работают за запущенным веб-сервером; в IIS — остановленный пул приложений
• Лимиты ресурсов хостинга — виртуальный хостинг ограничивает CPU, память и число процессов на аккаунт
• Плагин, тема или обновление — в WordPress и других CMS неудачное обновление может обрушить приложение или оставить сайт в режиме обслуживания
• Атака — DDoS или поток ботов исчерпывает те же ресурсы, что и всплеск трафика

Решение для посетителей: что вы можете сделать

Если вы заходите на чужой сайт, проблема на его стороне. Что можно сделать:

• Подождать и повторить — 503 задуман как временный; подождите минуту и обновите страницу один раз. Если страница показывает время Retry-After или сообщение об обслуживании, подождите столько
• Проверить, не работает ли сайт у всех — проверка доступности сайта от DNS Robot открывает сайт из-за пределов вашей сети
• Посмотреть страницу статуса или соцсети сайта — плановые работы и сбои обычно анонсируют
• Попробовать другую сеть — если сайт открывается через мобильный интернет, то либо VPN или прокси в вашей обычной сети отвечает этим 503, либо сайт ограничивает частоту запросов с вашего IP-адреса

Способ 1: выясните, какой уровень отправил 503

Прежде чем что-либо перезапускать, посмотрите на сообщение и заголовки ответа: они подскажут, какой уровень ответил. Проверьте снаружи с помощью проверки HTTP-заголовков от DNS Robot или curl -sI и обратите внимание на заголовок server и текст страницы (см. таблицу выше).

Затем перезапустите тот уровень, который отказывает, а не только веб-сервер:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Если 503 возвращается через несколько минут после перезапуска, причина никуда не делась: переходите к ресурсам и логам.

Способ 2: проверьте ресурсы сервера (CPU, RAM, диск)

Если сервер перегружен, перезапуск даёт лишь временное облегчение. Проверьте, что потребляет ресурсы.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Если CPU или RAM загружены на 90%+, вам нужно оптимизировать приложение, завершить неуправляемые процессы или обновить сервер. Если диск заполнен, очистите лог-файлы, старые бэкапы или временные файлы.

Способ 3: проверьте логи ошибок

Логи точно скажут, почему возник 503. Прочитайте последние строки командами ниже и поищите в них следующее:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

«limiting requests» или «limiting connections» (nginx) — limit_req или limit_conn отклонил запрос; он отвечает 503, пока вы не зададите limit_req_status или limit_conn_status.

«max_children» (PHP-FPM, например «server reached pm.max_children setting») — заняты все PHP-воркеры: Apache отвечает 503, а nginx — 502 или 504.

«AH01114» / «failed to make connection to backend» (Apache mod_proxy) — Apache не смог связаться с бэкендом и ответил 503.

«Too many connections» (MySQL) — исчерпан лимит соединений с базой данных.

«no live upstreams» и «upstream timed out» в nginx относятся к 502 Bad Gateway и 504 Gateway Timeout, а не к 503.

Способ 4: отключите плагины и темы (WordPress / CMS)

В WordPress и других CMS тяжёлый плагин может исчерпать PHP-воркеры или лимиты ресурсов хостинга, что даёт 503 (плагин, который падает, даёт 500). Если 503 начался после обновления или установки плагина, начните с него.

Если у вас нет доступа к панели администратора WordPress, отключите плагины через файловую систему или базу данных.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

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

Застряли на «Briefly unavailable for scheduled maintenance»? WordPress создаёт файл .maintenance в корне сайта на время обновлений и игнорирует его, когда ему больше 10 минут. Удалите его, чтобы вернуться раньше; если сообщение остаётся, поищите файл wp-content/maintenance.php или кэшированную копию страницы.

Способ 5: увеличьте лимиты PHP и сервера

Если на сервере закончились PHP-воркеры или достигнут лимит памяти, необходимо увеличить значения в конфигурации.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

После этого перезапустите PHP-FPM (sudo systemctl restart php8.2-fpm, с вашей версией), чтобы новые лимиты применились.

Способ 6: проверьте CDN или балансировщик нагрузки

Если вы используете Cloudflare, другую CDN или балансировщик нагрузки, 503 может исходить от них, а не от вашего сервера.

Правило Cloudflare (их руководство по ошибке 503):

• На странице есть «cloudflare» или «cloudflare-nginx» — её сгенерировала Cloudflare: проверьте, не превысил ли Worker лимиты CPU или памяти, затем обратитесь в поддержку Cloudflare с выводом /cdn-cgi/trace
• Нет признаков Cloudflare — 503 вернул ваш origin-сервер, а Cloudflare передала его дальше: проверьте логи origin и спросите хостинг, не ограничивает ли он частоту запросов с IP-адресов Cloudflare

Для HAProxy, облачного балансировщика нагрузки или Kubernetes Ingress проверьте бэкенды: 503 там обычно означает, что ни один бэкенд не смог принять запрос (для AWS Application Load Balancer — что в целевой группе нет зарегистрированных целей). Проверка DNS от DNS Robot подтвердит, что ваш домен по-прежнему указывает туда, куда вы ожидаете.

Способ 7: проверьте наличие DDoS или бот-атак

Внезапный всплеск трафика от ботов или DDoS-атака может перегрузить сервер. Проверьте логи доступа на наличие подозрительных паттернов.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Если один адрес или небольшой диапазон шлёт тысячи запросов, заблокируйте его на файрволе. За Cloudflare или другой CDN сначала сделайте так, чтобы в логах был виден настоящий IP посетителя (set_real_ip_from плюс real_ip_header CF-Connecting-IP в nginx), иначе вы заблокируете CDN вместо атакующего. При крупной атаке режим «I'm Under Attack» в Cloudflare или DDoS-защита вашего хостинга отфильтруют трафик, прежде чем он до вас дойдёт.

Способ 8: устраните проблемы с подключением к базе данных

Когда у базы данных заканчиваются соединения или она останавливается, приложение перед ней может отказать. Одни приложения отвечают 503; WordPress вместо этого показывает «Error establishing a database connection». Проверьте базу данных напрямую:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Если вы видите много соединений в статусе sleeping, ваше приложение не закрывает соединения с базой данных корректно. Если долгие запросы блокируют другие, оптимизируйте эти запросы или завершите их, чтобы разблокировать базу данных.

Способ 9: свяжитесь с хостинг-провайдером

Если вы используете виртуальный хостинг, управляемый WordPress-хостинг или платформу вроде Squarespace, Wix или Shopify, у вас может не быть доступа к серверным логам или возможности перезапускать сервисы. В таких случаях ошибка 503 может быть вызвана инфраструктурой хостинг-провайдера.

Обратитесь в службу поддержки хостинг-провайдера и предоставьте:

• Точный URL, возвращающий 503
• Когда появилась ошибка — укажите дату и время
• Что изменилось — устанавливали ли вы плагин, обновляли тему или меняли настройки DNS?
• Ошибка периодическая или постоянная — периодические 503 указывают на нехватку ресурсов; постоянные 503 — на сбой или неправильную конфигурацию

503 в сравнении с другими HTTP-ошибками

Ошибку 503 часто путают с другими серверными ошибками. Вот чем они отличаются.

Главное различие: 503 задуман как временный, а заголовок Retry-After может указать, на какой срок. При сканировании Google относится к ошибкам 5xx и 429 одинаково: его краулеры замедляются, а проиндексированные URL некоторое время сохраняются, но со временем исключаются, если ошибки продолжаются (Google Search Central).

Об ошибках на стороне прокси читайте в 502 Bad Gateway и 504 Gateway Timeout; об ограничениях частоты — в 429 Too Many Requests.

Как предотвратить ошибки 503

Профилактика лучше, чем тушение пожаров. Вот лучшие практики для предотвращения ошибок 503.

• Мониторьте ресурсы сервера — Настройте оповещения при CPU > 80%, RAM > 85% и диск > 90%. Инструменты вроде UptimeRobot, Pingdom или Grafana обеспечивают мгновенные уведомления.
• Используйте CDN — Cloudflare, Fastly или AWS CloudFront кэшируют статические ресурсы и поглощают всплески трафика, снижая нагрузку на origin-сервер.
• Включите кэширование — Используйте Redis, Memcached или Varnish для кэширования запросов к базе данных и отрендеренных страниц. Пользователям WordPress: установите плагин кэширования, например WP Super Cache или W3 Total Cache.
• Автоматическое масштабирование — Если вы используете облачный хостинг (AWS, GCP, Azure, DigitalOcean), настройте автомасштабирование для добавления серверов при всплесках трафика.
• Ограничивайте ботов — Настройте Nginx или Cloudflare для rate-limiting агрессивных краулеров и парсеров, прежде чем они перегрузят сервер.
• Оптимизируйте запросы к базе данных — медленные запросы надолго занимают соединения и воркеры. Добавляйте индексы, оптимизируйте join-запросы и кэшируйте результаты в Redis или Memcached.
• Используйте правильную страницу обслуживания — При деплое возвращайте 503 с заголовком Retry-After вместо того, чтобы позволять серверу упасть. Это сохраняет SEO и информирует пользователей.
• Обновляйте ПО — Обновляйте CMS, плагины, PHP и базу данных до последних стабильных версий, чтобы избежать известных багов и проблем безопасности.