502 Bad Gateway в nginx: виноват бэкенд, а не nginx

502 Bad Gateway от nginx значит, что сам nginx работает нормально, — отказал ваш бэкенд. nginx попытался передать запрос вашему приложению (PHP-FPM, процессу Node, gunicorn, другому серверу) и не получил ничего пригодного. Поэтому отлаживать нужно то, что стоит за nginx, а не сам nginx.

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

Соседние коды выглядят похоже, но указывают на другое. 500 Internal Server Error (англ.) значит, что бэкенд ответил, но собственной ошибкой, а 503 Service Unavailable (англ.) — что запрос отклонили намеренно, например из-за заполненного пула PHP-FPM или режима обслуживания. 404 Not Found (англ.) вообще не сбой: nginx или приложение ответили и ничего не нашли по этому пути. Если сайт работает за Cloudflare и страница ошибки принадлежит самому Cloudflare, смотрите на её код: ошибка 520 (англ.) значит, что ответ вашего сервера оборвался, а ошибка 522 — что Cloudflare не смог к нему подключиться.

Всегда начинайте с лога ошибок

В логе названа точная причина. Прочитайте его, прежде чем трогать конфигурацию:

sudo tail -n 50 /var/log/nginx/error.log

Сообщение указывает прямо на причину (nginx их не переводит, так что текст одинаков на любом сервере):

• connect() failed (111: Connection refused) — бэкенд не запущен.
• no live upstreams — все бэкенды, о которых знает nginx, лежат.
• upstream timed out — бэкенд жив, но слишком медленный.
• connect() to unix:/…​.sock failed — неверный путь к сокету или права доступа.

Причина 1: бэкенд не запущен

# выберите тот, что используете
sudo systemctl status php8.3-fpm
sudo systemctl status your-node-app
sudo systemctl restart php8.3-fpm

Убедитесь, что он действительно слушает там, где его ждёт nginx. Если nginx проксирует на 127.0.0.1:3000, этот порт должен появиться здесь:

sudo ss -tlnp | grep -E ':3000|php|fpm'

Причина 2: неверный сокет или порт в конфигурации

Адрес в fastcgi_pass или proxy_pass должен совпадать с тем, на котором слушает бэкенд. Классический повод — обновление PHP, которое меняет путь к сокету (php8.2-fpm.sock → php8.3-fpm.sock):

grep -R "fastcgi_pass\|proxy_pass" /etc/nginx/
ls /run/php/    # какой сокет на самом деле существует?

Причина 3: бэкенд слишком медленный

Если в логе написано timed out, приложение работает, но не успевает ответить за время, которое ему отводит nginx. Увеличьте таймаут как временную меру, а по-настоящему лечите медленный код или добавляйте ресурсы:

# в блоке location или server
proxy_read_timeout 120s;
# затем
sudo nginx -t && sudo systemctl reload nginx

Причина 4: права на сокет

Когда nginx и бэкенд работают от разных пользователей, nginx может не иметь права открыть сокет. Приведите listen.owner/listen.group пула FPM в соответствие с пользователем nginx (часто это www-data), затем перезапустите оба.

Когда бэкенд снова отвечает, проверьте страницу снаружи: проверка HTTP-заголовков (англ.) запрашивает её с нашего сервера, показывает код статуса каждого редиректа по пути и сообщает, если вместо вашего сервера ответила защита от ботов CDN.

Постоянные 502 под трафиком часто значат, что сервер попросту мал для нагрузки. Тариф Hi-CPU KVM даёт PHP-FPM и Node вычислительный запас, чтобы ответы укладывались в таймаут nginx.

Частые вопросы