WordPress 502 Bad Gateway în 2026: Ghidul complet de depanare și rezolvare (DirectAdmin + VPS)

O eroare WordPress 502 Bad Gateway înseamnă că NGINX a primit cererea, a transmis-o către PHP-FPM pentru procesare și nu a primit niciun răspuns valid înapoi. Rezolvarea ține aproape întotdeauna de una dintre cele șapte situații: PHP-FPM este oprit, calea socketului este greșită, poolul de workere FPM este epuizat, timeoutul FastCGI al NGINX este prea scurt, procesul a fost terminat de OOM killerul Linux, MySQL blochează workere PHP, sau un firewall (inclusiv fail2ban) blochează traficul de loopback. Acest ghid parcurge sistematic diagnosticarea fiecărei cauze, cu comenzi reale și căi specifice DirectAdmin, astfel încât să nu ghicești.

Înainte de orice: citește logurile

Nu atinge fișierele de configurare înainte de a ști care este eroarea exactă. Logurile îți vor spune precis cu ce categorie de 502 ai de-a face, iar săritul peste acest pas pierde timp. Rulează aceste trei comenzi în ordine și citește outputul cu atenție înainte de a trece la orice secțiune de rezolvare.

# Logul de erori NGINX — îți arată ce a văzut NGINX când cererea a eșuat
tail -50 /var/log/nginx/error.log

# Logul PHP-FPM — îți arată dacă FPM cade, rămâne fără workere sau refuză conexiuni
tail -50 /var/log/php8.5-fpm.log

# Ring bufferul kernelului — îți arată dacă OOM killerul a pornit și a terminat un proces
dmesg | grep -iE "oom|killed process" | tail -20

Logul de erori NGINX este cel mai important. O linie care conține connect() to unix:/var/run/php/php8.5-fpm.sock failed (2: No such file or directory) indică Fix 1 sau Fix 2. O linie cu connect() failed (111: Connection refused) indică Fix 1. O linie cu upstream timed out (110: Connection timed out) indică Fix 4. O linie fără nicio eroare upstream, combinată cu o intrare OOM în kernel, indică Fix 5. Potrivește tiparul erorii cu remediul corespunzător.

Fix 1: PHP-FPM este oprit

Aceasta este cea mai frecventă cauză. PHP-FPM se oprește silențios după un eveniment de epuizare a memoriei, un update eșuat sau o eroare în configurația poolului, în timp ce NGINX rămâne activ. Monitorizarea automată a serviciilor din DirectAdmin supraveghează NGINX, dar nu repornește întotdeauna PHP-FPM alături de acesta.

systemctl status php8.5-fpm

# Dacă este inactiv sau în stare de eroare:
systemctl start php8.5-fpm

# Verifică de ce nu a pornit (citește outputul complet):
journalctl -xeu php8.5-fpm --no-pager | tail -30

Dacă pornește fără probleme și eroarea 502 dispare, investigația nu s-a încheiat. Ceva l-a oprit. Verifică logul PHP-FPM și logul OOM al kernelului (Fix 5) pentru a găsi cauza principală, altfel va cădea din nou în câteva ore. Dacă systemctl raportează o eroare de sintaxă în configurația poolului, găsește și corectează directiva problematică înainte de repornire.

Fix 2: Nepotrivire între calea socketului din NGINX și PHP-FPM

Aceasta este a doua cauză ca frecvență și este aproape întotdeauna declanșată de un upgrade de versiune PHP prin CustomBuildul DirectAdmin. Când CustomBuild upgradează PHP (de exemplu de la 8.4 la 8.5), creează un nou fișier socket la o cale nouă, dar nu actualizează automat fiecare configurație de virtual host NGINX care referențiază calea veche. Fișierul socket referit în configurația NGINX nu mai există, producând eroarea „No such file or directory" în logul NGINX.

Mai întâi, listează ce fișiere socket există efectiv pe server în acest moment.

ls -la /var/run/php/

Apoi găsește ce solicită efectiv configurația de virtual host NGINX pentru domeniul afectat.

# DirectAdmin stochează configurațiile de virtual host aici:
grep -r "fastcgi_pass" /etc/nginx/conf.d/virtual/domeniultau.conf

# Sau caută în toate virtual hosturile simultan:
grep -r "fastcgi_pass" /etc/nginx/conf.d/virtual/

Valoarea de după fastcgi_pass unix: trebuie să corespundă exact unui fișier socket care există în /var/run/php/. Dacă diferă, editează configurația virtual hostului pentru a referenția calea corectă a socketului, apoi testează și reîncarcă NGINX.

nginx -t && systemctl reload nginx

În DirectAdmin, configurația NGINX per utilizator se află de obicei la /etc/nginx/conf.d/virtual/username.domeniultau.conf. Modificările făcute aici supraviețuiesc rebuildurilor CustomBuild dacă se află în fișierul de configurare corect, controlat de utilizator. Modificările făcute în configurația globală NGINX vor fi suprascrise la următoarea rulare CustomBuild.

Fix 3: Poolul de workere PHP-FPM este epuizat (pm.max_children)

PHP-FPM poate rula cu socketul corect și tot poate produce erori 502 sub trafic, dacă toate sloturile de workere disponibile sunt ocupate. Când toate sloturile pm.max_children sunt pline și sosește o nouă cerere, PHP-FPM nu poate accepta conexiunea. NGINX așteaptă până expiră timeoutul fastcgi_read_timeout și returnează un 502. Aceasta produce erori intermitente care se agravează pe măsură ce traficul crește.

Logul FPM va afișa avertismentul explicit când aceasta este cauza.

grep "max_children" /var/log/php8.5-fpm.log

Dacă găsești intrări de tipul server reached pm.max_children setting (X), consider raising it, poolul este subdimensionat. Deschide configurația poolului și recalculează limita pe baza memoriei RAM disponibile efectiv. Găsește mai întâi dimensiunea medie de memorie a workerelor PHP active.

ps --no-headers -o "rss,cmd" -C php-fpm8.5 | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }'

Dacă outputul arată 45MB per proces și ai 1.8GB de RAM disponibili pentru PHP (după scăderea NGINX, MySQL și overheadului OS), maximul tău sigur este de 40 de procese child (1800 / 45 = 40). Deschide /etc/php/8.5/fpm/pool.d/www.conf (sau fișierul pool per utilizator în setupul DirectAdmin) și ajustează corespunzător. Schimbă și managerul de procese din ondemand în dynamic pentru a menține workere de bază pre-inițializate și a elimina latența de cold-start.

pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 500

systemctl reload php8.5-fpm

Fix 4: Timeoutul FastCGI din NGINX este prea scurt

Operațiunile WordPress grele — importuri mari de produse WooCommerce, randări de pagini Elementor cu zeci de widgeturi sau ecrane de administrare care rulează interogări complexe de baze de date — pot depăși timeoutul implicit FastCGI de 60 de secunde al NGINX. NGINX abandonează conexiunea și returnează un 502 chiar dacă PHP-FPM procesează cererea normal în background.

Logul de erori NGINX va afișa upstream timed out (110: Connection timed out) while reading response header from upstream dacă aceasta este cauza. În DirectAdmin, adaugă override-urile de timeout în blocul de configurare NGINX personalizat al domeniului, nu în configurația globală NGINX. Locul corect pentru personalizările la nivel de utilizator care supraviețuiesc unui rebuild CustomBuild este în fișierul de virtual host per utilizator.

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

Aceasta este o măsură de atenuare, nu o rezolvare. Un proces PHP care necesită 120 de secunde pentru a genera o pagină are o problemă — o interogare lentă la baza de date, un apel API extern blocant sau un plugin prost codat. După creșterea timeoutului pentru a opri erorile 502, instalează pluginul Query Monitor și profilează cererea lentă pentru a găsi bottleneckul real.

Fix 5: OOM Killerul Linux a terminat PHP-FPM

Dacă PHP-FPM este găsit oprit fără erori în propriul log, iar repornirea lui rezolvă temporar eroarea 502 înainte ca aceasta să reapară, OOM killerul Linux este probabil vinovatul. OOM killerul kernelului este un mecanism de ultimă instanță care termină procesul cel mai consumator de memorie pentru a preveni blocarea totală a sistemului. Își scrie acțiunile în logul kernelului, nu în logul PHP-FPM — de aceea este atât de frecvent trecut cu vederea.

dmesg | grep -iE "oom|killed process" | tail -20
# Sau prin journalctl:
journalctl -k | grep -iE "oom|killed"

Dacă găsești intrări de tipul Out of memory: Kill process [PID] (php-fpm8.5) score X or sacrifice child, RAM-ul de pe VPS-ul tău este insuficient pentru setarea curentă pm.max_children. Repornirea PHP-FPM fără reducerea consumului de memorie va duce la același crash la următorul spike de trafic. Opțiunile tale sunt: redu pm.max_children la o valoare pe care serverul tău o poate susține efectiv (calculează-o corect conform Fix 3), identifică și elimină pluginurile cu memory leakuri care umflă dimensiunea workerelor individuale, sau upgradează la un plan VPS cu mai mult RAM.

Fix 6: MySQL blochează workere PHP-FPM

Aceasta este cauza cel mai des nediagnosticată a erorilor 502 și este rareori acoperită în ghidurile generale despre WordPress. Când MySQL este supraîncărcat, blocat sau rulează o interogare extrem de lentă, fiecare worker PHP-FPM care face un apel la baza de date se blochează așteptând un răspuns. Deoarece workerele PHP sunt blocate — nu crashate — ele apar ca procese active, iar pm.max_children se umple instant. Cererile noi intră la coadă și expiră, producând un 502. MySQL însuși nu aruncă o eroare vizibilă pentru WordPress până la expirarea timeoutului de conexiune.

systemctl status mysql

# Conectează-te și verifică lista de procese active:
mysql -u root -p -e "SHOW FULL PROCESSLIST;"

# Caută interogări cu o valoare Time mare sau State care arată "Waiting for table lock"
# Termină o interogare blocantă prin ID-ul procesului ei (înlocuiește ID cu numărul real):
mysql -u root -p -e "KILL QUERY ID;"

Dacă MySQL rulează dar processlistul arată zeci de interogări acumulându-se, problema este probabil un index lipsă din baza de date, un job WP-Cron scăpat de sub control care declanșează interogări masive simultane sau un plugin WordPress care efectuează un full table scan la fiecare încărcare de pagină. Ghidul de recuperare a erorii critice WordPress acoperă dezactivarea WP-Cron și izolarea conflictelor de pluginuri la nivel de bază de date.

Fix 7: Fail2Ban blochează traficul de loopback sau IP-urile Cloudflare

Aceasta este o cauză specifică și frustrantă care se prezintă ca un 502 complet normal din perspectiva vizitatorului, dar nu lasă nicio eroare PHP-FPM evidentă în loguri. Fail2ban, un instrument de securitate legitim și important, poate fi configurat greșit astfel încât să baneze accidental 127.0.0.1 (adresa de loopback) sau range-urile IP folosite de Cloudflare ca proxy. Când NGINX încearcă să transmită o cerere către PHP-FPM prin interfața de loopback, este blocat la nivelul firewallului și returnează o eroare de conexiune refuzată.

# Verifică dacă adresa de loopback sau IP-urile Cloudflare sunt banate în prezent:
fail2ban-client status
fail2ban-client status nginx-http-auth

# Verifică regulile iptables active pentru orice DROP pe loopback:
iptables -L -n | grep "127.0.0.1"

# Dacă 127.0.0.1 este banat, debanează-l imediat:
fail2ban-client set JAILNAME unbanip 127.0.0.1

Pentru a preveni reapariția problemei, adaugă adresa de loopback și range-urile IP publicate de Cloudflare în lista ignoreip a fail2ban din /etc/fail2ban/jail.local. Cloudflare publică range-urile sale actuale de IP-uri la https://www.cloudflare.com/ips/. Dacă site-ul tău rulează în spatele Cloudflare și observi erori 502 doar din anumite regiuni geografice, o problemă de rutare pe partea Cloudflare sau un IP de origine expirat în configurația DNS Cloudflare merită verificat înainte de a săpa mai adânc în stackul serverului.

Bonus: Xdebug activ în producție

Xdebug este o extensie PHP de debugging care nu trebuie niciodată încărcată pe un server de producție. Când este activă, adaugă 30 până la 60MB overhead per worker PHP și încetinește semnificativ execuția. Pe un VPS unde în mod normal încap 40 de workere în RAM, Xdebug reduce capacitatea la 15 workere înainte de a epuiza memoria, cauzând direct eroarea 502 din Fix 3. Aceasta este frecventă după ce un dezvoltator testează local, exportă o configurație și aceasta ajunge în producție cu ini-ul Xdebug încă activat.

# Verifică dacă Xdebug este activ:
php -m | grep -i xdebug

# Găsește fișierul de configurare care îl activează:
find /etc/php/8.5/ -name "*.ini" | xargs grep -l "xdebug"

# Dezactivează-l prin comentarea liniei extension:
# Schimbă: zend_extension=xdebug.so
# În:      ;zend_extension=xdebug.so

systemctl reload php8.5-fpm

Checklist rapid de diagnosticare

Dacă ești în mijlocul unui incident și ai nevoie de o secvență structurată, folosește această ordine. Fiecare pas elimină o categorie de cauze înainte de a trece la următoarea.

1. Citește /var/log/nginx/error.log — identifică stringul exact de eroare upstream înainte de a atinge orice fișier.
2. Rulează systemctl status php8.5-fpm — serviciul rulează? Dacă nu, pornește-l și verifică journalctl -xeu php8.5-fpm pentru motivul opririi.
3. Rulează ls /var/run/php/ și compară cu grep fastcgi_pass /etc/nginx/conf.d/virtual/domeniultau.conf — se potrivesc exact?
4. Rulează dmesg | grep -i oom — a fost procesul terminat de kernel?
5. Rulează grep "max_children" /var/log/php8.5-fpm.log — poolul de workere atinge plafonul?
6. Rulează systemctl status mysql și SHOW FULL PROCESSLIST — MySQL este blocat sau supraîncărcat?
7. Rulează iptables -L -n | grep 127.0.0.1 — fail2ban blochează traficul de loopback?
8. Rulează php -m | grep xdebug — o extensie de debugging umflă consumul de memorie?

Dacă parcurgi întregul checklist și eroarea 502 persistă, problema este aproape sigur de natură ambientală: un binar PHP corupt după un update eșuat, un disc plin care împiedică crearea fișierului socket sau o problemă hardware pe nodul fizic. Verifică spațiul pe disc cu df -h și utilizarea inode-urilor cu df -i înainte de a escalada. Dacă serverul este administrat prin planurile noastre de web hosting, deschide un tichet de suport cu outputul logului de erori NGINX atașat — un 502 pe infrastructură managed înseamnă că ceva la nivel de server necesită investigație la nivelul hypervisorului.