Сбои и доступность
502 Bad Gateway: Nginx не получает корректный ответ PHP
Nginx показывает 502 Bad Gateway. Объясняем, почему это часто проблема связи с обработчиком сайта и что сообщить администратору.
Что происходит и с чего начать
Веб-сервер может принимать запрос посетителя и передавать его другому процессу, например PHP-FPM. Если вместо ожидаемого ответа он получает отказ или некорректный результат, появляется 502. Сам код не доказывает, что PHP просто остановлен: нужно проверить сообщения Nginx за время сбоя. На некоторых схемах есть ещё внешний прокси, поэтому важно установить, какой узел показал ошибку. Начните с того, работают ли статические файлы и какие адреса перестали открываться.
Что можно проверить самостоятельно
- Сохраните время ошибки и адрес страницы. Проверьте, открываются ли другие динамические страницы и небольшой статический файл, не создавая большое число повторных запросов.
- Уточните, началось ли это после обновления PHP, перезапуска, переноса или изменения конфигурации сервера. Эти события помогают найти несогласованные параметры подключения.
- Если есть панель хостинга, проверьте сообщения о состоянии служб. Не перезапускайте все сервисы подряд до сохранения ошибки: это может уничтожить сведения о первой причине отказа.
Как понять результаты проверки
Специалист сопоставляет журнал Nginx со службой, которой он передаёт запросы. Проверяются адрес соединения, права доступа, работа процесса и возможное аварийное завершение. Слово upstream в журнале обозначает следующий сервер или обработчик в цепочке. Оно не обязательно относится к внешнему сервису в интернете. Техническое решение зависит от сообщения: отсутствие соединения, закрытие его во время ответа и неверный ответ требуют разных проверок. Одна лишь замена 502 на красивую заглушку не восстанавливает работу приложения.
Что проверяет разработчик
Для этой части понадобятся доступ к настройкам, журналам ошибок или коду. Её можно передать специалисту вместе с результатами предыдущих шагов.
- Найдите запись error log для неудачного запроса. Ошибка подключения к сокету отличается от преждевременного закрытия соединения процессом.
- Проверьте состояние PHP-FPM, адрес сокета или порта и права доступа. После обновления PHP Nginx может обращаться к старому пути.
- При периодическом сбое сопоставьте его с перезапусками, нехваткой памяти и аварийным завершением процессов.
На что обратить внимание
Служба может быть запущена, но слушать другой сокет. Если процесс падает во время обработки, кратковременный перезапуск восстанавливает доступность, однако причина сбоя остаётся.
Как исправляют причину
Согласуйте upstream с фактической службой и исправьте причину завершения процессов. Перед применением конфигурации выполните её проверку. Не увеличивайте тайм-ауты, если соединение вообще не устанавливается.
Как убедиться, что проблема решена
Проверьте динамические страницы и исходное проблемное действие. Понаблюдайте за журналами после нескольких запросов и планового перезапуска службы.
После исправления проверьте исходную страницу, отправку формы и несколько последовательных запросов. Убедитесь, что служба не перезапускается сама через короткие интервалы и новые ошибки не накапливаются. Если проблема касалась конфигурации запуска, полезна проверка после согласованного перезапуска сервиса. Это подтверждает, что настройки сохранены, а сайт не работает только благодаря временно запущенному вручную процессу.