#Что означает ошибка
503 Service Unavailable
HTTP 503 Service Unavailable означает, что сервер временно не может обработать запрос: идёт обслуживание, перегрузка или упал бэкенд. Ошибка временная по определению, но может затягиваться.
Для посетителя помогает повторить запрос позже; владельцу нужно искать причину.
Различайте 503 от самого веб-сервера и от балансировщика/CDN.
503 означает временную недоступность: техобслуживание или перегрузка. Посетителю достаточно подождать; владельцу — проверить backend, ресурсы и логи.
#Причины и решения
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| ПерегрузкаРесурсы. | 503. | Масштабируйте. |
| ТехобслуживаниеРежим. | 503. | Дождитесь. |
| Упал backendСлужба. | 503. | Запустите. |
| Лимит хостингаТариф. | 503. | Обратитесь. |
#Пошаговое решение
- Повторите запрос позжеЕсли браузер показывает 503 Service Unavailable, подождите некоторое время и один раз обновите страницу через
Ctrl+R(macOS:Command+R). Если заголовок ответа содержитRetry-After, ориентируйтесь на указание сервера; если его нет, не отправляйте частые повторные запросы. При оформлении платежа или заказа сначала проверьте историю операции: повтор может создать дубликат. Если 503 сохраняется на других устройствах, сообщите владельцу сайта. - Проверьте статус сервисаОткройте официальную страницу состояния соответствующего сервиса (если она есть) и проверьте сообщения о текущих сбоях. Сравните работу сервиса в приложении и браузере; при общей аварии дождитесь восстановления, не сбрасывая устройство.
- Владельцу: проверьте службыЭто действие только для владельца сервера. Подключитесь к Linux-серверу через SSH или откройте терминал панели хостинга; нужны права на просмотр служб. Сначала выясните, что обслуживает сайт (Nginx, Apache, PHP-FPM, приложение). Для Nginx выполните
systemctl status nginx --no-pager, для установленного PHP-FPM —systemctl list-units --type=service "*fpm*", затемsystemctl status ИМЯ_СЛУЖБЫ, заменив имя названием реально существующего подразделения. Состояниеfailedи ошибки в журнале указывают на сбой;activeсамо по себе не исключает перегрузку. Ничего не перезапускайте, пока не изучены последние ошибки. - Проверьте логи и нагрузкуАдминистратору: найдите в журнале доступа и ошибок веб-сервера запись, соответствующую точному времени и URL сбоя. На системах с systemd можно начать с
sudo journalctl -u nginx --since "15 minutes ago"(если nginx работает как служба); для файловых логов используйте путь, указанный в конфигурацииaccess_log/error_log. Ищите сообщения подключения к upstream, тайм-ауты и отказ приложения; не меняйте лимиты без подтверждённой причины. Посетителю достаточно записать код и время и обратиться к владельцу. - Устраните подтверждённую причину перегрузкиТолько администратору сайта. После изучения ошибок проверьте
free -h,df -hи загрузку процессов (top); выясните, не исчерпаны ли рабочие процессы PHP, память или диск. Если журнал прямо указывает на зависшую службу, согласуйте краткий перерыв и перезапустите только её командойsudo systemctl restart ИМЯ_СЛУЖБЫс реальным именем из предыдущего шага. Повторите запрос к странице и сравните журнал до и после. Настраивать лимиты имеет смысл лишь после выяснения причины и создания резервной копии конфигурации; посетитель сайта должен сообщить об ошибке владельцу, а не перезагружать свой компьютер.
#Для посетителя
Подождите 5–10 минут и обновите страницу. Откройте сайт на другом устройстве и сети. Проверьте статус на . Если нужен сайт срочно, используйте кэш поисковой системы или архив . Не отправляйте повторно платежи и формы во время сбоя.
#Для владельца: причины
Исчерпан лимит процессов PHP-FPM/Apache (pm.max_children), заполнена память, упал backend (Node, Gunicorn), включён режим обслуживания CMS (файл .maintenance в WordPress), достигнут лимит хостинга. Проверьте systemctl status php8.2-fpm nginx, free -m, top, и логи /var/log/nginx/error.log.
#Исправление
Перезапустите службы: sudo systemctl restart php8.2-fpm nginx. Увеличьте pm.max_children в www.conf с учётом памяти. Удалите .maintenance в корне WordPress. Для CDN убедитесь, что исходный сервер отвечает. Добавьте кэширование и ограничьте боты через fail2ban или правила WAF. Настройте корректную страницу 503 с Retry-After.
systemctl status nginx php8.2-fpmfree -mtail -n 50 /var/log/nginx/error.log#Как проверить результат
После исправления проверьте код ответа: curl -I https://example.com должен вернуть HTTP/2 200. Понаблюдайте за нагрузкой минимум час: htop и journalctl -u php8.2-fpm -n 100 покажут повторные падения. Если 503 возникает пиками, добавьте мониторинг (UptimeRobot, ) и оповещения. Поисковые системы воспринимают кратковременные 503 с заголовком Retry-After нормально, но длительная недоступность влияет на индексацию — не оставляйте сайт в таком состоянии более суток.