502 Bad Gateway: orsaker och hur du åtgärdar det

Vad felet betyder

Ett 502 är ett svar från en server som fungerar. Webbservern framför (nginx, Apache, en lastbalanserare eller ett CDN som Cloudflare) tog emot förfrågan, skickade den vidare till applikationen bakom sig (PHP-FPM, en Node.js- eller Python-process, en backend-server) och fick inget användbart svar tillbaka: anslutningen vägrades, bröts eller gav skräp. ”Gateway” är servern framför; ”bad” är det som kom tillbaka bakifrån.

Ett 502 berättar alltså två saker på en gång: framsidan är uppe, och baksidan är nere eller trasig. Det snävar in sökandet avsevärt.

Vanliga orsaker

1. Applikationsprocessen körs inte. PHP-FPM kraschade eller stoppades, Node.js-processen dog, containern avslutades. Framsidan kan inte ansluta alls.
2. Applikationen är överbelastad. Alla PHP-FPM-arbetare är upptagna, kön är full, nya anslutningar vägras. Ofta efter en trafiktopp eller en långsam databasfråga som blockerar alla arbetare.
3. Fel socket eller port i konfigurationen. Efter en uppdatering eller ett byte av PHP-version pekar nginx fortfarande på php8.2-fpm.sock medan den nya poolen lyssnar på php8.4-fpm.sock.
4. För snäva tidsgränser. Backend svarar, men senare än framsidan vill vänta. Vissa konfigurationer rapporterar detta som 502, andra som 504 Gateway Timeout.
5. Backend skickar en för stor rubrik eller ett ogiltigt svar. Typiskt för ramverk som lägger mycket i cookies; nginx loggar då ”upstream sent too big header”.
6. CDN:et når inte din server. Med Cloudflare framför betyder en 502-sida med Cloudflare-logotypen att Cloudflare inte fick något från din origin: brandvägg, fel IP efter en flytt, eller att servern helt enkelt ligger nere.

Om du är besökare

Du kan inte åtgärda ett 502 på någon annans hemsida. Ladda om en gång efter en minut; om det kvarstår måste hemsidans ägare agera. För din egen hemsida, läs vidare.

Om det är din hemsida: kontrollera först

Ligger den nere för alla? Kör kontrollen av om hemsidan ligger nere. Den visar statuskoden utifrån och om ett CDN eller origin svarade.

Delat webbhotell eller webbplatsbygge? Ett 502 där är nästan alltid webbhotellets problem (en överbelastad PHP-pool på en delad nod). Hoppa till meddelandet till ditt webbhotell nedan.

Din egen server: logga in via SSH och fråga webbservern vad som gick fel.

# nginx: de senaste felen, nyaste längst ned
sudo tail -n 50 /var/log/nginx/error.log

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

Typiska rader och vad de betyder:

• connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory): PHP-FPM körs inte, eller så är socketsökvägen fel.
• connect() failed (111: Connection refused) while connecting to upstream: backend-porten lyssnar inte.
• upstream prematurely closed connection: backend-processen kraschade medan den svarade, ofta ett PHP-fatalfel eller slut på minne.
• upstream sent too big header: öka buffertarna (se nedan).
• (11: Resource temporarily unavailable): alla PHP-FPM-arbetare är upptagna.

Åtgärder på din egen server

1. Starta den stoppade tjänsten

# hitta PHP-FPM-versionen du använder
systemctl list-units --type=service | grep -E 'php|fpm'

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

# Node.js- eller Python-appar som hanteras av systemd
sudo systemctl restart myapp

Om tjänsten vägrar starta står orsaken i journalctl -u php8.3-fpm -n 50. Den vanligaste är en full disk (df -h), den näst vanligaste ett syntaxfel i en poolkonfiguration (sudo php-fpm8.3 -t).

2. Rätta socketen eller porten

Jämför vad nginx ansluter till med vad PHP-FPM lyssnar på:

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

De två måste stämma överens. Efter en ändring: testa alltid konfigurationen innan du laddar om:

sudo nginx -t && sudo systemctl reload nginx

Med Apache och PHP-FPM via mod_proxy_fcgi gäller samma kontroll raden SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"; testa med sudo apachectl configtest.

3. Ge PHP-FPM utrymme

Om felloggen säger att arbetare är upptagna eller server reached pm.max_children, höj gränsen i poolfilen (/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

Varje arbetare behöver minne (ofta 30 till 80 MB för WordPress); kontrollera free -m innan du höjer talet, och leta efter den långsamma frågan eller det plugin som håller arbetarna upptagna från första början.

4. Höj buffertarna för stora rubriker

I nginx server-blocket:

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

5. Särskilt för WordPress

Ett 502 direkt efter en plugin- eller temauppdatering betyder oftast att PHP får slut på minne eller drabbas av ett fatalfel vid varje förfrågan. Byt namn på pluginmappen via SFTP eller SSH för att stänga av det (wp-content/plugins/plugin-name till plugin-name.off) och ladda sedan om hemsidan. Höj memory_limit i poolen eller php.ini om journalctl visar ”Allowed memory size exhausted”. Om du använder WP-CLI: wp plugin deactivate plugin-name.

6. Bakom Cloudflare

Kontrollera att origin svarar direkt: curl -I https://YOUR-SERVER-IP -H 'Host: example.com' -k. Om det fungerar kan brandväggen på servern blockera Cloudflares adressintervall, eller så pekar DNS-posten i Cloudflare på en gammal IP.

När det är ditt webbhotells problem

På ett delat webbhotell kan du inte starta om PHP-FPM. Skicka det här till ditt webbhotell, med tiden och det exakta felet:

Hej, min hemsida example.com returnerar ”502 Bad Gateway” sedan ungefär 14:30 UTC. En kontroll utifrån bekräftar det; jag har inte ändrat något på min sida. Kan ni kontrollera PHP-processerna och webbservern på mitt webbhotellskonto och höra av er när det är tillbaka?

Förhindra nästa

Ett 502 är nästan alltid en stoppad eller överbelastad backend, och båda syns innan besökarna märker det: en PHP-FPM-tjänst som stoppat, minne som tar slut, en disk som fylls. Serverövervakning med agenten rapporterar precis detta inifrån servern, och hemsidekontroller utifrån fångar 502 i samma ögonblick som det uppstår. På din egen server kan en Quick Fix starta om den stoppade tjänsten efter att dess konfigurationstest har godkänts; om orsaken ligger djupare tar en Deep Fix över dygnet runt.