Ошибки 502 и 504 на сайте: как отличить проблему Nginx, PHP-FPM и приложения

Диагностика ошибок 502 и 504 на сервере сайта

Ошибки 502 Bad Gateway и 504 Gateway Timeout часто выглядят для пользователя одинаково: сайт не открывается или отвечает через длительную паузу. Но причины у них могут быть совершенно разными — от остановленного PHP-FPM до зависшего запроса в базе данных или внешнего API.

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

Что обычно означает 502

В типовой связке Nginx + PHP-FPM веб-сервер передаёт PHP-запрос отдельному процессу. Ошибка 502 часто означает, что Nginx не смог получить корректный ответ от upstream: PHP-FPM не запущен, сокет недоступен, процесс аварийно завершился или конфигурации не совпадают.

Первым делом проверяют статус PHP-FPM, его журнал, путь к сокету или порту и ошибки Nginx.

Что обычно означает 504

504 чаще говорит о том, что соединение с обработчиком установлено, но ответ не пришёл вовремя. Причиной может быть тяжёлый PHP-код, медленный SQL-запрос, блокировка, обращение к недоступному API или слишком большой импорт.

Увеличить timeout иногда можно, но это не должно быть первым решением. Если обычная страница внезапно требует минуты на формирование, важно найти, куда уходит время.

С чего начинать диагностику

Зафиксировать точное время ошибки и проблемный URL.
Проверить error log Nginx или Apache.
Проверить журнал PHP-FPM и PHP-ошибки.
Посмотреть загрузку CPU, память и количество процессов.
Проверить базу данных и медленные запросы.
Уточнить, обращается ли страница к внешним сервисам.

Почему простой рестарт не решает проблему

Перезапуск PHP-FPM может временно вернуть сайт в работу, особенно если процессы зависли или исчерпали память. Но без анализа логов причина останется. Через несколько часов ситуация повторится, а полезные следы предыдущего сбоя могут уже исчезнуть.

Рестарт — это способ восстановить доступность, но не диагностика причины 502 или 504.

На что смотреть в PHP-FPM

достаточно ли процессов для текущей нагрузки;
не достигается ли лимит pm.max_children;
нет ли процессов, регулярно завершающихся по памяти;
совпадает ли сокет в настройках Nginx и PHP-FPM;
не появились ли ошибки после смены версии PHP.

Если проблема началась именно после обновления PHP, дополнительно проверьте собственный код и модули. Для этого есть отдельный материал о поиске несовместимости после обновления PHP.

Когда виновата база данных

PHP-процесс может быть жив, но ждать SQL слишком долго. В такой ситуации в журналах веб-сервера будет только итоговый таймаут, а корень проблемы находится в базе. Проверяют активные запросы, блокировки, slow query log и изменения, которые произошли перед появлением ошибки.

Не забывайте о внешних API

Если страница в реальном времени ждёт ответ CRM, платёжной системы или другого API, недоступность внешнего сервиса может задержать весь запрос. Для таких интеграций нужны разумные сетевые таймауты и сценарий ошибки, при котором сайт продолжает работать.

Общий порядок проверки полной недоступности сайта разобран в статье «Сайт не открывается: с чего начинать диагностику».

Поиск причин 502/504, анализ Nginx, PHP-FPM и базы данных относится к задачам технической поддержки.