gezien op websites 502 Slechte gateway en 504 Gateway-time-out fouten treden meestal op omdat de webserver niet het juiste antwoord krijgt van de back-endservice. Deze service kan PHP-FPM, Apache backend, Node.js-applicatie, gamepanel-API-service of een andere applicatie achter de proxy zijn.

Deze fouten komen vooral veel voor bij hosting, gamepaneel, WHMCS, Pterodactyl, aangepast beheerpaneel en webgebaseerde opstartsystemen.

1. Verschil tussen 502- en 504-fout

• 502 Slechte gateway: De webserver kan geen verbinding maken met de backend-service of ontvangt een onleesbaar antwoord.
• 504 Gateway-time-out: De backend-service lijkt te reageren, maar het antwoord wordt niet op tijd geretourneerd.

502 is dus meer een verbindings-/servicecrash, en 504 is een traagheids- of time-outprobleem.

2. Servicestatussen controleren

Controleer eerst of de webserver en PHP-services actief zijn.

systemctl status nginx
systemctl status apache2
systemctl status php-fpm

Op CentOS-, AlmaLinux- of Rocky Linux-systemen kan de PHP-FPM-service de volgende naam hebben:

systemctl status php-fpm
systemctl status httpd

Als de service is gestopt, start u deze opnieuw:

systemctl restart nginx
systemctl restart php-fpm

3. Logbestanden bekijken

Het is niet juist om door te gaan met giswerk voor 502- en 504-fouten. Het logbestand toont de werkelijke oorzaak van de fout.

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

Op CentOS-gebaseerde systemen:

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

In de logboeken zijn de volgende uitspraken te zien:

• connect() mislukt: Kan geen verbinding maken met de backend-service.
• upstream time-out: Backend-service reageert laat.
• verbinding geweigerd: De service is uitgevallen of er wordt doorgestuurd naar de verkeerde poort.
• toestemming geweigerd: Er is een probleem met de socket- of bestandsrechten.

4. PHP-FPM-socket- of poortcontrole

Nginx maakt verbinding met PHP-FPM via socket of poort. Het PHP-FPM-pad in het Nginx-configuratiebestand en de werkelijke PHP-FPM-luisterwaarde moeten hetzelfde zijn.

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

Als Nginx bijvoorbeeld gebruikt:

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

Aan de PHP-FPM-kant moet naar dezelfde socket worden geluisterd:

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

5. Time-outinstellingen verhogen

504-fouten kunnen worden ontvangen in grote verwerkingspanelen, speelmarkten, API's of langzaam werkende PHP-scripts. Nginx-time-outwaarden kunnen worden verhoogd.

nano /etc/nginx/nginx.conf

Aan het http-blok of het betreffende serverblok kunnen de volgende waarden worden toegevoegd:

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

Test de instellingen en start Nginx opnieuw:

nginx -t
systemctl restart nginx

6. PHP-FPM-proceslimieten controleren

Wanneer het verkeer toeneemt, zijn de PHP-FPM-transactielimieten mogelijk onvoldoende. In dit geval worden aanvragen in de wachtrij geplaatst en treedt er een time-out op.

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

Voorbeeld instellingen:

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

Deze waarden moeten worden aangepast aan de hoeveelheid RAM van de server. Als u een te hoge waarde instelt, neemt het RAM-verbruik toe.

Veelvoorkomende fouten

• Instellingen wijzigen zonder naar het logbestand te kijken
• Het Nginx-socketpad wordt niet bijgewerkt, ook al is de PHP-versie gewijzigd
• De daadwerkelijke langzame vraag wordt niet opgelost door de time-out te verlengen
• PHP-FPM-limieten verhogen zonder RAM te berekenen
• De service opnieuw starten zonder de Nginx-configuratie te testen

Veelgestelde vragen

Wordt de 502-fout altijd veroorzaakt door Nginx?
Nee. Nginx is degene die de fout vertoont. Het echte probleem kan zich in PHP-FPM, Apache backend, Node.js-applicatie of een andere service bevinden.

Is het verhogen van de time-out de definitieve oplossing voor 504-fouten?
Niet altijd. Het verlengen van de time-out biedt tijdelijke verlichting. De echte oplossing is het vinden van het trage query-, zware verwerkings- of prestatieprobleem.

Is het veilig om PHP-FPM opnieuw te starten?
Het is over het algemeen veilig, maar actieve verzoeken kunnen voor korte tijd worden beïnvloed. In drukke systemen verdienen uren met weinig verkeer de voorkeur.

Prestatieaanbevelingen

• Controleer regelmatig de PHP-FPM-versie en het socketpad.
• Onderzoek langzame querylogboeken in het webpaneel en API-services.
• Als het RAM-geheugen onvoldoende is, verhoog dan niet onbewust de waarde PHP-FPM max_children.
• Verminder de backend-belasting door een cachesysteem te gebruiken.
• Beheer foutenlogboeken voordat ze groeien met logrotate.

Dit artikel is speciaal opgesteld voor PvPServer.