502 Bad Gateway: årsager og rettelse

Hvad fejlen betyder

En 502 er et svar fra en server, der virker. Webserveren foran (nginx, Apache, en load balancer eller et CDN som Cloudflare) modtog forespørgslen, sendte den videre til applikationen bag sig (PHP-FPM, en Node.js- eller Python-proces, en backend-server) og fik intet brugbart svar tilbage: forbindelsen blev afvist, afbrudt eller returnerede volapyk. “Gateway” er serveren foran; “bad” er det, der kom tilbage fra bagsiden.

En 502 fortæller dig altså to ting på én gang: forsiden er oppe, og bagsiden er nede eller ødelagt. Det indsnævrer søgningen betydeligt.

Almindelige årsager

1. Applikationsprocessen kører ikke. PHP-FPM gik ned eller blev stoppet, Node.js-processen døde, containeren afsluttede. Forsiden kan slet ikke få forbindelse.
2. Applikationen er overbelastet. Alle PHP-FPM-workers er optaget, køen er fuld, nye forbindelser afvises. Ofte efter en trafikspids eller en langsom databaseforespørgsel, der blokerer hver worker.
3. Forkert socket eller port i konfigurationen. Efter en opdatering eller et skift af PHP-version peger nginx stadig på php8.2-fpm.sock, mens den nye pool lytter på php8.4-fpm.sock.
4. For snævre timeouts. Backenden svarer, men senere, end forsiden vil vente. Nogle opsætninger melder det som 502, andre som 504 Gateway Timeout.
5. Backenden sender en for stor header eller et ugyldigt svar. Typisk for frameworks, der lægger meget i cookies; nginx logger så “upstream sent too big header”.
6. CDN’et kan ikke nå din server. Med Cloudflare foran betyder en 502-side med Cloudflare-logoet, at Cloudflare ikke fik noget fra din origin: firewall, forkert IP efter en flytning, eller serveren er simpelthen nede.

Hvis du er besøgende

Du kan ikke rette en 502 på en andens hjemmeside. Genindlæs én gang efter et minut; hvis den bliver ved, må hjemmesidens ejer handle. For din egen hjemmeside: læs videre.

Hvis det er din hjemmeside: tjek først

Er den nede for alle? Kør tjekket af, om hjemmesiden er nede. Det viser statuskoden udefra og om et CDN eller origin svarede.

Delt hosting eller hjemmesidebygger? En 502 dér er næsten altid hostingudbyderens problem (en overbelastet PHP-pool på en delt node). Spring til beskeden til din hostingudbyder nedenfor.

Din egen server: log ind via SSH, og spørg webserveren, hvad der gik galt.

# nginx: de seneste fejl, nyeste nederst
sudo tail -n 50 /var/log/nginx/error.log

# Apache (Debian/Ubuntu)
sudo tail -n 50 /var/log/apache2/error.log

Typiske linjer og hvad de betyder:

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory): PHP-FPM kører ikke, eller socket-stien er forkert.
• connect() failed (111: Connection refused) while connecting to upstream: backend-porten lytter ikke.
• upstream prematurely closed connection: backend-processen gik ned, mens den svarede, ofte en PHP-fatal fejl eller mangel på hukommelse.
• upstream sent too big header: forøg bufferne (se nedenfor).
• (11: Resource temporarily unavailable): alle PHP-FPM-workers er optaget.

Rettelser på din egen server

1. Start den stoppede tjeneste

# find den PHP-FPM-version, du bruger
systemctl list-units --type=service | grep -E 'php|fpm'

systemctl status php8.3-fpm
sudo systemctl start php8.3-fpm

# Node.js- eller Python-apps styret af systemd
sudo systemctl restart myapp

Nægter tjenesten at starte, står årsagen i journalctl -u php8.3-fpm -n 50. Den hyppigste er en fuld disk (df -h), den næsthyppigste en syntaksfejl i en pool-konfiguration (sudo php-fpm8.3 -t).

2. Ret socket eller port

Sammenlign det, nginx forbinder til, med det, PHP-FPM lytter på:

grep -r fastcgi_pass /etc/nginx/sites-enabled/
grep -r '^listen' /etc/php/*/fpm/pool.d/

De to skal stemme overens. Efter en ændring skal konfigurationen altid testes, før den genindlæses:

sudo nginx -t && sudo systemctl reload nginx

Med Apache og PHP-FPM via mod_proxy_fcgi gælder det samme tjek for linjen SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"; test med sudo apachectl configtest.

3. Giv PHP-FPM plads

Siger fejlloggen, at workers er optaget, eller server reached pm.max_children, så hæv grænsen i pool-filen (/etc/php/8.3/fpm/pool.d/www.conf):

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6

Hver worker kræver hukommelse (ofte 30 til 80 MB for WordPress); tjek free -m, før du hæver tallet, og led efter den langsomme forespørgsel eller det plugin, der holder workers optaget i første omgang.

4. Hæv bufferne til store headers

I nginx’ server-blok:

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
proxy_buffers 8 16k;
proxy_buffer_size 32k;

5. WordPress-særligheder

En 502 lige efter en opdatering af et plugin eller tema betyder som regel, at PHP løber tør for hukommelse eller rammer en fatal fejl ved hver forespørgsel. Omdøb plugin-mappen via SFTP eller SSH for at slå det fra (wp-content/plugins/plugin-name til plugin-name.off), og genindlæs så hjemmesiden. Hæv memory_limit i poolen eller php.ini, hvis journalctl viser “Allowed memory size exhausted”. Hvis du bruger WP-CLI: wp plugin deactivate plugin-name.

6. Bag Cloudflare

Tjek, at origin svarer direkte: curl -I https://YOUR-SERVER-IP -H 'Host: example.com' -k. Virker det, blokerer firewallen på serveren måske Cloudflares adresseintervaller, eller DNS-recorden i Cloudflare peger på en gammel IP.

Når det er din hostingudbyders problem

Hos delt hosting kan du ikke genstarte PHP-FPM. Send din hostingudbyder dette, med tidspunktet og den præcise fejl:

Hej, min hjemmeside example.com returnerer “502 Bad Gateway” siden ca. kl. 14:30 UTC. Et tjek udefra bekræfter det; jeg har ikke ændret noget hos mig. Kan I tjekke PHP-processerne og webserveren på min hostingkonto og give mig besked, når den er tilbage?

Forebyg den næste

En 502 er næsten altid en stoppet eller overbelastet backend, og begge dele kan ses, før besøgende opdager det: en PHP-FPM-tjeneste, der stoppede, hukommelse der løber tør, en disk der fyldes op. Servermonitorering med agenten melder netop dette indefra serveren, og hjemmesidetjek udefra fanger 502’en i det øjeblik, den opstår. På din egen server kan en Quick Fix genstarte den stoppede tjeneste, når dens konfigurationstest er bestået; ligger årsagen dybere, tager en Deep Fix over døgnet rundt.