Ett 502 Bad Gateway-fel betyder att en server som fungerar som gateway eller proxy fick ett ogiltigt svar från servern bakom den. Besökaren nådde något, oftast nginx, Apache, en lastbalanserare eller ett CDN, men det lagret kunde inte få ett korrekt svar från din applikation. Applikationen kraschade, startar om, lyssnar någon annanstans eller stängde anslutningen mitt i.
Det gör en 502 till ett besked om två servrar, inte en. Den här guiden visar hur du ser vilket lager som returnerade felet, hur du åtgärdar de vanliga orsakerna och hur du får veta om nästa 502 innan dina kunder gör det.
Vad en 502 berättar
De flesta webbplatser har minst två lager mellan besökaren och koden. Ett CDN eller en lastbalanserare sitter längst fram, en webbserver som nginx tar emot anslutningen och en applikationsprocess, till exempel PHP-FPM, Node.js, Gunicorn eller en Java-server, bygger sidan. Varje lager skickar förfrågan vidare till nästa och skickar tillbaka svaret.
En 502 uppstår när ett av lagren skickar vidare en förfrågan och inte får tillbaka något användbart. Jämför med de andra gateway-felen:
502 Bad Gateway: uppströmsservern svarade med något ogiltigt, återställde anslutningen eller nekade den.
503 Service Unavailable: tjänsten är överbelastad, under underhåll eller har ingen frisk server att skicka förfrågan till.
504 Gateway Timeout: uppströmsservern svarade inte i tid.
En 502 betyder alltså oftast trasig eller inte igång, en 504 oftast långsam. Vår fusklapp över HTTP-statuskoder listar resten av familjen, och guiden om 503-fel tar upp överbelastning och underhåll.
Hitta lagret som returnerade 502-felet
Innan du ändrar något, ta reda på vem som svarade. Felsidan och svarshuvudena säger det oftast rakt ut:
curl -sI https://www.example.com/checkout
HTTP/2 502
server: cloudflare
cf-ray: 8d2f1c3a5b7e4a21-ARN
server: cloudflare med en felsida från Cloudflare som anger din värd: Cloudflare nådde din origin-server, och den fallerade.
server: nginx eller Apache med en enkel felsida: din egen webbserver kunde inte nå applikationen bakom den.
server: awselb/2.0 eller en annan lastbalanserare: lastbalanseraren fick inget giltigt svar från något mål, eller från det den valde.
Jämför sedan med en förfrågan som hoppar över det yttre lagret. Skicka den direkt till origin-servern eller till applikationens port på själva servern:
curl -sI –resolve www.example.com:443:203.0.113.10 https://www.example.com/checkout
curl -sI http://127.0.0.1:3000/checkout
Om applikationen svarar lokalt men inte via proxyn, titta på proxyns konfiguration. Om den inte svarar lokalt heller är det applikationen som är problemet.
Vanliga orsaker och hur du åtgärdar dem
Applikationsprocessen har kraschat eller startar om
Den vanligaste orsaken. Processen bakom proxyn fick slut på minne, stötte på ett ohanterat undantag eller dödades, och proxyn har inget att prata med. nginx loggar det tydligt:
connect() failed (111: Connection refused) while connecting to upstream,
upstream: ”http://127.0.0.1:3000/checkout”
Kontrollera om processen körs och varför den stannade:
systemctl status myapp
journalctl -u myapp –since ”30 min ago”
dmesg -T | grep -i ”killed process”
En rad från kärnans OOM killer betyder att servern fick slut på minne. En omstart får upp sajten igen, men den verkliga lösningen är mer minne, färre workers eller en minnesläcka som hittas och täpps till. Se till att tjänsten startar om av sig själv efter en krasch, till exempel med Restart=on-failure i dess systemd-enhet.
PHP-FPM ligger nere eller har slut på workers
På PHP-sajter skickar nginx förfrågningar till PHP-FPM via en socket eller port. Om PHP-FPM är stoppat, sökvägen till socketen är fel eller socketens behörigheter stänger ute nginx, svarar varje PHP-sida med 502:
connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)
Det meddelandet kommer oftast efter en PHP-uppgradering: nginx pekar fortfarande på den gamla versionens socket. Peka fastcgi_pass på den nya socketen och ladda om nginx. Om loggen i stället säger server reached pm.max_children är alla workers upptagna, ofta i väntan på en långsam databas eller ett externt API. Höj gränsen bara om servern har minne över; annars, ta reda på vad som håller workerna upptagna.
Fel uppströmsadress eller port
Efter en migrering, en ombyggd container eller en ändrad port kan proxyn fortfarande skicka vidare till den gamla adressen. Felloggen visar adressen den försökte nå. Jämför med var applikationen faktiskt lyssnar:
ss -ltnp | grep -E ’:(3000|8000|9000)’
I Docker och Kubernetes är orsaken ofta ett tjänstnamn som inte längre går att slå upp, en container som lyssnar på 127.0.0.1 inuti containern i stället för 0.0.0.0, eller en readiness-kontroll som markerar varje pod som inte redo.
Uppströmsservern stängde anslutningen för tidigt
upstream prematurely closed connection while reading response header betyder att applikationen tog emot förfrågan och sedan lade på. Typiska orsaker är en krasch mitt i förfrågan, en worker som dödades för att den överskred sin egen tidsgräns, som Gunicorns –timeout eller PHP:s max_execution_time, och keep-alive-anslutningar som applikationen stänger tidigare än proxyn förväntar sig. Anpassa tidsgränserna så att proxyn väntar lite längre än applikationen, aldrig tvärtom, och titta på vilka förfrågningar som är tillräckligt långsamma för att nå gränsen.
För stora svarshuvuden
Stora cookies eller många Set-Cookie-huvuden kan bli större än nginx buffert för uppströmsserverns svarshuvuden. nginx loggar då upstream sent too big header while reading response header from upstream och returnerar 502. Höj buffertarna försiktigt:
proxy_buffer_size 16k;
proxy_buffers 8 16k;
# for PHP-FPM
fastcgi_buffer_size 32k;
fastcgi_buffers 8 16k;
Ta sedan reda på varför huvudena växte. En cookie som växer vid varje besök är en bugg värd att rätta.
CDN:et kan inte prata med din origin-server
När ett CDN eller en lastbalanserare returnerar 502, kontrollera vad som sitter mellan den och din server. En brandvägg som blockerar CDN:ets adressintervall, ett origin-certifikat som CDN:et inte godtar, en origin-server som bara talar HTTP/1.0 eller stänger anslutningar för snabbt, eller en DNS-post som pekar på en gammal server slutar alla på samma sätt. Testa origin-servern direkt, som ovan, och kontrollera brandväggen och TLS-inställningarna på båda sidor.
502-fel vid deployer
Om 502-fel dyker upp i tio eller tjugo sekunder åt gången och alltid kring en release är det deployen själv som orsakar dem. Den gamla processen stannar, den nya tar några sekunder att starta och varje förfrågan däremellan fallerar. Lösningen är en releaseordning där något alltid är redo att svara:
Starta den nya versionen bredvid den gamla.
Vänta tills dess hälsokontroll går igenom. Vår guide om att bygga en endpoint för hälsokontroller visar vad kontrollen ska testa.
Flytta över trafiken till den nya versionen.
Låt den gamla versionen avsluta förfrågningarna den har och stoppa den sedan.
Processhanterare och orkestrerare stöder detta som rullande omladdningar eller omladdningar utan nertid. Använd dem i stället för en vanlig omstart.
Så fångar övervakning 502-fel
En 502 är ofta kortvarig. En deploy ger tjugo sekunder av fel, en worker kraschar och startar om, en cache döljer problemet för de flesta besökare. När någon öppnar sajten fungerar den igen, men en kund mitt i ett köp såg felet.
En upptidsövervakare hämtar dina sidor enligt ett schema och registrerar statuskod och svarstid för varje kontroll. En 502 är en misslyckad kontroll. Det som spelar roll är vad som händer sedan:
Bekräfta felet. En enda misslyckad förfrågan kan vara en tillfällig blipp. Uptimecheck kontrollerar så ofta som varje minut från Stockholm, London och New York och bekräftar varje fel från en andra plats innan en incident öppnas, så att en enstaka återställd anslutning inte väcker någon.
Visa bevisen. Incidenten innehåller svaret som fallerade, så att du ser statuskoden, server-huvudet och felsidan, och en skärmbild av vad besökarna såg. När servern inte svarade alls får du nätverksvägen i stället.
Nå rätt personer. Larmen går till e-post, Slack, Microsoft Teams, PagerDuty, webhooks och de andra larmkanalerna ditt team använder.
Bevaka mer än startsidan. Startsidan cachas ofta av ett CDN och fortsätter fungera medan kassan, inloggningen och API:et returnerar 502. Lägg till upptidsövervakare för sidorna som drar in pengar och API-övervakare för endpoints som dina appar anropar. När 502-felet kommer från en applikation som fick slut på minne visar serverövervakning minneskurvan bredvid avbrottet.
Checklista för 502-fel
Läs server-huvudet och felsidan för att se vilket lager som returnerade 502-felet.
Anropa origin-servern och applikationens port direkt för att ringa in felet.
Läs proxyns fellogg för samma tidsstämpel: nekad, stängd för tidigt eller för stort huvud.
Kontrollera att applikationsprocessen körs, och varför den stannade om den inte gör det.
Jämför uppströmsadress, socket och port med var applikationen lyssnar.
Anpassa tidsgränserna så att proxyn väntar längre än applikationen.
Deploya genom att starta den nya versionen innan du stoppar den gamla.
Övervaka viktiga sidor och endpoints varje minut och bekräfta varje fel innan du larmar.