Перейти к содержанию
Инциденты

502 Bad Gateway в Nginx: полный порядок диагностики

Код 502 означает, что Nginx принял запрос, но не получил корректный ответ от upstream-приложения. Причину нужно искать между proxy и приложением: в процессе, сокете или порте, таймауте, правах, ресурсах и логах около точного времени ошибки.

Антон БелогородцевЧтение: 4 минОбновлено 15 июля 2026 г.5 практических разделов
Что получите
01зафиксируйте точное время с часовым поясом
02проверьте один URL и весь домен
03сохраните заголовки и тело ответа

Диагностическое дерево HTTP 5xx

Выберите симптом, чтобы увидеть вероятную зону проверки.

Проверьте приложение

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

Короткий ответ

Практическая диагностика 502 Bad Gateway в Nginx: upstream, PHP-FPM, сокеты, порты, таймауты, логи и безопасный порядок восстановления.

01

Что именно сообщает 502

Nginx в этой ситуации работает и отвечает клиенту сам. Ошибка находится дальше по цепочке: upstream не запущен, преждевременно закрыл соединение, слушает другой адрес или не успел ответить.

Сначала зафиксируйте URL, время, повторяемость и область влияния. Если 502 возвращает один route, вероятнее проблема конкретного обработчика. Если весь сайт — проверьте процесс приложения и конфигурацию upstream.

зафиксируйте точное время с часовым поясом
проверьте один URL и весь домен
сохраните заголовки и тело ответа
не перезапускайте всё до чтения логов
02

Начните с 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/...`.

connection refused — процесс не слушает адрес
no such file — путь к сокету неверен
permission denied — права на сокет или каталог
prematurely closed — приложение завершило ответ аварийно
Разовая проверка показывает сейчас

Мониторинг покажет, когда состояние изменится

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

Начать бесплатно
03

Сверьте конфигурацию Nginx с реальным процессом

Значение proxy_pass или fastcgi_pass должно совпадать с фактическим listener. После обновления PHP путь к сокету часто меняется, а после переноса приложения порт может остаться старым.

Проверьте итоговую конфигурацию через `nginx -T`, а синтаксис — через `nginx -t`. Reload безопаснее restart, но выполняйте его только после успешной проверки и понимания изменения.

сравните host, port или путь к socket
проверьте активный server block
учтите контейнерную сеть и DNS имени сервиса
не применяйте конфигурацию при ошибке nginx -t
04

Проверьте ресурсы и таймауты

Если upstream существует, но отвечает нестабильно, сопоставьте 502 с CPU, RAM, OOM, диском, числом worker-процессов, очередями и медленными запросами базы данных. Заполненный диск или OOM часто проявляются как внезапные обрывы.

Увеличение proxy_read_timeout может скрыть симптом, но не исправляет медленную операцию. Сначала найдите запрос, который не укладывается в ожидаемое время, и проверьте его зависимости.

ищите OOM в kernel journal
проверьте свободное место и inode
сопоставьте время 502 с нагрузкой
измерьте ответ upstream напрямую
05

Восстановите сервис и не потеряйте причину

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

Затем добавьте регулярную проверку критичного URL и серверных ресурсов. В ретроспективе сохраните начало, влияние, подтверждённую причину, действие и защиту от повторения.

проверка upstream из той же сети
проверка внешнего URL несколько раз
контроль сообщения о восстановлении
алерт на URL, heartbeat, диск и память
От знания к системе

Автоматизируйте проверку, описанную в статье

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

Настроить бесплатно
01Добавьте URL и включите регулярные проверки.
02Собирайте HTTP, TTFB, SSL и историю состояния.
03Получайте сигнал о сбое и отдельное сообщение о восстановлении.

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

Короткие ответы на вопросы, которые обычно возникают при диагностике.

Чем 502 отличается от 504?

При 502 proxy получил некорректный ответ или не подключился к upstream. 504 обычно означает, что upstream не ответил за отведённое время.

Нужно ли сразу перезапускать Nginx?

Нет. Nginx уже отвечает. Сначала прочитайте error.log и проверьте upstream; бездумный restart может стереть полезный контекст и создать новый сбой.

Можно ли просто увеличить timeout?

Только если длительная операция ожидаема и безопасна. В остальных случаях это маскирует медленное приложение, базу или внешнюю зависимость.

Как проверить, что проблема устранена?

Проверьте upstream напрямую, затем внешний URL несколько раз, статус в мониторинге и отсутствие новых ошибок в логах.

Следующий шаг

Не ждите следующего сообщения «сайт не работает»

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

7 дней бесплатнобез картыотмена в любой момент