502 Bad Gateway: årsaker og hvordan du fikser det

Hva feilen betyr

En 502 er et svar fra en server som fungerer. Webserveren foran (nginx, Apache, en lastbalanserer eller et CDN som Cloudflare) mottok forespørselen, sendte den videre til applikasjonen bak seg (PHP-FPM, en Node.js- eller Python-prosess, en backend-server) og fikk ikke noe brukbart svar tilbake: tilkoblingen ble avvist, brutt eller ga søppel. «Gateway» er serveren foran; «bad» er det som kom tilbake fra baksiden.

En 502 forteller deg altså to ting samtidig: fronten er oppe, og baksiden er nede eller ødelagt. Det innsnevrer søket betydelig.

Vanlige årsaker

1. Applikasjonsprosessen kjører ikke. PHP-FPM krasjet eller ble stoppet, Node.js-prosessen døde, containeren avsluttet. Fronten kan ikke koble til i det hele tatt.
2. Applikasjonen er overbelastet. Alle PHP-FPM-arbeiderne er opptatt, køen er full, nye tilkoblinger avvises. Ofte etter en trafikktopp eller en treg databasespørring som blokkerer hver arbeider.
3. Feil socket eller port i konfigurasjonen. Etter en oppdatering eller en bytte av PHP-versjon peker nginx fortsatt på php8.2-fpm.sock mens den nye poolen lytter på php8.4-fpm.sock.
4. For stramme tidsavbrudd. Backend svarer, men senere enn fronten er villig til å vente. Noen oppsett melder dette som 502, andre som 504 Gateway Timeout.
5. Backend sender en for stor header eller et ugyldig svar. Typisk for rammeverk som legger mye i informasjonskapsler; nginx logger da «upstream sent too big header».
6. CDN-et når ikke serveren din. Med Cloudflare foran betyr en 502-side med Cloudflare-logoen at Cloudflare ikke fikk noe fra opprinnelsesserveren din: brannmur, feil IP etter en flytting, eller serveren er rett og slett nede.

Hvis du er besøkende

Du kan ikke fikse en 502 på andres nettside. Last på nytt én gang etter et minutt; vedvarer den, må eieren av nettsiden gjøre noe. For din egen nettside, les videre.

Hvis det er din nettside: sjekk først

Er den nede for alle? Kjør nettside-nede-sjekken. Den viser statuskoden utenfra og om et CDN eller opprinnelsesserveren svarte.

Delt hosting eller nettstedsbygger? En 502 der er nesten alltid hosting-leverandørens problem (en overbelastet PHP-pool på en delt node). Hopp til meldingen til hosting-leverandøren din nedenfor.

Din egen server: logg inn via SSH og spør webserveren hva som gikk galt.

# nginx: de siste feilene, 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 hva de betyr:

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory): PHP-FPM kjører ikke, eller socket-stien er feil.
• connect() failed (111: Connection refused) while connecting to upstream: backend-porten lytter ikke.
• upstream prematurely closed connection: backend-prosessen krasjet mens den svarte, ofte en fatal PHP-feil eller tomt for minne.
• upstream sent too big header: øk bufferne (se nedenfor).
• (11: Resource temporarily unavailable): alle PHP-FPM-arbeiderne er opptatt.

Løsninger på din egen server

1. Start den stoppede tjenesten

# finn PHP-FPM-versjonen du bruker
systemctl list-units --type=service | grep -E 'php|fpm'

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

# Node.js- eller Python-apper som styres av systemd
sudo systemctl restart myapp

Nekter tjenesten å starte, står årsaken i journalctl -u php8.3-fpm -n 50. Den vanligste er en full disk (df -h), den nest vanligste en syntaksfeil i en pool-konfigurasjon (sudo php-fpm8.3 -t).

2. Rett socket eller port

Sammenlign hva nginx kobler til med hva PHP-FPM lytter på:

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

De to må stemme overens. Etter en endring tester du alltid konfigurasjonen før du laster på nytt:

sudo nginx -t && sudo systemctl reload nginx

Med Apache og PHP-FPM via mod_proxy_fcgi gjelder den samme kontrollen linjen SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"; test med sudo apachectl configtest.

3. Gi PHP-FPM plass

Sier feilloggen at arbeiderne er opptatt eller server reached pm.max_children, øk grensen 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 arbeider trenger minne (ofte 30 til 80 MB for WordPress); sjekk free -m før du øker tallet, og let etter den trege spørringen eller pluginen som holder arbeiderne opptatt i utgangspunktet.

4. Øk bufferne for store headere

I nginx server-blokken:

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

5. WordPress-spesifikt

En 502 rett etter en plugin- eller temaoppdatering betyr vanligvis at PHP går tom for minne eller treffer en fatal feil ved hver forespørsel. Gi plugin-mappen et nytt navn via SFTP eller SSH for å slå den av (wp-content/plugins/plugin-name til plugin-name.off), og last deretter nettsiden på nytt. Øk memory_limit i poolen eller php.ini hvis journalctl viser «Allowed memory size exhausted». Bruker du WP-CLI: wp plugin deactivate plugin-name.

6. Bak Cloudflare

Sjekk at opprinnelsesserveren svarer direkte: curl -I https://YOUR-SERVER-IP -H 'Host: example.com' -k. Fungerer det, kan brannmuren på serveren blokkere Cloudflares adresseområder, eller DNS-posten i Cloudflare peker på en gammel IP.

Når det er hosting-leverandørens problem

På delt hosting kan du ikke starte PHP-FPM på nytt. Send hosting-leverandøren din dette, med tidspunktet og den nøyaktige feilen:

Hei, nettsiden min example.com returnerer «502 Bad Gateway» siden omtrent 14:30 UTC. En sjekk utenfra bekrefter det; jeg har ikke endret noe hos meg. Kan dere sjekke PHP-prosessene og webserveren på hostingkontoen min og si fra når det er oppe igjen?

Forhindre neste gang

En 502 er nesten alltid en stoppet eller overbelastet backend, og begge deler er synlige før de besøkende merker det: en PHP-FPM-tjeneste som stoppet, minne som går tomt, en disk som fylles opp. Serverovervåking med agenten rapporterer akkurat dette fra innsiden av serveren, og nettsidesjekker utenfra fanger 502 i det øyeblikket den dukker opp. På din egen server kan en Quick Fix starte den stoppede tjenesten på nytt etter at konfigurasjonstesten er bestått; ligger årsaken dypere, tar en Deep Fix over døgnet rundt.