Eroare 502 Bad Gateway pe Nginx: cum verifici aplicația din spatele proxy-ului

O eroare 502 Bad Gateway apare când un intermediar nu primește un răspuns valid de la serviciul către care transmite cererea. Pe o configurație Nginx cu proxy invers, acel serviciu poate fi o aplicație Node.js sau alt server HTTP. Identificarea componentei care emite eroarea este primul pas.

Delimitează traseul cererii

Notează domeniul, adresa exactă, ora și frecvența problemei. Stabilește dacă există un CDN sau alt proxy înainte de Nginx. Aspectul paginii nu este o dovadă suficientă: corelează răspunsul cu logurile și configurația pentru domeniul afectat.

Verifică dacă eroarea apare pe toate paginile sau numai la o operațiune. Un import poate folosi altă rută ori alt serviciu decât pagina principală. Nu modifica întreaga infrastructură pornind de la o singură cerere.

Confirmă că aplicația funcționează

Verifică starea procesului prin mecanismul care îl administrează: systemd, manager de procese sau orchestrator. Controlează apoi portul ori socketul din configurația Nginx. O aplicație pornită pe alt port nu devine accesibilă doar pentru că procesul există.

Pentru un backend HTTP local care oferă deja o rută de verificare, un test orientativ este:

curl --max-time 10 --show-error http://127.0.0.1:3000/health

Adaptează adresa și ruta. Comanda nu este potrivită pentru un socket FastCGI și nu verifică automat toate funcțiile aplicației. Dacă serviciul cere un anumit antet Host, reproduce și acea condiție în test.

Citește eroarea precisă din log

În logul Nginx pentru intervalul notat, caută indicii despre refuzul conexiunii, închiderea prematură a acesteia sau un răspuns nevalid. Verifică în paralel logurile aplicației. O oprire a lucrătorului în același moment poate explica eroarea mai bine decât încărcarea generală a VPS-ului.

La socketuri locale, controlează calea, proprietarul și drepturile de acces ale procesului Nginx. Nu aplica permisiuni globale de scriere pentru a elimina rapid mesajul. Stabilește ce utilizatori trebuie să comunice și acordă accesul necesar acelui traseu.

Verifică protocolul și configurația activă

Un backend HTTP și unul HTTPS necesită configurări corespunzătoare. Pentru PHP-FPM se folosește interfața FastCGI, nu o cerere HTTP obișnuită. Confirmă și faptul că modificarea aparține blocului server potrivit.

sudo nginx -t

Validarea sintaxei ajută înainte de reîncărcare, dar nu demonstrează conectivitatea către aplicație. Creșterea limitelor de timp sau a bufferelor trebuie justificată de eroarea observată. Altfel poate doar să ascundă temporar cauza.

Testează după corecție

Repetă operațiunea care producea eroarea și urmărește stabilitatea pe un interval reprezentativ. Dacă problema a apărut după o publicare, compară porturile, căile și variabilele modificate. Păstrează o procedură de revenire la configurația validată.

Pentru un serviciu găzduit prin XSERVERE, trimite suportului intervalul, ruta afectată și fragmentele relevante fără secrete. Pe un VPS administrat de client, verificarea aplicației și a proxy-ului trebuie inclusă în aceeași intervenție.

Surse

• Nginx — HTTP proxy module — https://nginx.org/en/docs/http/ngx_http_proxy_module.html
• Nginx — FastCGI module — https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html
• curl — manual — https://curl.se/docs/manpage.html