502 Bad Gateway в Nginx: полный порядок диагностики
Код 502 означает, что Nginx принял запрос, но не получил корректный ответ от upstream-приложения. Причину нужно искать между proxy и приложением: в процессе, сокете или порте, таймауте, правах, ресурсах и логах около точного времени ошибки.
Диагностическое дерево HTTP 5xx
Выберите симптом, чтобы увидеть вероятную зону проверки.
Начните с логов backend, последних деплоев, переменных окружения и ошибок базы данных.
Практическая диагностика 502 Bad Gateway в Nginx: upstream, PHP-FPM, сокеты, порты, таймауты, логи и безопасный порядок восстановления.
Что именно сообщает 502
Nginx в этой ситуации работает и отвечает клиенту сам. Ошибка находится дальше по цепочке: upstream не запущен, преждевременно закрыл соединение, слушает другой адрес или не успел ответить.
Сначала зафиксируйте URL, время, повторяемость и область влияния. Если 502 возвращает один route, вероятнее проблема конкретного обработчика. Если весь сайт — проверьте процесс приложения и конфигурацию upstream.
Начните с error.log и состояния upstream
В error.log Nginx обычно есть формулировка, которая резко сужает поиск: connection refused, no such file, permission denied, upstream timed out или prematurely closed connection.
Одновременно проверьте, запущен ли сервис приложения и что он слушает ожидаемый порт или Unix-сокет. Для systemd пригодятся `systemctl status <service>` и `journalctl -u <service> --since "10 minutes ago"`. Для порта — `ss -lntp`; для сокета — `ls -la /run/...`.
Мониторинг покажет, когда состояние изменится
Добавьте сайт или сервер один раз — perfMon будет проверять его автоматически, сохранит историю и сообщит о сбое и восстановлении.
7 дней без оплаты и банковской карты с момента создания сервера. Затем 2 000 ₽ за сервер за 30 дней, до 50 сайтов на сервер. Продление вручную. Условия тарифа
Сверьте конфигурацию Nginx с реальным процессом
Значение proxy_pass или fastcgi_pass должно совпадать с фактическим listener. После обновления PHP путь к сокету часто меняется, а после переноса приложения порт может остаться старым.
Проверьте итоговую конфигурацию через `nginx -T`, а синтаксис — через `nginx -t`. Reload безопаснее restart, но выполняйте его только после успешной проверки и понимания изменения.
Проверьте ресурсы и таймауты
Если upstream существует, но отвечает нестабильно, сопоставьте 502 с CPU, RAM, OOM, диском, числом worker-процессов, очередями и медленными запросами базы данных. Заполненный диск или OOM часто проявляются как внезапные обрывы.
Увеличение proxy_read_timeout может скрыть симптом, но не исправляет медленную операцию. Сначала найдите запрос, который не укладывается в ожидаемое время, и проверьте его зависимости.
Восстановите сервис и не потеряйте причину
Если подтверждено, что процесс остановлен, восстановите именно его и проверьте upstream напрямую до внешнего URL. После восстановления убедитесь, что 502 исчез, корректный статус стабилен, а логи не продолжают расти.
Затем добавьте регулярную проверку критичного URL и серверных ресурсов. В ретроспективе сохраните начало, влияние, подтверждённую причину, действие и защиту от повторения.
Автоматизируйте проверку, описанную в статье
Разовая диагностика помогает сейчас. Регулярный мониторинг нужен, чтобы не пропустить повторение проблемы.
7 дней без оплаты и банковской карты с момента создания сервера. Затем 2 000 ₽ за сервер за 30 дней, до 50 сайтов на сервер. Продление вручную. Условия тарифа
Попробовать 7 днейПрименить на практике
Частые вопросы
Короткие ответы на вопросы, которые обычно возникают при диагностике.
Чем 502 отличается от 504?
При 502 proxy получил некорректный ответ или не подключился к upstream. 504 обычно означает, что upstream не ответил за отведённое время.
Нужно ли сразу перезапускать Nginx?
Нет. Nginx уже отвечает. Сначала прочитайте error.log и проверьте upstream; бездумный restart может стереть полезный контекст и создать новый сбой.
Можно ли просто увеличить timeout?
Только если длительная операция ожидаема и безопасна. В остальных случаях это маскирует медленное приложение, базу или внешнюю зависимость.
Как проверить, что проблема устранена?
Проверьте upstream напрямую, затем внешний URL несколько раз, статус в мониторинге и отсутствие новых ошибок в логах.
Не ждите следующего сообщения «сайт не работает»
Добавьте первый сайт или сервер: perfMon будет проверять состояние автоматически, сохранит историю и уведомит ответственных.
7 дней без оплаты и банковской карты с момента создания сервера. Затем 2 000 ₽ за сервер за 30 дней, до 50 сайтов на сервер. Продление вручную. Условия тарифа