Отладка ошибок шлюза/Gateway Errors 502 и 504

Иногда встречаются ошибки шлюзов, обычно 502 Bad Gateway или 504 Gateway Timeout.

Это ошибки, которые возвращает Nginx, когда он посылает запрос к PHP, но PHP возвращает какую-то ошибку, говорящую, что он не может обработать запрос. Как правило, это НЕ ошибки, возникающие в вашем приложении, а (обычно) ошибки, возникающие ещё до того, как приложение обработает запрос.

Что такое шлюз/Gateway

Шлюз/Gateway — это то, что находится между веб-сервером (обычно Nginx) и вашим приложением. Для большинства из нас это PHP-FPM. Nginx использует протокол fastcgi для преобразования веб-запроса в то, что может понять PHP-FPM. Затем PHP-FPM запускает ваше приложение, настраивая PHP на необходимую ему информацию (устанавливая супер глобальные переменные $_GET, $_POST, $_SESSION, $_SERVER и т.д.).

Если PHP-FPM возвращает ошибку, то Nginx выдаёт нам ошибку шлюза/Gateway.

Bad Gateway

Bad Gateway возвращается, когда PHP-FPM возвращает ошибку. Обычно это одна из следующих ошибок:

1. PHP-FPM не работает (возможно, из-за большого количества ошибок)
2. PHP-FPM достиг предела max_children и не может больше обрабатывать запросы
3. Какая-либо ошибка PHP, например segfault

Таймаут Шлюза/Gateway Timeout

Ошибки таймаута шлюза/Gateway Timeout обычно возникают, когда ваше приложение обрабатывает слишком большой трафик. Это может соответствовать ошибкам PHP-FPM max_children (слишком большое количество запросов, на которое он настроен), но в основном это происходит, когда ваша база данных перегружена и не может обрабатывать дополнительные соединения, выполняющие запросы. На возврат запросов уходит слишком много времени.

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

Отладка ошибок шлюза/Gateway Errors

Основное правило для отладки ошибок шлюза — это логи. Я начинаю с вершины стека сетевых запросов и двигаюсь вниз. Это означает, что логи я проверяю в следующем порядке:

1. Nginx
2. PHP-FPM
3. Использование ресурсов сервера
4. Журналы приложений

Логи Nginx обычно содержат наименее полезные данные, хотя они могут подсказать вам, что PHP-FPM не работает (если он не может найти файл сокета PHP-FPM, например, /var/run/php-fpm.sock).

Логи FPM обычно наиболее полезны, поскольку PHP-FPM — это шлюз, возвращающий ошибку! Часто вы увидите ошибку, связанную с достижением (или приближением) ограничения max_children. Реже можно увидеть ошибку segfault (если вы видите такую ошибку, то, вероятно, в вашем коде есть рекурсия).

Использование ресурсов сервера — это то, что я бы проверил следующим. Можно использовать htop или аналогичную программу для проверки использования CPU/RAM и того, какие процессы их используют. Также следует проверить использование диска с помощью df -h, чтобы проверить, не закончилось ли на нем свободное место.

Возможно, у вас также закончились inode! Inode — это "индексные узлы", используемые для отслеживания использования файлов в системах linux. Поскольку все является файлами (включая то, как Linux обрабатывает открытые сетевые соединения!), нехватка inode может стать проблемой. Вы можете выполнить команду df -i, чтобы увидеть использование inode на каждом диске.

Наконец, я проверяю журналы приложений. Они могут показать ошибки, связанные с тайм-аутом или ошибками базы данных, но иногда проблема не связана с кодовой базой приложения. Насколько полезны эти журналы, будет зависеть от ошибок шлюза.