văzute pe site-uri web 502 Poarta proastă şi 504 Gateway Timeout erorile apar de obicei deoarece serverul web nu primește răspunsul corect de la serviciul back-end. Acest serviciu poate fi PHP-FPM, backend Apache, aplicația Node.js, serviciul API pentru panoul de jocuri sau o altă aplicație din spatele proxy-ului.

Aceste erori sunt frecvente în special în găzduire, panou de joc, WHMCS, Pterodactyl, panou de administrare personalizat și sisteme de lansare bazate pe web.

1. Diferența dintre Eroare 502 și 504

• 502 Bad Gateway: Serverul web nu se poate conecta la serviciul de backend sau primește un răspuns confuz.
• 504 Gateway Timeout: Serviciul backend pare să răspundă, dar răspunsul nu este returnat la timp.

Deci 502 este mai degrabă o blocare a conexiunii/serviciului, iar 504 este o problemă de încetinire sau de timeout.

2. Verificarea stărilor serviciului

Mai întâi, verificați dacă serverul web și serviciile PHP rulează.

systemctl status nginx
systemctl status apache2
systemctl status php-fpm

Pe sistemele CentOS, AlmaLinux sau Rocky Linux, serviciul PHP-FPM poate fi numit:

systemctl status php-fpm
systemctl status httpd

Dacă serviciul s-a oprit, reporniți-l:

systemctl restart nginx
systemctl restart php-fpm

3. Revizuirea fișierelor jurnal

Nu este corect să continuați cu presupuneri pentru erorile 502 și 504. Fișierul jurnal arată cauza reală a erorii.

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

Pe sisteme bazate pe CentOS:

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

Următoarele declarații pot fi văzute în jurnalele:

• connect() a eșuat: Nu se poate conecta la serviciul backend.
• a expirat: Serviciul backend răspunde cu întârziere.
• conexiune refuzată: Serviciul este întrerupt sau există redirecționare către portul greșit.
• permisiunea refuzata: Există o problemă cu socket-ul sau permisiunea fișierului.

4. PHP-FPM Socket sau Port Control

Nginx se conectează la PHP-FPM prin socket sau port. Calea PHP-FPM din fișierul de configurare Nginx și valoarea reală de ascultare PHP-FPM trebuie să fie aceleași.

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

De exemplu, dacă Nginx folosește:

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

Același socket ar trebui să fie ascultat pe partea PHP-FPM:

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

5. Creșterea setărilor de timeout

Erorile 504 pot fi primite în panouri mari de procesare, piețe de joc, API-uri sau scripturi PHP cu rulare lentă. Valorile de timeout Nginx pot fi mărite.

nano /etc/nginx/nginx.conf

Următoarele valori pot fi adăugate la blocul http sau la blocul de server relevant:

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

Testați setările și reporniți Nginx:

nginx -t
systemctl restart nginx

6. Verificarea limitelor de proces PHP-FPM

Când traficul crește, limitele tranzacțiilor PHP-FPM pot fi insuficiente. În acest caz, solicitările sunt puse în coadă și are loc un timeout.

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

Exemple de setări:

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

Aceste valori ar trebui ajustate în funcție de cantitatea de RAM a serverului. Setarea unei valori prea mari crește consumul de memorie RAM.

Greșeli comune

• Schimbarea setărilor fără a privi fișierul jurnal
• Nu se actualizează calea socketului Nginx, chiar dacă versiunea PHP s-a schimbat
• Nu remediați interogarea lentă reală prin creșterea timpului de expirare
• Creșterea limitelor PHP-FPM fără a calcula RAM
• Repornirea serviciului fără a testa configurația Nginx

Întrebări frecvente

Eroarea 502 este întotdeauna cauzată de Nginx?
Nu. Nginx este doar cel care arată eroarea. Problema reală poate fi în PHP-FPM, backend Apache, aplicația Node.js sau alt serviciu.

Creșterea timeout-ului este soluția definitivă pentru erorile 504?
Nu întotdeauna. Creșterea timeout-ului oferă o ușurare temporară. Soluția reală este să găsiți problema de interogare lentă, procesare grea sau performanță.

Este sigur să reporniți PHP-FPM?
În general, este sigur, dar solicitările active pot fi afectate pentru o perioadă scurtă de timp. În sistemele aglomerate, ar trebui preferate orele de trafic redus.

Recomandări de performanță

• Verificați regulat versiunea PHP-FPM și calea socketului.
• Examinați jurnalele de interogări lente în panoul web și serviciile API.
• Dacă RAM este insuficientă, nu creșteți inconștient valoarea PHP-FPM max_children.
• Reduceți încărcarea backend-ului utilizând un sistem cache.
• Gestionați jurnalele de erori înainte ca acestea să crească cu logrotate.

Acest articol este pregătit special pentru PvPServer.