Ett 504 Gateway Timeout-fel betyder att en server som fungerar som gateway eller proxy väntade på svar från servern bakom sig och till slut gav upp. Anropet nådde ditt CDN, din lastbalanserare eller din webbserver, skickades vidare till applikationen, och applikationen svarade inte innan tidsgränsen gick ut.
Servern bakom proxyn är ofta fortfarande igång. Den är bara för långsam, eller så är något den väntar på det. Därför skiljer sig ett 504-fel från de flesta avbrott: en omstart löser sällan problemet för gott. Den här guiden visar hur du hittar vilken tidsgräns som löste ut, vad som brukar göra anropet långsamt och hur du åtgärdar orsaken i stället för symtomet.
Vad ett 504-fel säger dig
Ett anrop till en modern webbplats passerar flera lager, och varje lager har sin egen gräns för hur länge det väntar på nästa:
Ett CDN som Cloudflare väntar en fast tid på din ursprungsserver.
En lastbalanserare har en tidsgräns för inaktivitet eller svar per mål.
nginx väntar på upstream-servern enligt proxy_read_timeout eller fastcgi_read_timeout, som standard 60 sekunder.
Applikationen har egna gränser, till exempel PHP:s max_execution_time eller en worker-timeout i Gunicorn.
504-felet kommer från det första lager vars gräns tar slut. Grannarna betyder något annat: 502 Bad Gateway betyder att upstream-servern svarade med något ogiltigt eller inte alls, och 503 Service Unavailable betyder att tjänsten avvisade anropet för att den är överbelastad eller har underhåll.
Hitta tidsgränsen som löste ut
Ta tid på anropet. Ett 504-fel som alltid kommer efter lika många sekunder pekar på en bestämd gräns:
curl -s -o /dev/null -w ”status %{http_code} after %{time_total}s\n” https://www.example.com/reports
status 504 after 60.04s
Titta sedan på svarshuvudena och felsidan för att se vilket lager som svarade, precis som vid alla 5xx-fel. En enkel nginx-sida med server: nginx betyder att din egen webbserver fick timeout. En sida med CDN:ets varumärke som nämner din värd betyder att CDN:et fick timeout i väntan på din ursprungsserver.
nginx loggar timeouten tillsammans med adressen den väntade 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 vet du vilken sida som är långsam och vilken del av stacken som fick den att vänta. Nästa steg är att ta reda på varför.
Vanliga orsaker och hur du åtgärdar dem
Långsamma databasfrågor
Den vanligaste orsaken. En fråga som tog 50 millisekunder med tusen rader tar 40 sekunder med en miljon, eftersom den läser igenom hela tabellen. Slå på loggen för långsamma frågor och leta efter sidans frågor:
# 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 långsammaste frågan med EXPLAIN och leta efter fullständiga tabellskanningar. Ett saknat index är den vanliga lösningen. Lås är den andra vanliga misstänkta: en lång transaktion eller en migrering kan hålla en tabell medan alla anrop som behöver den får vänta.
Långsamma externa API:er
Sidor anropar ofta andra tjänster medan de byggs: en betalleverantör, en fraktkalkylator, en sökmotor, ett CRM. Är den tjänsten långsam blir din sida långsam, och din proxy får timeout. Sätt en kort tidsgräns på varje utgående anrop, några sekunder i stället för bibliotekets standardvärde, och bestäm vad sidan visar när anropet misslyckas. En fraktberäkning som säger ”beräknas i kassan” är bättre än ett 504-fel.
Håll koll på tjänsterna du är beroende av. Uptimechecks övervakning av tredjepartstjänster följer statussidorna för 31 tjänster som Klarna, Shopify och Cloudflare, så att en långsam leverantör syns bredvid dina egna kontroller.
För få workers för trafiken
När alla workers är upptagna hamnar nya anrop i kö. De är inte långsamma i sig, de väntar på sin tur, och proxyns klocka tickar hela tiden. PHP-FPM skriver det i sin logg med server reached pm.max_children. Fler workers hjälper bara om servern har minne och CPU för dem. Ofta är det bättre att göra varje anrop kortare, så att samma workers hinner med fler, och att cacha sidor som inte ändras per besökare.
Långa jobb inne i ett webbanrop
Exporter, importer, rapportgenerering, bildbehandling och utskick av hundratals e-postmeddelanden hör inte hemma i ett webbanrop. De tar den tid de tar, och förr eller senare passerar något av dem en tidsgräns. Flytta dem till en bakgrundskö: anropet startar jobbet och svarar direkt, och sidan frågar efter resultatet eller så får användaren ett mejl när det är klart.
Själva servern är överbelastad
Hög CPU-belastning, minnesbrist som tvingar servern att swappa eller en disk som inte hänger med gör allt långsamt på en gång. Ett 504-fel på varje sida, inte bara på en, pekar hit. Titta på CPU, minne, swap och diskväntan för samma period:
uptime
free -m
iostat -x 5 3
Serverövervakning sparar den historiken, så att du kan se vad servern gjorde den minut 504-felen började i stället för att gissa i efterhand.
Nätverksproblem mellan lagren
Om proxyn inte når upstream-servern alls, till exempel för att en brandvägg slänger paket i stället för att avvisa dem, hänger anslutningen tills den får timeout. Det slutar med ett 504-fel snarare än ett 502-fel. Kontrollera att proxyn kan öppna en anslutning till upstream-serverns adress och port från samma maskin.
När det är rätt att höja tidsgränsen
Ibland är ett anrop långt av goda skäl: en stor uppladdning, en rapport som en administratör beställer en gång i månaden. Höj då gränsen bara för den sökvägen, och håll lagren i ordning så att de yttre väntar längre än de inre:
location /admin/exports/ {
proxy_read_timeout 300s;
proxy_pass http://app;
}
Att höja gränsen för hela webbplatsen gör inte långsamma sidor snabbare. Besökarna får bara vänta längre innan de ser ett fel, och långsamma anrop håller workers längre, vilket gör kön värre för alla andra.
Så fångar övervakning 504-fel
Ett 504-fel kommer sällan från ingenstans. Sidan blev lite långsammare för varje vecka i takt med att datamängden växte, tills den en dag passerade gränsen. Det är goda nyheter, för det betyder att du kan se det komma.
Bevaka svarstiden, inte bara statusen. Uptimecheck registrerar svarstiden för varje kontroll, uppdelad i DNS, anslutning, TLS, server och nedladdning, så att du ser om det var servern eller nätverket som blev långsammare. Ett larm om långsamma svar säger till när en sida passerar gränsen du har satt, långt innan proxyns timeout. Vår guide om vad som är en bra svarstid hjälper dig att välja gränsen.
Bekräfta fel innan du larmar. Kontrollerna körs så ofta som varje minut från Stockholm, London och New York, och varje fel bekräftas från en andra plats, så att ett enstaka långsamt anrop inte väcker någon.
Övervaka de långsamma sidorna direkt. Sök, kassa, kontosidor och rapporter är där 504-felen uppstår, och det är sällan startsidan. Lägg till upptidsmonitorer för dem, med en tidsgräns som motsvarar vad en besökare står ut med.
Checklista för 504-fel
Ta tid på anropet: ett jämnt antal sekunder visar vilken gräns som löste ut.
Läs svarshuvudena och felsidan för att se vilket lager som fick timeout.
Hitta den långsamma sidan i proxyns fellogg.
Leta efter långsamma frågor, lås och långsamma externa anrop för den sidan.
Kontrollera workers, CPU, minne, swap och disk för samma minuter.
Åtgärda den långsamma delen, cacha den eller flytta den till ett bakgrundsjobb.
Höj tidsgränser bara för sökvägar som är långa av goda skäl, yttre lager längre än inre.
Larma om långsamma svar, så att nästa 504-fel syns medan det fortfarande bara är en fördröjning.