Ошибка 502 Bad Gateway: как найти и починить

Где именно рвётся цепочка

Запрос идёт по маршруту «браузер → nginx → приложение (PHP-FPM, Node, Python) → база». 502 появляется на втором стыке: nginx жив и отвечает, а процесс приложения умер, перезапускается или не слушает свой порт и сокет.

Частые причины

• →Приложение упало и не поднялось: закончилась память, процесс убит OOM-killer.
• →Перезапуск во время деплоя — секунды, когда старый процесс уже остановлен, а новый ещё не слушает.
• →Неверный upstream в конфиге: сменился порт или путь к сокету.
• →Приложение не выдерживает нагрузку — очередь воркеров переполнена.
• →Слишком долгий ответ: связка отваливается по proxy_read_timeout, отдавая 502 вместо 504.

Что проверить по шагам

• →Посмотрите error.log nginx: там прямо написано «connect() failed» или «upstream prematurely closed connection».
• →Проверьте, что процесс приложения жив и слушает нужный порт или сокет.
• →Гляньте свободную память и лимиты воркеров: 502 под нагрузкой почти всегда об этом.
• →Сверьте время сбоя с временем деплоя — короткие 502 при выкате лечатся graceful reload.

sudo tail -n 100 /var/log/nginx/error.log
systemctl status php8.2-fpm   # или ваш процесс
ss -lntp | grep 9000

Как не узнавать о 502 от клиентов

Мониторинг Logsy стучится в ваши адреса раз в минуту и ждёт конкретный код ответа. Как только вместо 200 приходит 502, уведомление уходит на почту и в Telegram — с адресом, кодом и временем. Если ошибка плавающая и ловится только у части посетителей, её видно в логе сессий: там сохраняется сам упавший запрос.