HTTP 503 Service Unavailable: что делать посетителю и владельцу сайта

  • Обновлено
  • Чтение ≈ 3 минуты

Краткий ответ

503 означает временную недоступность: техобслуживание или перегрузка. Посетителю достаточно подождать; владельцу — проверить backend, ресурсы и логи.

В этой статье
  1. Что означает ошибка
  2. Причины и решения
  3. Пошаговое решение
  4. Для посетителя
  5. Для владельца: причины
  6. Исправление
  7. Как проверить результат

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

503
503 Service Unavailable

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

Для посетителя помогает повторить запрос позже; владельцу нужно искать причину.

Различайте 503 от самого веб-сервера и от балансировщика/CDN.

503 означает временную недоступность: техобслуживание или перегрузка. Посетителю достаточно подождать; владельцу — проверить backend, ресурсы и логи.

#Причины и решения

Возможная причинаКак узнатьЧто делать
ПерегрузкаРесурсы.503.Масштабируйте.
ТехобслуживаниеРежим.503.Дождитесь.
Упал backendСлужба.503.Запустите.
Лимит хостингаТариф.503.Обратитесь.

#Пошаговое решение

  1. Повторите запрос позжеЕсли браузер показывает 503 Service Unavailable, подождите некоторое время и один раз обновите страницу через Ctrl+R (macOS: Command+R). Если заголовок ответа содержит Retry-After, ориентируйтесь на указание сервера; если его нет, не отправляйте частые повторные запросы. При оформлении платежа или заказа сначала проверьте историю операции: повтор может создать дубликат. Если 503 сохраняется на других устройствах, сообщите владельцу сайта.
  2. Проверьте статус сервисаОткройте официальную страницу состояния соответствующего сервиса (если она есть) и проверьте сообщения о текущих сбоях. Сравните работу сервиса в приложении и браузере; при общей аварии дождитесь восстановления, не сбрасывая устройство.
  3. Владельцу: проверьте службыЭто действие только для владельца сервера. Подключитесь к Linux-серверу через SSH или откройте терминал панели хостинга; нужны права на просмотр служб. Сначала выясните, что обслуживает сайт (Nginx, Apache, PHP-FPM, приложение). Для Nginx выполните systemctl status nginx --no-pager, для установленного PHP-FPM — systemctl list-units --type=service "*fpm*", затем systemctl status ИМЯ_СЛУЖБЫ, заменив имя названием реально существующего подразделения. Состояние failed и ошибки в журнале указывают на сбой; active само по себе не исключает перегрузку. Ничего не перезапускайте, пока не изучены последние ошибки.
  4. Проверьте логи и нагрузкуАдминистратору: найдите в журнале доступа и ошибок веб-сервера запись, соответствующую точному времени и URL сбоя. На системах с systemd можно начать с sudo journalctl -u nginx --since "15 minutes ago" (если nginx работает как служба); для файловых логов используйте путь, указанный в конфигурации access_log/error_log. Ищите сообщения подключения к upstream, тайм-ауты и отказ приложения; не меняйте лимиты без подтверждённой причины. Посетителю достаточно записать код и время и обратиться к владельцу.
  5. Устраните подтверждённую причину перегрузкиТолько администратору сайта. После изучения ошибок проверьте free -h, df -h и загрузку процессов (top); выясните, не исчерпаны ли рабочие процессы PHP, память или диск. Если журнал прямо указывает на зависшую службу, согласуйте краткий перерыв и перезапустите только её командой sudo systemctl restart ИМЯ_СЛУЖБЫ с реальным именем из предыдущего шага. Повторите запрос к странице и сравните журнал до и после. Настраивать лимиты имеет смысл лишь после выяснения причины и создания резервной копии конфигурации; посетитель сайта должен сообщить об ошибке владельцу, а не перезагружать свой компьютер.

#Для посетителя

Подождите 5–10 минут и обновите страницу. Откройте сайт на другом устройстве и сети. Проверьте статус на downdetector.com. Если нужен сайт срочно, используйте кэш поисковой системы или архив web.archive.org. Не отправляйте повторно платежи и формы во время сбоя.

#Для владельца: причины

Исчерпан лимит процессов 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.

Linux · Терминал (Bash)Команда
Диагностика сервера при 503.
systemctl status nginx php8.2-fpm
free -m
tail -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, Zabbix) и оповещения. Поисковые системы воспринимают кратковременные 503 с заголовком Retry-After нормально, но длительная недоступность влияет на индексацию — не оставляйте сайт в таком состоянии более суток.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.