#Что означает ошибка
502 Bad Gateway nginx
Nginx сам страницы не генерирует: он передаёт запрос приложению (PHP-FPM, Node.js, Gunicorn и т. п.) и возвращает его ответ. Если приложение не отвечает или отвечает «мусором», Nginx возвращает 502. Если приложение отвечает слишком долго — это уже 504 Gateway Time-out, причины там другие.
#Пошаговое решение для новичка
- Найдите источник ошибки 502Откройте проблемную страницу и запишите время, URL и код 502. На сервере по SSH просмотрите
sudo tail -n 100 /var/log/nginx/error.logлибо путь журнала конкретного домена; ищитеconnect() failed,upstream prematurely closed connectionи имя upstream. Начинайте с этой записи, а не с перезапуска служб. - Проверьте приложение и его слушательПо конфигурации сайта найдите
fastcgi_passлибоproxy_pass, затем проверьте, существует ли указанный Unix-сокет или слушается TCP-порт черезss -lxnp/ss -ltnp. Выясните реальную версию PHP-FPM или название другого приложения и посмотрите журнал именно этой службы; не используйте наугадphp8.3-fpm. - Устраните конкретную причинуЕсли служба действительно остановлена, сначала изучите её журнал и конфигурацию, затем запустите лишь нужную службу в согласованное окно. При ошибке сокета сравните пути и права, при падении процесса — память и расширения; при нехватке воркеров — slowlog и очередь. Не ставьте права 777 и не увеличивайте лимиты без расчёта.
- Проверьте исправление и откатПосле изменения Nginx выполните
sudo nginx -tи только при успешной проверкеsudo systemctl reload nginx. Повторите исходный запрос, проверьте журналы Nginx и приложения и убедитесь, что код 502 не возвращается. Если изменения ухудшили работу, восстановите резервную копию конфигурации и сообщите точную ошибку администратору.
#Шаг 1. Откройте журнал ошибок
Не гадайте — прочитайте последние строки журнала. Путь по умолчанию на Debian/Ubuntu:
error_log.sudo tail -n 50 /var/log/nginx/error.logНайдите строку со словом upstream и сверьтесь с таблицей:
| Сообщение в журнале | Что значит | Что делать |
|---|---|---|
connect() failed (111: Connection refused) | На указанном порту никто не слушает: backend остановлен или слушает другой адрес. | Проверьте и запустите службу, сверьте порт в proxy_pass/fastcgi_pass. |
connect() to unix:/…sock failed (2: No such file or directory) | Сокета не существует: PHP-FPM не запущен или путь в конфиге неверный. | Запустите PHP-FPM, сверьте путь с listen в пуле. |
connect() to unix:/…sock failed (13: Permission denied) | У пользователя Nginx нет прав на сокет. | Согласуйте listen.owner/listen.group/listen.mode пула с пользователем Nginx. |
upstream prematurely closed connection while reading response header | Backend оборвал соединение: фатальная ошибка или перезапуск процесса. | Смотрите журнал PHP-FPM и приложения. |
recv() failed (104: Connection reset by peer) | Backend сбросил соединение: нехватка памяти, падение воркера. | Проверьте память, лимиты и журнал backend. |
#Шаг 2. Проверьте, что backend запущен
php8.2-fpm, php-fpm). Вторая команда показывает unix-сокеты, на которых слушает PHP-FPM.sudo systemctl status php8.3-fpmsudo ss -lxnp | grep phpЕсли служба остановлена, запустите её и посмотрите, почему она падала:
# Уточните настоящее имя службы, например через systemctl list-units 'php*-fpm.service':sudo systemctl list-units 'php*-fpm.service' --all# Затем изучите журнал своей службы: journalctl -u ИМЯ_СЛУЖБЫ -n 50 --no-pager# Запускайте/перезапускайте её лишь после устранения причины и с планом отката.Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Шаг 3. Сверьте адрес backend в конфигурации Nginx
Путь в fastcgi_pass должен в точности совпадать с директивой listen в пуле PHP-FPM (по умолчанию /etc/php/8.3/fpm/pool.d/www.conf).
fastcgi_pass 127.0.0.1:9000; и соответствующий listen в пуле.location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}#Шаг 4. Проверьте права на сокет
user в nginx.conf) должен совпадать с listen.owner/listen.group или входить в эту группу.[www]
user = www-data
group = www-data
listen = /run/php/php8.3-fpm.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660#Шаг 5. Проверьте исчерпание дочерних процессов
Если в журнале PHP-FPM встречается фраза server reached pm.max_children setting, все воркеры заняты, и новые запросы не обслуживаются. Увеличивать pm.max_children можно только с учётом доступной памяти: ориентируйтесь на средний размер процесса PHP, а не на «побольше».
#Шаг 6. Применяйте изменения безопасно
sudo nginx -t && sudo systemctl reload nginx#Как проверить результат
- Страница открывается, а в
error.logнет новых строк сupstream. - Команда
curl -I https://ваш-сайт/возвращает200или ожидаемый редирект.
#Если не помогло
Временно включите подробный журнал (error_log … info;), воспроизведите ошибку и сопоставьте время в журналах Nginx, PHP-FPM и приложения. Если 502 появляется только под нагрузкой, ищите нехватку памяти (журнал ядра dmesg и OOM-killer) и лимиты процессов.