PvP Server Kiralama & Oyun Sunucuları
0 Giriş Yap Kayıt Ol

Рішення помилки 502 Bad Gateway і 504 Gateway Timeout Error на сервері Linux

Yazdır

Рішення помилки 502 Bad Gateway і 504 Gateway Timeout Error на сервері Linux

Покроковий посібник із вирішення проблем Nginx, Apache, PHP-FPM і часу очікування служби.

побачив на веб-сайтах 502 Поганий шлюз і 504 Час очікування шлюзу помилки зазвичай виникають через те, що веб-сервер не отримує правильну відповідь від внутрішньої служби. Цією службою може бути PHP-FPM, бекенд Apache, програма Node.js, служба API ігрової панелі або інша програма за проксі.

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

Просте пояснення: Nginx схожий на слугу біля дверей. Якщо PHP або програма всередині не відповідає, користувачеві буде показано помилку 502 або 504.

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
Важливо: Якщо версія PHP змінилася, Nginx може все ще переглядати старий шлях сокета PHP-FPM. Це одна з найпоширеніших причин помилок 502.

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.

Bu cevap yeterince yardımcı oldu mu?

Oyla

overlay spinner