En 502 Bad Gateway-feil betyr at en server som fungerer som gateway eller proxy, fikk et ugyldig svar fra serveren bak seg. Den besøkende nådde noe, som regel nginx, Apache, en lastbalanserer eller et CDN, men det laget fikk ikke et skikkelig svar fra applikasjonen din. Applikasjonen har krasjet, starter på nytt, lytter et annet sted eller lukket tilkoblingen midt i forespørselen.
Det gjør en 502 til en melding om to servere, ikke én. Denne guiden viser hvordan du finner ut hvilket lag som returnerte den, hvordan du løser de vanlige årsakene, og hvordan du får vite om neste 502 før kundene gjør det.
Hva en 502 forteller deg
De fleste nettsteder har minst to lag mellom den besøkende og koden. Et CDN eller en lastbalanserer ligger foran, en webserver som nginx tar imot tilkoblingen, og en applikasjonsprosess, for eksempel PHP-FPM, Node.js, Gunicorn eller en Java-server, bygger siden. Hvert lag sender forespørselen videre til det neste og sender svaret tilbake.
En 502 oppstår når ett av disse lagene sender en forespørsel videre og ikke får noe brukbart tilbake. Sammenlign den med de andre gateway-feilene:
502 Bad Gateway: upstream-serveren svarte med noe ugyldig, tilbakestilte tilkoblingen eller avviste den.
503 Service Unavailable: tjenesten er overbelastet, under vedlikehold eller har ingen frisk server å sende forespørselen til.
504 Gateway Timeout: upstream-serveren svarte ikke i tide.
En 502 betyr altså som regel ødelagt eller ikke i gang, mens en 504 som regel betyr tregt. Juksearket vårt over HTTP-statuskoder viser resten av familien, og guiden om 503-feil tar for seg overbelastning og vedlikehold.
Finn laget som returnerte 502-feilen
Før du endrer noe, må du finne ut hvem som svarte. Feilsiden og svarheaderne sier det som regel rett ut:
curl -sI https://www.example.com/checkout
HTTP/2 502
server: cloudflare
cf-ray: 8d2f1c3a5b7e4a21-ARN
server: cloudflare med en feilside fra Cloudflare som nevner verten din: Cloudflare nådde origin-serveren din, og det var den som feilet.
server: nginx eller Apache med en enkel feilside: din egen webserver nådde ikke applikasjonen bak seg.
server: awselb/2.0 eller en annen lastbalanserer: lastbalansereren fikk ikke et gyldig svar fra noe mål, eller fra det den valgte.
Sammenlign deretter med en forespørsel som hopper over det ytterste laget. Send den rett til origin-serveren eller til applikasjonsporten på selve serveren:
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
Hvis applikasjonen svarer lokalt, men ikke gjennom proxyen, bør du se på konfigurasjonen til proxyen. Svarer den ikke lokalt heller, er det applikasjonen som er problemet.
Vanlige årsaker og hvordan du løser dem
Applikasjonsprosessen har krasjet eller starter på nytt
Den vanligste årsaken. Prosessen bak proxyen gikk tom for minne, traff et unntak som ikke ble håndtert, eller ble drept, og proxyen har ingenting å snakke med. nginx logger det tydelig:
connect() failed (111: Connection refused) while connecting to upstream,
upstream: «http://127.0.0.1:3000/checkout»
Sjekk om prosessen kjører, og hvorfor den stoppet:
systemctl status myapp
journalctl -u myapp –since «30 min ago»
dmesg -T | grep -i «killed process»
En linje fra kjernens OOM-killer betyr at serveren gikk tom for minne. En omstart får nettstedet opp igjen, men den egentlige løsningen er mer minne, færre workers eller å finne og rette en minnelekkasje. Sørg for at tjenesten starter på nytt av seg selv etter et krasj, for eksempel med Restart=on-failure i systemd-enheten.
PHP-FPM er nede eller tom for workers
På PHP-nettsteder sender nginx forespørsler til PHP-FPM gjennom en socket eller en port. Hvis PHP-FPM er stoppet, socket-stien er feil eller tilgangene på socketen stenger nginx ute, returnerer alle PHP-sider 502:
connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)
Den meldingen kommer som regel etter en PHP-oppgradering: nginx peker fortsatt på socketen til den gamle versjonen. Pek fastcgi_pass på den nye socketen og last inn nginx på nytt. Hvis loggen i stedet sier server reached pm.max_children, er alle workers opptatt, ofte fordi de venter på en treg database eller et eksternt API. Hev grensen bare hvis serveren har minne til overs; ellers bør du finne ut hva som holder dem opptatt.
Feil upstream-adresse eller port
Etter en migrering, en ombygging av en container eller et portbytte kan proxyen fortsatt sende videre til den gamle adressen. Feilloggen viser adressen den prøvde. Sammenlign den med hvor applikasjonen faktisk lytter:
ss -ltnp | grep -E ‘:(3000|8000|9000)’
I Docker og Kubernetes er årsaken ofte et tjenestenavn som ikke lenger slås opp, en container som lytter på 127.0.0.1 inne i containeren i stedet for 0.0.0.0, eller en readiness-sjekk som merker alle pods som ikke klare.
Upstream-serveren lukket tilkoblingen for tidlig
upstream prematurely closed connection while reading response header betyr at applikasjonen tok imot forespørselen og deretter la på. Typiske årsaker er et krasj midt i forespørselen, en worker som ble drept fordi den overskred sin egen tidsgrense, for eksempel Gunicorns –timeout eller PHPs max_execution_time, og keep-alive-tilkoblinger som applikasjonen lukker tidligere enn proxyen forventer. Juster tidsavbruddene slik at proxyen venter litt lenger enn applikasjonen, aldri omvendt, og se på hvilke forespørsler som er trege nok til å nå grensen.
For store svarheadere
Store informasjonskapsler eller mange Set-Cookie-headere kan bli større enn nginx’ buffer for svarheaderne fra upstream. nginx logger da upstream sent too big header while reading response header from upstream og returnerer 502. Øk bufferne forsiktig:
proxy_buffer_size 16k;
proxy_buffers 8 16k;
# for PHP-FPM
fastcgi_buffer_size 32k;
fastcgi_buffers 8 16k;
Finn deretter ut hvorfor headerne vokste. En informasjonskapsel som blir større for hvert besøk, er en feil som er verdt å rette.
CDN-et når ikke origin-serveren din
Når et CDN eller en lastbalanserer returnerer 502, bør du sjekke hva som ligger mellom den og serveren din. En brannmur som blokkerer CDN-ets adresseområder, et origin-sertifikat CDN-et ikke godtar, en origin-server som bare snakker HTTP/1.0 eller lukker tilkoblinger for raskt, eller en DNS-post som peker på en gammel server, ender alle på samme måte. Test origin-serveren direkte, som vist over, og sjekk brannmuren og TLS-innstillingene på begge sider.
502-feil under deploy
Hvis 502-feil dukker opp i ti eller tjue sekunder av gangen og alltid rundt en release, er det selve deployen som forårsaker dem. Den gamle prosessen stopper, den nye bruker noen sekunder på å starte, og alle forespørsler i mellomtiden feiler. Løsningen er en releaserekkefølge der noe alltid er klart til å svare:
Start den nye versjonen ved siden av den gamle.
Vent til helsesjekken passerer. Guiden vår om å bygge et endepunkt for helsesjekk viser hva den sjekken bør teste.
Flytt trafikken over til den nye versjonen.
La den gamle versjonen fullføre forespørslene den har, og stopp den deretter.
Prosessbehandlere og orkestreringsverktøy støtter dette som rullerende omlastinger eller omlastinger uten nedetid. Bruk dem i stedet for en vanlig omstart.
Slik fanger overvåking opp 502-feil
En 502 er ofte kortvarig. En deploy gir tjue sekunder med feil, en worker krasjer og starter på nytt, en hurtigbuffer skjuler problemet for de fleste besøkende. Når noen åpner nettstedet, fungerer det igjen, men en kunde midt i et kjøp så feilen.
En oppetidsovervåking ber om sidene dine etter en fast plan og registrerer statuskoden og responstiden for hver sjekk. En 502 er en mislykket sjekk. Det som betyr noe, er hva som skjer etterpå:
Bekreft feilen. Én mislykket forespørsel kan være et blaff. Uptimecheck sjekker så ofte som hvert minutt fra Stockholm, London og New York, og bekrefter hver feil fra en annen lokasjon før en hendelse åpnes, slik at en enkeltstående tilbakestilling ikke vekker noen.
Vis bevisene. Hendelsen inneholder svaret som feilet, så du ser statuskoden, server-headeren og feilsiden, og et skjermbilde av det besøkende så. Når serveren ikke svarte i det hele tatt, får du nettverksveien i stedet.
Nå de rette personene. Varsler går til e-post, Slack, Microsoft Teams, PagerDuty, webhooks og de andre varslingskanalene teamet ditt bruker.
Overvåk mer enn forsiden. Forsiden ligger ofte i hurtigbufferen til et CDN og fortsetter å fungere mens kassen, innloggingen og API-et returnerer 502. Legg til oppetidsovervåking for sidene som tjener penger, og API-overvåking for endepunktene appene dine kaller. Når 502-feilen kommer fra en applikasjon som gikk tom for minne, viser serverovervåking minnekurven ved siden av nedetiden.
Sjekkliste for 502-feil
Les server-headeren og feilsiden for å se hvilket lag som returnerte 502-feilen.
Send forespørsler direkte til origin-serveren og applikasjonsporten for å snevre det inn.
Les feilloggen til proxyen for samme tidsstempel: avvist, lukket for tidlig eller for stor header.
Sjekk at applikasjonsprosessen kjører, og hvorfor den stoppet hvis den ikke gjør det.
Sammenlign upstream-adressen, socketen og porten med der applikasjonen lytter.
Juster tidsavbruddene slik at proxyen venter lenger enn applikasjonen.
Deploy ved å starte den nye versjonen før du stopper den gamle.
Overvåk viktige sider og endepunkter hvert minutt, og bekreft hver feil før du varsler.