Ошибка 502 Bad Gateway: что это значит и как исправить Печать

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

Проще говоря, один сервер пытается получить данные от другого, но не получает нормального ответа.

Такая ситуация часто встречается на связке Nginx + PHP-FPM, Nginx + Apache, при использовании прокси-сервера или CDN, а также в различных веб-приложениях.

Например, посетитель открывает сайт, запрос попадает на Nginx, а Nginx должен передать его PHP-FPM. Если PHP-FPM не отвечает, работает с ошибкой или вообще недоступен, Nginx может вернуть пользователю 502 Bad Gateway.

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

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

502 Bad Gateway

или:

HTTP 502 Bad Gateway

При использовании Nginx часто отображается:

502 Bad Gateway
nginx

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

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

Что происходит при ошибке 502

Типичная схема может выглядеть так:

Пользователь
     ↓
Nginx
     ↓
PHP-FPM
     ↓
Приложение
     ↓
База данных

Если Nginx не может получить корректный ответ от PHP-FPM, возникает 502.

При другой конфигурации:

Пользователь
     ↓
Nginx
     ↓
Apache
     ↓
PHP

В этом случае проблема может находиться между Nginx и Apache.

При использовании Cloudflare схема будет выглядеть примерно так:

Пользователь
     ↓
Cloudflare
     ↓
Nginx / Apache
     ↓
PHP-FPM
     ↓
Приложение

Поэтому первым делом нужно определить, между какими компонентами возникает проблема.

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

Наиболее распространённые причины:

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

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

• PHP-FPM работает, но перегружен;

• Nginx не может подключиться к PHP-FPM;

• неправильный путь к Unix Socket PHP-FPM;

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

• Apache не отвечает;

• сервер перегружен;

• приложение слишком долго выполняет запрос;

• неправильная конфигурация Nginx;

• проблемы после изменения версии PHP;

• ошибка после обновления CMS;

• проблемы с прокси или CDN.

Начните с проверки PHP-FPM

Если сервер использует Nginx и PHP-FPM, сначала проверьте состояние PHP-FPM.

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

systemctl status php8.2-fpm

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

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

systemctl start php8.2-fpm

Чтобы PHP-FPM автоматически запускался после перезагрузки сервера:

systemctl enable php8.2-fpm

После запуска обновите страницу сайта.

Если сайт снова заработал, проблема была связана с PHP-FPM.

Перезапустите PHP-FPM

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

В таком случае можно выполнить:

systemctl restart php8.2-fpm

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

Если ошибка регулярно возвращается, простой перезапуск не решает проблему. Нужно выяснить, почему PHP-FPM перестаёт нормально обрабатывать запросы.

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

Для диагностики откройте журнал PHP-FPM.

Например:

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

Также PHP-FPM может записывать ошибки в отдельный файл:

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

Конкретный путь зависит от операционной системы и версии PHP.

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

server reached pm.max_children setting

pool seems busy

child exited on signal

failed to listen

Такие сообщения могут указывать на нехватку процессов, неправильную конфигурацию или проблемы с PHP-FPM.

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

Если PHP-FPM работает, следующим шагом необходимо проверить Nginx.

Обычно ошибки находятся в:

/var/log/nginx/error.log

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

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

При ошибке 502 можно увидеть сообщения вроде:

connect() to unix:/run/php/php8.2-fpm.sock failed

или:

connect() failed (111: Connection refused)

Это уже даёт полезную информацию.

Например:

connect() failed (111: Connection refused)

обычно означает, что Nginx не смог подключиться к backend-сервису.

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

Nginx и PHP-FPM могут взаимодействовать через Unix Socket.

Например:

/run/php/php8.2-fpm.sock

Проверьте, существует ли он:

ls -la /run/php/

Если Nginx пытается использовать:

/run/php/php8.2-fpm.sock

а такого файла нет, запросы к PHP не будут работать.

Проверьте настройки PHP-FPM:

grep -R "^listen" /etc/php/8.2/fpm/pool.d/

Результат может выглядеть так:

listen = /run/php/php8.2-fpm.sock

Теперь сравните этот путь с настройкой Nginx.

Проверьте конфигурацию Nginx

Неправильная конфигурация Nginx — ещё одна распространённая причина 502.

Проверить конфигурацию:

nginx -t

Если конфигурация корректная, вы увидите сообщение примерно такого вида:

syntax is ok
test is successful

Если есть ошибка, Nginx покажет файл и строку, в которой обнаружена проблема.

После изменения конфигурации не стоит сразу перезагружать сервер. Сначала выполните nginx -t.

Проверьте upstream

Если Nginx используется как reverse proxy, ошибка 502 может возникнуть из-за недоступности upstream-сервера.

Например:

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

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

127.0.0.1:8080

Проверьте, слушает ли какой-либо процесс этот порт:

ss -lntp | grep 8080

Если порт не используется, Nginx не сможет подключиться к приложению.

Проверьте Apache

Если используется связка:

Nginx → Apache → PHP

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

systemctl status apache2

На некоторых системах используется:

systemctl status httpd

Если Apache остановлен:

systemctl start apache2

или:

systemctl start httpd

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

Проверьте порты

Если Nginx работает как reverse proxy, приложение должно слушать тот порт, который указан в proxy_pass.

Проверить открытые локальные порты:

ss -lntp

Например:

LISTEN 0 128 127.0.0.1:8080

означает, что какой-то процесс слушает порт 8080 на localhost.

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

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

502 может быть следствием высокой нагрузки.

Проверьте:

top

или:

htop

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

• загрузку CPU;

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

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

• нагрузку на диск;

• процессы MySQL/MariaDB;

• количество одновременных соединений.

Если сервер полностью загружен, PHP-FPM или другой backend может перестать своевременно отвечать на запросы.

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

При нехватке RAM Linux может начать активно использовать swap или завершать процессы.

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

free -h

Пример:

               total        used        free
Mem:            8Gi         7.8Gi       100Mi
Swap:           2Gi         2Gi         0Mi

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

Можно использовать:

ps aux --sort=-%mem | head

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

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

В логах может появиться:

server reached pm.max_children setting

Проверьте настройки пула 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 до большого значения.

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

Проверьте зависшие PHP-процессы

Иногда отдельные PHP-скрипты выполняются слишком долго.

Посмотреть процессы можно:

ps aux | grep php

Если один или несколько процессов постоянно занимают CPU или память, проверьте, какой запрос или скрипт их запустил.

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

• тяжёлый PHP-скрипт;

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

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

• неисправный плагин;

• cron-задача;

• внешний API;

• медленный запрос к базе данных.

Проверьте базу данных

Иногда PHP не может нормально обработать запрос из-за проблем с MySQL или MariaDB.

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

systemctl status mariadb

или:

systemctl status mysql

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

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

mysqladmin processlist

Это позволяет увидеть активные запросы к MySQL.

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

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

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

df -h

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

df -i

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

Проверьте, не изменялась ли версия PHP

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

Например, сайт работал на PHP 8.1, после перехода на PHP 8.3 начал возвращать 502.

Сам PHP 8.3 не обязательно является причиной. Проблема может быть в:

• старом коде;

• расширении PHP;

• конфигурации PHP-FPM;

• несовместимом плагине.

Проверьте логи и, если необходимо, временно верните предыдущую поддерживаемую версию PHP.

Ошибка 502 после обновления WordPress

Если 502 появилась после обновления WordPress, темы или плагина, временно отключите недавно установленное расширение.

Если доступа к WordPress нет, это можно сделать через SSH или файловый менеджер.

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

mv wp-content/plugins wp-content/plugins_backup

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

Ошибка 502 при использовании Cloudflare

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

Схема:

Браузер
   ↓
Cloudflare
   ↓
Ваш сервер
   ↓
Nginx / Apache
   ↓
PHP-FPM / приложение

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

В этом случае проверьте:

1. доступен ли сервер;

2. работает ли Nginx или Apache;

3. работает ли PHP-FPM;

4. слушает ли сервер необходимые порты;

5. нет ли блокировки запросов firewall;

6. что показывают логи Nginx и PHP-FPM.

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

Проверьте firewall

Firewall может блокировать соединение между Nginx и backend-сервисом.

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

Проверить правила можно с помощью используемого firewall.

Для UFW:

sudo ufw status

Для firewalld:

sudo firewall-cmd --list-all

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

Если Nginx и PHP-FPM работают на одном сервере через Unix Socket, открытие порта для PHP-FPM обычно вообще не требуется.

Если 502 появляется только на одной странице

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

Например:

• импорт большого файла;

• генерация отчёта;

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

• загрузка большого изображения;

• запрос к внешнему API;

• тяжёлый SQL-запрос.

В таком случае обратите внимание на время выполнения запроса и настройки timeout.

Проверьте timeout

Для reverse proxy Nginx используются параметры вроде:

proxy_connect_timeout
proxy_read_timeout
proxy_send_timeout

Для FastCGI:

fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout

Если приложение выполняет операцию слишком долго, Nginx может прекратить ожидание ответа.

Но увеличивать timeout вслепую не стоит.

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

Сначала нужно найти причину медленной работы.

Если ошибка появляется периодически

Если 502 возникает не постоянно, а только время от времени, обратите внимание на:

• скачки нагрузки;

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

• доступную RAM;

• cron-задачи;

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

• автоматические обновления;

• резкий рост посещаемости;

• лимиты PHP-FPM;

• количество одновременных соединений.

В такой ситуации полезно сопоставить время появления ошибки с записями в логах.

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

Если сайт возвращает 502 Bad Gateway, последовательно проверьте:

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

2. Посмотрите логи PHP-FPM.

3. Посмотрите error.log Nginx.

4. Проверьте PHP-FPM socket или upstream.

5. Проверьте конфигурацию Nginx через nginx -t.

6. Если используется Apache — проверьте его состояние.

7. Проверьте нагрузку CPU и RAM.

8. Проверьте количество PHP-FPM процессов.

9. Проверьте MySQL/MariaDB.

10. Проверьте свободное место и inode.

11. Проверьте firewall.

12. Если используется Cloudflare — отдельно проверьте origin-сервер.

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

Полностью исключить появление 502 невозможно, но вероятность можно существенно снизить.

Рекомендуется:

• следить за нагрузкой VPS;

• контролировать работу PHP-FPM;

• правильно рассчитывать pm.max_children;

• регулярно обновлять CMS и плагины;

• следить за логами;

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

• не допускать постоянного дефицита RAM;

• правильно настраивать Nginx и Apache;

• не увеличивать timeout без необходимости;

• использовать мониторинг доступности сервисов.

Для VPS удобно использовать Zabbix, Uptime Kuma или другой инструмент мониторинга, чтобы видеть момент, когда backend перестаёт отвечать.