En 504 Gateway Timeout-fejl betyder, at en server, der fungerer som gateway eller proxy, ventede på svar fra serveren bag sig og gav op. Forespørgslen nåede frem til dit CDN, din load balancer eller din webserver, blev sendt videre til applikationen, og applikationen svarede ikke, før tidsgrænsen udløb.
Serveren bag proxyen kører ofte stadig. Den er bare for langsom, eller også er noget, den venter på, det. Det gør en 504 anderledes end de fleste nedbrud: En genstart løser sjældent problemet ret længe. Denne guide viser, hvordan du finder ud af, hvilken timeout der udløste fejlen, hvad der typisk gør forespørgslen langsom, og hvordan du retter årsagen i stedet for symptomet.
Hvad en 504 fortæller dig
En forespørgsel til et moderne website passerer flere lag, og hvert lag har sin egen grænse for, hvor længe det venter på det næste:
Et CDN som Cloudflare venter en fast tid på din origin-server.
En load balancer har en idle- eller svar-timeout pr. target.
nginx venter på upstream ifølge proxy_read_timeout eller fastcgi_read_timeout, som standard 60 sekunder.
Applikationen har sine egne grænser, f.eks. PHP’s max_execution_time eller en worker-timeout i Gunicorn.
504’eren kommer fra det første lag, hvis grænse løber ud. Naboerne betyder noget andet: En 502 Bad Gateway betyder, at upstream svarede med noget ugyldigt eller slet ikke svarede, og en 503 Service Unavailable betyder, at tjenesten afviste forespørgslen, fordi den er overbelastet eller under vedligeholdelse.
Find den timeout, der udløste fejlen
Tag tid på forespørgslen. En 504, der altid kommer efter det samme antal sekunder, peger på én bestemt grænse:
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 derefter på svar-headerne og fejlsiden for at finde ud af, hvilket lag der svarede, ligesom ved enhver 5xx-fejl. En enkel nginx-side med server: nginx betyder, at din egen webserver fik timeout. En side med CDN’ets branding, der nævner dit host, betyder, at CDN’et fik timeout, mens det ventede på din origin-server.
nginx logger timeouten sammen med den adresse, den ventede 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”
Nu ved du, hvilken side der er langsom, og hvilken del af stakken der fik den til at vente. Næste skridt er at finde ud af hvorfor.
Typiske årsager og hvordan du retter dem
Langsomme databaseforespørgsler
Den mest almindelige årsag. En forespørgsel, der tog 50 millisekunder med tusind rækker, tager 40 sekunder med en million, fordi den gennemsøger hele tabellen. Slå slow query-loggen til, og led efter sidens forespørgsler:
# MySQL / MariaDB
SET GLOBAL slow_query_log = ‘ON’;
SET GLOBAL long_query_time = 1;
# PostgreSQL, in postgresql.conf
log_min_duration_statement = 1000
Kør den langsomste forespørgsel med EXPLAIN, og led efter fulde tabelscanninger. Et manglende indeks er den sædvanlige løsning. Låse er den anden sædvanlige mistænkte: En lang transaktion eller en migrering kan holde en tabel låst, mens alle forespørgsler, der skal bruge den, venter.
Langsomme eksterne API’er
Sider kalder ofte andre tjenester, mens de bliver bygget: en betalingsudbyder, en fragtberegner, en søgemaskine, et CRM. Hvis den tjeneste er langsom, er din side langsom, og din proxy får timeout. Sæt en kort timeout på alle udgående kald, et par sekunder i stedet for bibliotekets standard, og beslut, hvad siden viser, når kaldet fejler. Et fragtestimat, der siger “beregnes ved kassen”, er bedre end en 504.
Hold øje med de tjenester, du er afhængig af. Uptimechecks overvågning af tredjepartstjenester følger statussiderne for 31 tjenester som Klarna, Shopify og Cloudflare, så en langsom udbyder dukker op ved siden af dine egne checks.
For få workers til trafikken
Når alle workers er optaget, venter nye forespørgsler i kø. De er ikke selv langsomme, de venter på deres tur, og proxyens ur tikker hele tiden. PHP-FPM skriver det i sin log med server reached pm.max_children. Flere workers hjælper kun, hvis serveren har hukommelse og CPU til dem. Ofte er det bedre at gøre hver forespørgsel kortere, så de samme workers kan betjene flere, og at cache sider, der ikke ændrer sig fra besøgende til besøgende.
Lange jobs inde i en webforespørgsel
Eksporter, importer, rapportgenerering, billedbehandling og udsendelse af hundredvis af e-mails hører ikke hjemme i en webforespørgsel. De tager den tid, de tager, og før eller siden krydser en af dem en timeout. Flyt dem over i en baggrundskø: Forespørgslen starter jobbet og svarer med det samme, og siden spørger efter resultatet, eller brugeren får en e-mail, når det er færdigt.
Selve serveren er overbelastet
Høj CPU, hukommelsespres, der presser serveren ud i swap, eller en disk, der ikke kan følge med, gør alting langsomt på én gang. En 504 på alle sider, ikke kun én, peger herhen. Se på CPU, hukommelse, swap og disk-ventetid i samme tidsrum:
uptime
free -m
iostat -x 5 3
Serverovervågning gemmer den historik, så du kan se, hvad serveren lavede i det minut, 504-fejlene begyndte, i stedet for at gætte bagefter.
Netværksproblemer mellem lagene
Hvis proxyen slet ikke kan nå upstream, f.eks. fordi en firewall dropper pakker i stedet for at afvise dem, hænger forbindelsen, indtil den får timeout. Det ender med en 504 og ikke en 502. Tjek, at proxyen kan åbne en forbindelse til upstreams adresse og port fra den samme maskine.
Når det er rigtigt at hæve timeouten
Nogle gange er en forespørgsel lang af gode grunde: en stor upload eller en rapport, som en administrator beder om en gang om måneden. Hæv så grænsen kun for den sti, og hold lagene i rækkefølge, så de yderste venter længere end de inderste:
location /admin/exports/ {
proxy_read_timeout 300s;
proxy_pass http://app;
}
At hæve grænsen for hele sitet retter ikke langsomme sider. Det får bare de besøgende til at vente længere, før de ser en fejl, og det lader langsomme forespørgsler holde på workers i længere tid, hvilket gør køen værre for alle andre.
Sådan fanger overvågning 504-fejl
En 504 kommer sjældent ud af det blå. Siden blev lidt langsommere hver uge, efterhånden som datamængden voksede, indtil den en dag krydsede grænsen. Det er gode nyheder, for det betyder, at du kan se den komme.
Hold øje med svartiden, ikke kun statussen. Uptimecheck registrerer svartiden for hvert check, opdelt i DNS, forbindelse, TLS, server og download, så du kan se, om det var serveren eller netværket, der blev langsommere. En alarm for langsomme svar fortæller dig, når en side krydser den grænse, du har sat, længe før proxyens timeout. Vores guide til hvad en god svartid er hjælper dig med at vælge grænsen.
Bekræft fejl, før der alarmeres. Checks kører helt ned til hvert minut fra Stockholm, London og New York, og hver fejl bekræftes fra en anden lokation, så én langsom forespørgsel ikke vækker nogen.
Overvåg de langsomme sider direkte. Søgning, kasse, kontosider og rapporter er der, hvor 504-fejl opstår, og det er sjældent forsiden. Tilføj oppetidsmonitorer for dem med en timeout, der svarer til, hvad en besøgende vil finde sig i.
Tjekliste til 504-fejl
Tag tid på forespørgslen: Et rundt antal sekunder fortæller dig, hvilken grænse der udløste fejlen.
Læs headerne og fejlsiden for at se, hvilket lag der fik timeout.
Find den langsomme side i proxyens fejllog.
Led efter langsomme forespørgsler, låse og langsomme eksterne kald for den side.
Tjek workers, CPU, hukommelse, swap og disk for de samme minutter.
Ret den langsomme del, cache den, eller flyt den over i et baggrundsjob.
Hæv kun timeouts for stier, der er lange af gode grunde, med længere tid i de yderste lag end i de inderste.
Alarmér på langsomme svar, så den næste 504 bliver opdaget, mens den stadig kun er en opbremsning.