En 504 Gateway Timeout-feil betyr at en server som fungerer som gateway eller proxy, ventet på svar fra serveren bak seg og ga opp. Forespørselen nådde CDN-et, lastbalansereren eller webserveren din, ble sendt videre til applikasjonen, og applikasjonen svarte ikke før tidsgrensen gikk ut.
Serveren bak proxyen kjører ofte fortsatt. Den er bare for treg, eller så er noe den venter på det. Det skiller en 504 fra de fleste andre utfall: en omstart løser det sjelden for lenge. Denne guiden viser hvordan du finner ut hvilken tidsgrense som slo til, hva som vanligvis gjør forespørselen treg, og hvordan du fikser årsaken i stedet for symptomet.
Hva en 504 forteller deg
En forespørsel til et moderne nettsted går gjennom flere lag, og hvert lag har sin egen grense for hvor lenge det venter på det neste:
Et CDN som Cloudflare venter en fast tid på opprinnelsesserveren din.
En lastbalanserer har en tidsgrense for inaktivitet eller svar per mål.
nginx venter på upstream-serveren i henhold til proxy_read_timeout eller fastcgi_read_timeout, som standard 60 sekunder.
Applikasjonen har sine egne grenser, som PHPs max_execution_time eller en worker-timeout i Gunicorn.
504-feilen kommer fra det første laget der grensen går ut. Naboene betyr noe annet: en 502 Bad Gateway betyr at upstream-serveren svarte med noe ugyldig eller ikke svarte i det hele tatt, og en 503 Service Unavailable betyr at tjenesten avviste forespørselen fordi den er overbelastet eller under vedlikehold.
Finn tidsgrensen som slo til
Ta tiden på forespørselen. En 504 som alltid kommer etter like mange sekunder, peker på én bestemt grense:
curl -s -o /dev/null -w «status %{http_code} after %{time_total}s\n» https://www.example.com/reports
status 504 after 60.04s
Se deretter på svarhodene og feilsiden for å finne ut hvilket lag som svarte, som ved enhver 5xx-feil. En enkel nginx-side med server: nginx betyr at din egen webserver fikk tidsavbrudd. En side med CDN-ets merkevare som nevner verten din, betyr at CDN-et fikk tidsavbrudd mens det ventet på opprinnelsesserveren.
nginx logger tidsavbruddet sammen med adressen den ventet på:
upstream timed out (110: Connection timed out) while reading response header from upstream,
upstream: «fastcgi://unix:/run/php/php8.3-fpm.sock», request: «GET /reports HTTP/2.0»
Nå vet du hvilken side som er treg, og hvilken del av stacken som holdt den på vent. Neste steg er å finne ut hvorfor.
Vanlige årsaker og hvordan du fikser dem
Trege databasespørringer
Den vanligste årsaken. En spørring som tok 50 millisekunder med tusen rader, tar 40 sekunder med en million, fordi den skanner hele tabellen. Slå på loggen for trege spørringer og se etter spørringene til siden:
# MySQL / MariaDB
SET GLOBAL slow_query_log = ‘ON’;
SET GLOBAL long_query_time = 1;
# PostgreSQL, in postgresql.conf
log_min_duration_statement = 1000
Kjør den tregeste spørringen med EXPLAIN og se etter fulle tabellskanninger. En manglende indeks er den vanlige løsningen. Låser er den andre vanlige mistenkte: en lang transaksjon eller en migrering kan holde på en tabell mens alle forespørsler som trenger den, venter.
Trege eksterne API-er
Sider kaller ofte andre tjenester mens de bygges: en betalingsleverandør, en fraktkalkulator, en søkemotor, et CRM. Er den tjenesten treg, blir siden din treg, og proxyen får tidsavbrudd. Sett en kort tidsgrense på alle utgående kall, noen få sekunder i stedet for bibliotekets standard, og bestem hva siden skal vise når kallet feiler. Et fraktestimat som sier «beregnes i kassen», er bedre enn en 504.
Hold øye med tjenestene du er avhengig av. Uptimechecks overvåking av tredjepartstjenester følger statussidene til 31 tjenester som Klarna, Shopify og Cloudflare, slik at en treg leverandør dukker opp ved siden av dine egne sjekker.
For få workers for trafikken
Når alle workers er opptatt, venter nye forespørsler i kø. De er ikke trege i seg selv, de venter på tur, og proxyens klokke går hele tiden. PHP-FPM sier fra i loggen med server reached pm.max_children. Flere workers hjelper bare hvis serveren har minne og CPU til dem. Ofte er det bedre å gjøre hver forespørsel kortere, slik at de samme workers rekker flere av dem, og å cache sider som ikke endrer seg fra besøkende til besøkende.
Lange jobber inne i en webforespørsel
Eksport, import, rapportgenerering, bildebehandling og utsending av hundrevis av e-poster hører ikke hjemme i en webforespørsel. De tar den tiden de tar, og før eller siden krysser én av dem en tidsgrense. Flytt dem til en bakgrunnskø: forespørselen starter jobben og svarer med en gang, og siden spør etter resultatet, eller brukeren får en e-post når den er ferdig.
Selve serveren er overbelastet
Høy CPU-bruk, minnepress som presser serveren over i swap, eller en disk som ikke henger med, gjør alt tregt på én gang. En 504 på alle sider, ikke bare én, peker hit. Se på CPU, minne, swap og diskventetid for samme periode:
uptime
free -m
iostat -x 5 3
Serverovervåking tar vare på den historikken, slik at du ser hva serveren drev med det minuttet 504-feilene startet, i stedet for å gjette i ettertid.
Nettverksproblemer mellom lagene
Hvis proxyen ikke når upstream-serveren i det hele tatt, for eksempel fordi en brannmur forkaster pakker i stedet for å avvise dem, henger tilkoblingen til den får tidsavbrudd. Det ender i en 504 og ikke en 502. Sjekk at proxyen kan åpne en tilkobling til upstream-serverens adresse og port fra samme maskin.
Når det er riktig å øke tidsgrensen
Noen ganger er en forespørsel lang av gode grunner: en stor opplasting, en rapport en administrator ber om én gang i måneden. Øk da grensen bare for den stien, og hold lagene i riktig rekkefølge, slik at de ytre venter lenger enn de indre:
location /admin/exports/ {
proxy_read_timeout 300s;
proxy_pass http://app;
}
Å øke grensen for hele nettstedet fikser ikke trege sider. Det får besøkende til å vente lenger før de ser en feil, og det lar trege forespørsler holde på workers lenger, noe som gjør køen verre for alle andre.
Slik fanger overvåking opp 504-feil
En 504 kommer sjelden ut av det blå. Siden ble litt tregere hver uke etter hvert som dataene vokste, helt til den en dag krysset grensen. Det er gode nyheter, for det betyr at du kan se det komme.
Følg med på responstiden, ikke bare statusen. Uptimecheck registrerer responstiden for hver sjekk, delt opp i DNS, tilkobling, TLS, server og nedlasting, slik at du ser om det var serveren eller nettverket som ble tregere. Et varsel om treg respons sier fra når en side krysser grensen du har satt, lenge før proxyens tidsavbrudd. Guiden vår om hva som er en god responstid hjelper deg med å velge grensen.
Bekreft feil før du varsler. Sjekker kjører så ofte som hvert minutt fra Stockholm, London og New York, og hver feil bekreftes fra en annen lokasjon, så én treg forespørsel ikke vekker noen.
Overvåk de trege sidene direkte. Søk, kasse, kontosider og rapporter er der 504-feil oppstår, og det er sjelden forsiden. Legg til oppetidsmonitorer for dem, med en tidsgrense som tilsvarer det en besøkende orker å vente.
Sjekkliste for 504
Ta tiden på forespørselen: et rundt antall sekunder forteller deg hvilken grense som slo til.
Les svarhodene og feilsiden for å se hvilket lag som fikk tidsavbrudd.
Finn den trege siden i proxyens feillogg.
Se etter trege spørringer, låser og trege eksterne kall for den siden.
Sjekk workers, CPU, minne, swap og disk for de samme minuttene.
Fiks den trege delen, cache den eller flytt den til en bakgrunnsjobb.
Øk tidsgrenser bare for stier som er lange av gode grunner, med lengre grenser i de ytre lagene enn i de indre.
Varsle om trege svar, slik at neste 504 blir oppdaget mens den fortsatt bare er en treghet.