ses på hjemmesider 502 Dårlig gateway og 504 Gateway timeout fejl opstår normalt, fordi webserveren ikke får det korrekte svar fra back-end-tjenesten. Denne service kan være PHP-FPM, Apache backend, Node.js applikation, game panel API service eller en anden applikation bag proxyen.

Disse fejl er især almindelige i hosting, spilpanel, WHMCS, Pterodactyl, brugerdefineret administrationspanel og webbaserede launcher-systemer.

1. Forskel mellem 502 og 504 fejl

• 502 Bad Gateway: Webserveren kan ikke oprette forbindelse til backend-tjenesten eller modtager et forvansket svar.
• 504 Gateway Timeout: Backend-tjenesten ser ud til at reagere, men svaret returneres ikke i tide.

Så 502 er mere en forbindelse/servicenedbrud, og 504 er et langsommeligheds- eller timeoutproblem.

2. Kontrol af servicestatusser

Først skal du kontrollere, om webserveren og PHP-tjenesterne kører.

systemctl status nginx
systemctl status apache2
systemctl status php-fpm

På CentOS, AlmaLinux eller Rocky Linux-systemer kan PHP-FPM-tjenesten hedde:

systemctl status php-fpm
systemctl status httpd

Hvis tjenesten er stoppet, genstart den:

systemctl restart nginx
systemctl restart php-fpm

3. Gennemgang af logfiler

Det er ikke korrekt at fortsætte med gætværk for 502 og 504 fejl. Logfilen viser den egentlige årsag til fejlen.

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

På CentOS-baserede systemer:

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

Følgende udsagn kan ses i loggene:

• connect() mislykkedes: Kan ikke oprette forbindelse til backend-tjenesten.
• upstream timeout: Backend-tjenesten svarer sent.
• forbindelse nægtet: Tjenesten er nede, eller der er viderestilling til den forkerte port.
• tilladelse nægtet: Der er et socket- eller filtilladelsesproblem.

4. PHP-FPM-socket eller portkontrol

Nginx opretter forbindelse til PHP-FPM via socket eller port. PHP-FPM-stien i Nginx-konfigurationsfilen og den faktiske PHP-FPM-lytteværdi skal være den samme.

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

For eksempel hvis Nginx bruger:

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

Den samme socket skal lyttes til på PHP-FPM-siden:

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

5. Forøgelse af timeout-indstillinger

504-fejl kan modtages i store behandlingspaneler, spillemarkeder, API'er eller langsomt kørende PHP-scripts. Nginx timeout værdier kan øges.

nano /etc/nginx/nginx.conf

Følgende værdier kan tilføjes til http-blokken eller den relevante serverblok:

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

Test indstillingerne og genstart Nginx:

nginx -t
systemctl restart nginx

6. Kontrol af PHP-FPM-procesgrænser

Når trafikken stiger, kan grænserne for PHP-FPM-transaktioner være utilstrækkelige. I dette tilfælde sættes anmodninger i kø, og der opstår en timeout.

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

Eksempelindstillinger:

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

Disse værdier bør justeres i henhold til mængden af RAM på serveren. Indstilling af en for høj værdi øger RAM-forbruget.

Almindelige fejl

• Ændring af indstillinger uden at se på logfilen
• Opdaterer ikke Nginx-socketstien, selvom PHP-versionen er ændret
• Ikke at rette den faktiske langsomme forespørgsel ved at øge timeout
• Forøgelse af PHP-FPM-grænser uden beregning af RAM
• Genstart af tjenesten uden at teste Nginx config

FAQ

Er 502 fejl altid forårsaget af Nginx?
Nej. Nginx er kun den, der viser fejlen. Det virkelige problem kan være i PHP-FPM, Apache-backend, Node.js-applikation eller en anden tjeneste.

Er øget timeout den endelige løsning for 504-fejl?
Ikke altid. Øget timeout giver midlertidig lindring. Den rigtige løsning er at finde den langsomme forespørgsel, tunge behandling eller ydeevneproblem.

Er det sikkert at genstarte PHP-FPM?
Det er generelt sikkert, men aktive anmodninger kan blive påvirket i kort tid. I travle systemer bør timer med lav trafik foretrækkes.

Præstationsanbefalinger

• Kontroller PHP-FPM-versionen og socketstien regelmæssigt.
• Undersøg langsomme forespørgselslogfiler i webpanel og API-tjenester.
• Hvis RAM er utilstrækkelig, skal du ikke øge PHP-FPM max_children værdien ubevidst.
• Reducer backend-belastningen ved at bruge et cache-system.
• Administrer fejllogfiler, før de vokser med logrotate.

Denne artikel er specielt forberedt til PvPServer.