Рішення помилки 502 Bad Gateway і 504 Gateway Timeout Error на сервері Linux
Покроковий посібник із вирішення проблем Nginx, Apache, PHP-FPM і часу очікування служби.
побачив на веб-сайтах 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
У журналах можна побачити такі заяви:
- Connect() не вдалося: Неможливо підключитися до серверної служби.
- вичерпано час очікування: Бекенд-служба відповідає із запізненням.
- з'єднання відмовлено: Служба не працює або відбувається переадресація на неправильний порт.
- у дозволі відмовлено: Виникла проблема з дозволом на сокет або файл.
4. PHP-FPM Socket або Port Control
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 можуть виникати у великих панелях обробки, Play Market, 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
FAQ
Чи завжди помилку 502 викликає Nginx?
Ні. Nginx — це лише той, хто показує помилку. Справжня проблема може бути в PHP-FPM, серверній частині Apache, програмі Node.js або іншій службі.
Чи є збільшення часу очікування остаточним рішенням для помилок 504?
Не завжди. Збільшення тайм-ауту забезпечує тимчасове полегшення. Реальне рішення полягає в тому, щоб знайти повільний запит, важку обробку або проблему продуктивності.
Чи безпечно перезапускати PHP-FPM?
Загалом це безпечно, але на активні запити може вплинути на короткий час. У завантажених системах слід віддавати перевагу годинам із низьким трафіком.
Рекомендації щодо продуктивності
- Регулярно перевіряйте версію PHP-FPM і шлях до сокета.
- Перегляньте журнали повільних запитів у веб-панелі та службах API.
- Якщо оперативної пам’яті недостатньо, не збільшуйте значення PHP-FPM max_children несвідомо.
- Зменште навантаження на сервер за допомогою системи кешу.
- Керуйте журналами помилок, перш ніж вони збільшаться, за допомогою logrotate.
Ця стаття спеціально підготовлена для PvPServer.