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

Ошибка 503 Service Unavailable означает, что сервер временно не может обработать запрос пользователя.

В отличие от ошибки 404, которая обычно говорит об отсутствии запрашиваемой страницы, код 503 чаще указывает на проблему с сервером или приложением, которое должно обработать запрос.

Такая ошибка нередко бывает временной. Она может появиться из-за высокой нагрузки, остановки PHP-FPM или другого сервиса, технических работ, проблем с базой данных или превышения установленных лимитов.

Ошибка 503 может затрагивать весь сайт или только отдельные страницы и запросы.

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

В зависимости от используемого веб-сервера сообщение может выглядеть по-разному:

503 Service Unavailable

или:

HTTP 503 Service Unavailable

Также можно встретить сообщение:

Service Temporarily Unavailable

Если сайт работает через Cloudflare или другой прокси-сервис, посетитель может увидеть другую страницу ошибки.

Главное в данном случае — HTTP-код 503. Он означает, что сервер в данный момент не может обработать запрос.

Основные причины ошибки 503

У ошибки 503 нет одной конкретной причины.

На практике наиболее часто встречаются:

• высокая загрузка CPU или оперативной памяти;

• слишком большое количество одновременных подключений;

• PHP-FPM достиг лимита процессов;

• PHP-FPM остановлен или не отвечает;

• Nginx или Apache не может подключиться к backend;

• веб-приложение перегружено;

• MySQL или MariaDB недоступна;

• на сервере выполняются технические работы;

• сайт переведен в режим обслуживания;

• недостаточно ресурсов VPS;

• reverse proxy или балансировщик не может подключиться к backend;

• firewall блокирует соединение между сервисами.

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

Проверьте нагрузку на сервер

Если сайт внезапно начал возвращать 503, сначала стоит проверить текущую нагрузку.

Выполните:

top

или, если установлен htop:

htop

Обратите внимание на:

• загрузку процессора;

• использование оперативной памяти;

• использование swap;

• количество работающих процессов;

• процессы PHP-FPM;

• MySQL или MariaDB.

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

Проверьте оперативную память

Выполните:

free -h

Например:

               total        used        free
Mem:            8Gi         7.5Gi       200Mi
Swap:           2Gi         1.8Gi       200Mi

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

Чтобы определить процессы, которые потребляют больше всего памяти:

ps aux --sort=-%mem | head

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

Проверьте PHP-FPM

Для сайтов на PHP PHP-FPM — один из первых сервисов, который необходимо проверить.

Например, для PHP 8.2:

systemctl status php8.2-fpm

Если используется другая версия PHP, замените 8.2 на установленную версию.

Если PHP-FPM остановлен, запустите его:

systemctl start php8.2-fpm

При необходимости сервис можно перезапустить:

systemctl restart php8.2-fpm

После этого снова откройте сайт.

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

Проверьте логи PHP-FPM

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

Для просмотра последних сообщений PHP-FPM:

journalctl -u php8.2-fpm -n 100 --no-pager

В зависимости от операционной системы и конфигурации PHP-FPM также может использовать отдельный файл журнала:

/var/log/php8.2-fpm.log

Обратите внимание на сообщения вроде:

server reached pm.max_children setting

Оно означает, что все доступные процессы PHP-FPM уже заняты.

Также в журнале могут встречаться сообщения о:

• завершении дочерних процессов;

• нехватке памяти;

• ошибках конфигурации;

• падении PHP-процессов;

• проблемах с подключением.

Проверьте лимит PHP-FPM

Одна из распространенных причин периодических ошибок 503 на нагруженных PHP-сайтах — достижение значения pm.max_children.

Настройки пула PHP-FPM обычно находятся в:

/etc/php/8.2/fpm/pool.d/www.conf

Найдите параметры:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

Например:

pm.max_children = 20

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

Увеличение pm.max_children иногда действительно помогает, но делать это без расчета не стоит.

Каждый PHP-процесс использует оперативную память. Если на VPS всего 4 ГБ RAM, слишком большое значение может привести к полному исчерпанию памяти и сделать ситуацию еще хуже.

Проверьте Nginx

Если в качестве веб-сервера используется Nginx, проверьте его состояние:

systemctl status nginx

Также обязательно проверьте конфигурацию:

nginx -t

При корректной конфигурации будет выведено примерно:

syntax is ok
test is successful

Если Nginx остановлен, запустите его:

systemctl start nginx

Если сервис работает, но сайт продолжает возвращать 503, переходите к проверке журнала ошибок.

Проверьте лог Nginx

Стандартный журнал ошибок Nginx обычно находится здесь:

/var/log/nginx/error.log

Посмотреть последние записи:

tail -n 100 /var/log/nginx/error.log

Для просмотра новых сообщений в реальном времени:

tail -f /var/log/nginx/error.log

Особое внимание стоит обратить на сообщения, связанные с:

• upstream;

• connection refused;

• timeout;

• PHP-FPM;

• Unix Socket;

• недоступным backend.

Лог часто позволяет сразу понять, почему Nginx не может передать запрос приложению.

Проверьте Apache

Если сервер работает по схеме:

Nginx → Apache → PHP

проверьте состояние Apache:

systemctl status apache2

На некоторых системах сервис называется httpd:

systemctl status httpd

Также проверьте журнал ошибок Apache.

На Debian и Ubuntu он обычно находится здесь:

/var/log/apache2/error.log

На системах с каталогом /var/log/httpd:

/var/log/httpd/error_log

Если Apache остановлен, запустите его:

systemctl start apache2

или:

systemctl start httpd

После этого проверьте работу сайта.

Проверьте, слушает ли backend нужный порт

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

Посмотреть открытые локальные порты:

ss -lntp

Например, если приложение должно работать на порту 8080:

ss -lntp | grep 8080

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

В таком случае проблема, скорее всего, находится в самом приложении.

Проверьте настройки reverse proxy

Пример конфигурации Nginx:

location / {
    proxy_pass http://127.0.0.1:8080;
}

В данном случае Nginx ожидает приложение по адресу:

127.0.0.1:8080

Если приложение остановилось или начало использовать другой порт, Nginx не сможет передать ему запрос.

Проверьте одновременно:

• настройки приложения;

• параметр proxy_pass в Nginx;

• порт, который реально слушает приложение.

Проверьте режим обслуживания

Ошибка 503 не всегда означает неисправность. Некоторые CMS и приложения специально возвращают этот код во время технических работ или обновления.

Например, WordPress во время обновления может создавать файл:

.maintenance

Если обновление было прервано, сайт иногда остается в режиме обслуживания.

Проверьте корневой каталог WordPress:

ls -la

Если там есть:

.maintenance

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

rm .maintenance

Не удаляйте его, если обновление еще действительно выполняется.

Проверьте плагины WordPress

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

Если войти в административную панель невозможно, временно переименуйте каталог плагинов:

mv wp-content/plugins wp-content/plugins_backup

После этого проверьте сайт.

Если он снова начал работать, проблема, скорее всего, связана с одним из плагинов.

После проверки верните каталог:

mv wp-content/plugins_backup wp-content/plugins

Затем включайте плагины по одному, чтобы определить проблемный.

Проверьте MySQL или MariaDB

PHP-приложение может возвращать 503, если не может нормально подключиться к базе данных.

Для MySQL:

systemctl status mysql

Для MariaDB:

systemctl status mariadb

Если база данных остановлена, запустите сервис:

systemctl start mariadb

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

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

Проверьте долгие запросы MySQL

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

mysqladmin processlist

Обратите внимание на запросы, которые выполняются необычно долго.

Причиной могут быть:

• неоптимизированные SQL-запросы;

• отсутствие необходимых индексов;

• импорт большого объема данных;

• резервное копирование;

• высокая посещаемость;

• плагин или приложение, создающее слишком много запросов.

В такой ситуации увеличение лимитов PHP или Nginx само по себе проблему не решит. Нужно разобраться с нагрузкой на базу данных.

Проверьте свободное место на диске

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

Проверьте свободное место:

df -h

Также проверьте inode:

df -i

Если файловая система полностью заполнена, сервисы могут не иметь возможности создавать временные файлы, логи, socket-файлы и другие необходимые данные.

Чтобы найти большие каталоги:

du -xh /var | sort -h | tail -n 20

Будьте осторожны при удалении файлов. Не удаляйте системные файлы и активные журналы, если не уверены, для чего они используются.

Проверьте использование swap

Если оперативная память заканчивается, Linux начинает активнее использовать swap.

Проверить состояние памяти:

free -h

Интенсивное использование swap может значительно замедлить работу VPS.

Swap полезен как дополнительный механизм защиты от нехватки памяти, но он не заменяет физическую RAM.

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

Проверьте системные лимиты

Иногда причиной 503 становятся не CPU и RAM, а системные ограничения.

Например, количество открытых файлов:

ulimit -n

Для конкретного сервиса можно посмотреть системный лимит:

systemctl show nginx | grep LimitNOFILE

На серверах с большим количеством соединений может потребоваться изменение лимитов файловых дескрипторов или подключений.

Не увеличивайте системные лимиты просто наугад. Сначала нужно понять, какое именно ограничение достигнуто.

Проверьте firewall

Если приложение подключается к другому серверу, firewall может блокировать необходимое соединение.

Для UFW:

sudo ufw status

Для firewalld:

sudo firewall-cmd --list-all

Проверьте, разрешены ли необходимые соединения.

При этом не следует открывать во внешний интернет внутренние порты без необходимости.

Проверьте Cloudflare

Если сайт работает через Cloudflare, необходимо определить, где именно возникает проблема.

Типичная схема:

Браузер
   ↓
Cloudflare
   ↓
Origin-сервер
   ↓
Nginx / Apache
   ↓
PHP-FPM / приложение
   ↓
База данных

По возможности проверьте origin-сервер напрямую.

Если сам origin возвращает 503, проблема находится на сервере или стороне приложения.

Если origin работает нормально, а Cloudflare показывает ошибку, проверьте настройки Cloudflare, proxy, firewall и последние изменения конфигурации.

Проверьте логи в момент возникновения ошибки

Если 503 появляется только время от времени, запишите точное время возникновения ошибки.

После этого посмотрите журналы за соответствующий период:

journalctl --since "10 minutes ago"

Проверьте Nginx:

tail -n 200 /var/log/nginx/error.log

И PHP-FPM:

journalctl -u php8.2-fpm --since "10 minutes ago"

Такой подход значительно эффективнее, чем просмотр огромного количества старых записей без привязки ко времени.

Если 503 появляется при резком росте трафика

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

Проверьте:

• загрузку CPU;

• использование RAM;

• количество PHP-FPM процессов;

• количество подключений к базе данных;

• количество соединений Nginx;

• ограничения самого приложения.

Для нагруженного сайта могут потребоваться:

• кеширование;

• CDN;

• reverse proxy;

• оптимизация базы данных;

• увеличение RAM или CPU;

• балансировщик нагрузки;

• несколько серверов приложений.

Важно сначала определить, какой именно ресурс достигает своего лимита.

Если 503 появился после перезагрузки VPS

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

Для этого можно выполнить:

systemctl --failed

Команда покажет сервисы, которые не смогли нормально запуститься.

Также отдельно проверьте:

systemctl status nginx
systemctl status php8.2-fpm
systemctl status mariadb

Если один из сервисов не работает, сначала изучите его логи, а уже затем перезапускайте.

Проверьте также, включен ли автоматический запуск сервиса:

systemctl is-enabled nginx

Если 503 появился после обновления PHP

Изменение версии PHP может привести к проблемам совместимости или изменить настройки PHP-FPM.

Проверьте установленную версию:

php -v

Затем убедитесь, что работает правильная версия PHP-FPM:

systemctl status php8.2-fpm

Дополнительно проверьте конфигурацию Nginx:

nginx -t

и журнал PHP-FPM.

Если сайт нормально работал на предыдущей версии PHP, временный возврат на поддерживаемую версию поможет определить, связано ли появление ошибки с обновлением.

Быстрый алгоритм диагностики

Если сайт возвращает 503 Service Unavailable, проверьте:

1. Загрузку CPU и RAM.

2. Работает ли PHP-FPM.

3. Логи PHP-FPM.

4. Состояние Nginx или Apache.

5. Логи веб-сервера.

6. Слушает ли backend нужный порт или Unix Socket.

7. Лимиты PHP-FPM.

8. Состояние MySQL или MariaDB.

9. Свободное место и inode.

10. Не включен ли режим обслуживания.

11. Плагины WordPress или другие расширения приложения.

12. Правила firewall.

13. Origin-сервер, если используется Cloudflare.

14. Системные журналы в момент появления ошибки.

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

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

Однако правильная настройка и мониторинг сервера позволяют существенно снизить вероятность таких проблем.

Рекомендуется контролировать:

• загрузку CPU;

• использование RAM;

• swap;

• свободное место на диске;

• количество PHP-FPM процессов;

• состояние базы данных;

• количество соединений веб-сервера;

• логи приложений и системных сервисов.

Для VPS можно использовать Zabbix, Uptime Kuma или другие системы мониторинга. Они позволяют получать уведомления, когда сервис перестает отвечать или сервер начинает испытывать нехватку ресурсов.

Также не забывайте о регулярных резервных копиях. Если после обновления или изменения конфигурации сервис перестал работать, актуальный backup значительно упростит восстановление.