видел на сайтах 502 Неверный шлюз И 504 Тайм-аут шлюза ошибки обычно возникают из-за того, что веб-сервер не получает правильный ответ от внутренней службы. Этой службой может быть PHP-FPM, серверная часть Apache, приложение Node.js, служба API игровой панели или другое приложение, работающее через прокси.

Эти ошибки особенно распространены на хостинге, игровой панели, WHMCS, Pterodactyl, пользовательской панели администрирования и веб-системах запуска.

1. Разница между ошибками 502 и 504

• 502 Неверный шлюз: Веб-сервер не может подключиться к серверной службе или получает искаженный ответ.
• 504 Тайм-аут шлюза: Кажется, что серверная служба отвечает, но ответ не возвращается вовремя.

Таким образом, 502 — это скорее сбой соединения/службы, а 504 — это проблема медленности или тайм-аута.

2. Проверка статусов услуг

Сначала проверьте, работают ли веб-сервер и службы PHP.

systemctl status nginx
systemctl status apache2
systemctl status php-fpm

В системах CentOS, AlmaLinux или Rocky Linux служба PHP-FPM может называться:

systemctl status php-fpm
systemctl status httpd

Если служба остановлена, перезапустите ее:

systemctl restart nginx
systemctl restart php-fpm

3. Просмотр файлов журналов

Неправильно гадать об ошибках 502 и 504. Файл журнала показывает реальную причину ошибки.

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/apache2/error.log

В системах на базе CentOS:

tail -n 100 /var/log/httpd/error_log

В журналах можно увидеть следующие утверждения:

• подключить() не удалось: Невозможно подключиться к серверной службе.
• время ожидания восходящего потока истекло: Серверная служба отвечает с опозданием.
• В соединении отказано: Служба не работает или происходит переадресация на неверный порт.
• доступ запрещен: Возникла проблема с сокетом или правами доступа к файлу.

4. Сокет PHP-FPM или управление портом

Nginx подключается к PHP-FPM через сокет или порт. Путь PHP-FPM в файле конфигурации Nginx и фактическое значение прослушивания PHP-FPM должны совпадать.

grep -R "fastcgi_pass" /etc/nginx/sites-enabled/
grep -R "listen =" /etc/php/*/fpm/pool.d/www.conf

Например, если Nginx использует:

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

Тот же сокет должен прослушиваться на стороне PHP-FPM:

listen = /run/php/php8.2-fpm.sock

5. Увеличение настроек таймаута

Ошибки 504 могут быть получены в больших панелях обработки, игровых рынках, API или медленно работающих PHP-скриптах. Значения таймаута Nginx можно увеличить.

nano /etc/nginx/nginx.conf

В блок http или соответствующий блок сервера можно добавить следующие значения:

proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
fastcgi_read_timeout 300;

Проверьте настройки и перезапустите Nginx:

nginx -t
systemctl restart nginx

6. Проверка ограничений процесса PHP-FPM

При увеличении трафика лимиты транзакций PHP-FPM могут оказаться недостаточными. В этом случае запросы ставятся в очередь и происходит таймаут.

nano /etc/php/8.2/fpm/pool.d/www.conf

Пример настроек:

pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

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

Распространенные ошибки

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

Часто задаваемые вопросы

Всегда ли ошибка 502 вызвана Nginx?
Нет. Ошибка показывает только Nginx. Настоящая проблема может быть в PHP-FPM, серверной части Apache, приложении Node.js или другом сервисе.

Является ли увеличение тайм-аута окончательным решением проблемы 504 ошибок?
Не всегда. Увеличение тайм-аута дает временное облегчение. Реальное решение — найти проблемы с медленным запросом, тяжелой обработкой или производительностью.

Безопасно ли перезапустить PHP-FPM?
В целом это безопасно, но активные запросы могут быть затронуты на короткое время. В загруженных системах следует отдавать предпочтение часам с низким трафиком.

Рекомендации по производительности

• Регулярно проверяйте версию PHP-FPM и путь к сокету.
• Изучите журналы медленных запросов в веб-панели и службах API.
• Если оперативной памяти недостаточно, не увеличивайте значение PHP-FPM max_children неосознанно.
• Уменьшите нагрузку на серверную часть с помощью системы кэширования.
• Управляйте журналами ошибок до того, как они разрастутся, с помощью logrotate.

Эта статья специально подготовлена ​​для PvPServer.