#Описание и признаки неисправности
В панели управления Nginx, Apache или PHP-FPM имеет состояние «Работает», но посетители получают HTTP 503 Service Unavailable. Статус процесса означает лишь, что служба запущена, а не что нужный сайт и его обработчик могут обслужить запрос. Чтобы исправить проблему, определите источник кода 503, проверьте конкретный виртуальный хост, пул PHP и ограничения нагрузки. Не увеличивайте лимиты процессов и не перезапускайте все службы до анализа журнала.
#Как отличить возможные причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Приложение само отдаёт 503CMS включила режим обслуживания, приложение перегружено или недоступна база. | В access log код 503 от приложения, в PHP-журнале сообщения о maintenance/exceptions. | Разобрать прикладной журнал и устранить условие обслуживания. |
| Пул жив, но очередь переполненаВсе рабочие процессы заняты, запросы не принимаются или ограничены. | Ошибки max_children, backlog, upstream timed out, пики времени ответа. | Оценить длительность запросов, память и размер пула. |
| 503 создаёт CDN или ограничительПромежуточный узел отказывает раньше исходного сервера. | Ответ прямого IP и публичного домена различается; другой заголовок Server/страница ошибки. | Проверить CDN/WAF/лимит запросов и точку генерации кода. |
#Пошаговая диагностика и решение
- Зафиксируйте конкретный ответ, время и адресВ браузере откройте точный URL сайта по HTTPS и зафиксируйте, когда появляется 503. С рабочего компьютера выполните `curl -sS -o /dev/null -w "%{http_code} " https://example.org/` (подставьте свой домен): в ответе должно быть трёхзначное число. Проверьте главную и один несложный статический файл: если статика 200, а PHP 503, сосредоточьтесь на обработчике приложения.
- Отличите CDN от исходного сервераПроверьте заголовки
curl -I https://example.org/и название страницы ошибки: CDN иногда имеет собственную страницу 503. Если известен действительный IP сервера, временно проверьтеcurl -I --resolve example.org:443:IP https://example.org/с подстановкой настоящих значений, без флага-k. Если прямой IP отвечает 200, а CDN 503, изучите ограничения и журналы CDN. Если оба 503, переходите к серверным журналам. - Посмотрите журналы в момент 503Откройте в панели журналы ошибок и доступа для конкретного сайта. По SSH администратор может выполнить
sudo journalctl -u nginx --since "15 minutes ago"иsudo journalctl -u apache2 --since "15 minutes ago"для установленных служб; системные журналы не заменяют собственные access/error журналы сайтов. Запишите точные строки по времени сбоя, а не весь журнал с адресами посетителей. Ошибкаupstream timed outможет приводить к 504, а не 503, поэтому важен реальный статус и конфигурация. - Проверьте конкретную PHP-службу, не только NginxВ панели откройте карточку сайта и посмотрите выбранный режим PHP и версию. Если используется PHP-FPM, уточните соответствующий пул и службу версии, а не любой запущенный FPM. По SSH
systemctl list-units --type=service --state=runningпокажет работающие службы; далее смотрите статус именно нужного юнита. При FastCGI/Apache схема отличается: не используйте инструкции для сокета PHP-FPM, которого здесь нет. - Ищите ресурсный предел, а не только статус «Работает»Сравните нагрузку и память за последние минуты через панель ресурсов,
free -h,df -h, сообщения о нехватке памяти в журнале ядра. Если пул достигpm.max_children, выясните количество занятых процессов и медленные запросы по настройкам пула. Не повышайте лимиты без расчёта доступной ОЗУ: переход от 503 к падению сервера из-за OOM — не исправление. - Исключите обслуживание приложения и лимиты доступаВ административном разделе CMS проверьте, не включён ли режим обслуживания и не остался ли после обновления временный файл блокировки; порядок зависит от конкретной CMS. Посмотрите коды и сообщения приложения, расписание технических работ и журналы WAF/ограничения запросов. Если 503 возникает только у одного IP или одного пути, причина может быть в политике ограничения, а не в работоспособности PHP.
- Проверяйте конфигурацию до её примененияЕсли обнаружено неверное направление запросов к обработчику, исправьте адрес сервера/сокета через настройки сайта в панели, предварительно сохранив старое значение. Для Nginx проверьте
sudo nginx -t, при связке с Apache —sudo apachectl configtest. После успешного теста примените изменения штатно. Если команда сообщает ошибку, откатите конфигурацию в панели вместо попытки многократного перезапуска служб. - Повторите измерения и оформите откатПосле исправления повторите запросы со стороны посетителя и напрямую к серверу, проверьте статическую и динамическую страницу, откройте журнал ещё раз. Если 503 исчез, но память быстро заканчивается или пулы снова переполняются, продолжите анализ длительных запросов и ограничений, а не объявляйте проблему решённой. Если после изменения конфигурации появились 502/500, верните сохранённые параметры и сообщите ответственному администратору.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Проверка результата и дальнейшие действия
Успех — одинаковый ожидаемый ответ для публичного домена и проверенного источника, статика и PHP-страницы работают, 503 не повторяется в наблюдаемое окно, ошибки в журналах прекратились. Если код создаёт CDN, передайте его поддержке настройки маршрутизации и записи времени; если источник — администратору журнал нужного пула и снимки ресурсов без конфиденциальной информации.