видено на веб-страниците 502 Bad Gateway и Истекување на 504 Gateway грешки обично се случуваат затоа што веб-серверот не го добива точниот одговор од back-end услугата. Оваа услуга може да биде PHP-FPM, заднина на Apache, апликација Node.js, услуга API на панелот за игри или друга апликација зад прокси.

Овие грешки се особено чести во хостинг, панел за игри, WHMCS, Pterodactyl, прилагоден административен панел и веб-базирани системи за фрлање.

1. Разлика помеѓу 502 и 504 Грешка

• 502 Bad Gateway: Веб-серверот не може да се поврзе со заднинската услуга или добива погрешен одговор.
• 504 Gateway Timeout: Се чини дека позадинската услуга реагира, но одговорот не се враќа навреме.

Значи, 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 приклучок или контрола на порта

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

Овие вредности треба да се прилагодат според количината на RAM меморија на серверот. Поставувањето превисока вредност ја зголемува потрошувачката на RAM меморија.

Вообичаени грешки

• Промена на поставките без да се гледа во датотеката за евиденција
• Не се ажурира патеката на штекерот Nginx иако верзијата на PHP е променета
• Не го поправаме вистинското бавно барање со зголемување на истекувањето
• Зголемување на границите на PHP-FPM без пресметување на RAM меморијата
• Рестартирање на услугата без тестирање на Nginx конфигурација

Најчесто поставувани прашања

Дали грешката 502 е секогаш предизвикана од Nginx?
Не. Nginx е само оној што ја покажува грешката. Вистинскиот проблем може да биде во PHP-FPM, заднината на Apache, апликацијата Node.js или друга услуга.

Дали зголемувањето на тајмаутот е дефинитивно решение за грешките 504?
Не секогаш. Зголемениот тајмаут обезбедува привремено олеснување. Вистинското решение е да се најде бавното барање, тешката обработка или проблемот со перформансите.

Дали е безбедно да се рестартира PHP-FPM?
Генерално е безбедно, но активните барања може да бидат засегнати за кратко време. Во зафатените системи, треба да се претпочитаат ниски часови на сообраќај.

Препораки за изведба

• Редовно проверувајте ја верзијата на PHP-FPM и патеката на штекерот.
• Испитајте ги бавните дневници за пребарување во веб-панелот и услугите на API.
• Ако RAM меморијата е недоволна, не ја зголемувајте вредноста на PHP-FPM max_children несвесно.
• Намалете го оптоварувањето на задниот дел со користење на кеш систем.
• Управувајте со дневниците за грешки пред да пораснат со логротат.

Оваа статија е специјално подготвена за PvPServer.