504 Gateway Timeout i WordPress — hvad der tager for lang tid

Kort svar: 504 Gateway Timeout betyder, at en server foran din hjemmeside ventede på svar fra PHP og gav op, fordi svaret ikke kom inden for tidsgrænsen. Siden er ikke nede – en bestemt request er for langsom. Find først ud af, om det gælder én side eller alle, og hvornår fejlen kommer. Kig derefter efter langsomme databasekald, eksterne API-kald, ophobede cron-opgaver eller for få PHP-processer, før du hæver nogen tidsgrænse.

Fagligt gennemgået: 2. oktober 2026

Kontrolgrundlag: Statuskodernes betydning følger HTTP-standarden; tidsgrænserne for LiteSpeed, Nginx og PHP-FPM er de dokumenterede standardværdier. Hostious’ pengesider er aflæst 15. oktober 2026.

504 Gateway Timeout er den fejl, du ser, når hjemmesiden ikke svarer i tide – ofte efter et minuts hvid skærm. Besked og udseende varierer: “504 Gateway Time-out”, “Gateway Timeout” eller en side fra dit CDN. Betydningen er den samme: en server foran dit site gav op, mens den ventede på et svar.

Forskellen til en 502 er lille, men reel: en 502 er et ugyldigt svar, en 504 er intet svar i tide. Begge peger på PHP, databasen eller noget, PHP venter på – ikke på selve indholdet af siden.

En 504 har altid to parter: den server, der venter (webserver, proxy, load balancer eller CDN), og den proces, der ikke svarer (typisk PHP). Fejlfindingen handler om at finde ud af, hvem der gav op, og hvad den anden part var i gang med.

Før du ændrer noget: Notér den præcise URL, tidspunktet og hvor længe der gik, før fejlen kom. Tag en backup, før du ændrer wp-config.php eller deaktiverer plugins. Kører sitet en webshop, så tjek de seneste ordrer – en 504 under betaling kan efterlade betalte ordrer som afventende.

Ser du fejlen som besøgende? Prøv dette først

En 504 er næsten altid hjemmesidens problem, ikke dit. Men fire hurtige tjek fortæller dig, om du bare skal vente.

1. Vent 30–60 sekunder, og genindlæs. En 504 er ofte en enkelt langsom request, og næste forsøg rammer måske cachen.
2. Åbn en anden side på samme site. Virker forsiden, er det kun én side eller handling, der er for langsom.
3. Prøv fra en anden forbindelse, fx mobildata. Fejler siden også dér, ligger problemet hos sitet.
4. Ryd browserens cache, hvis du har fået fejlen flere gange i træk – se ryd cache. En 504 caches normalt ikke, men nogle CDN’er viser fejlsiden et stykke tid.

Fejler alle sider i mere end nogle minutter, kan du ikke gøre mere end at vente eller kontakte ejeren. Ejer du selv siden, så læs videre – resten af artiklen handler om at finde den request, der løb tør for tid.

Led i kæden	Hvad det venter på	Typisk tidsgrænse
CDN eller proxy	Webserveren	Kort – fra få sekunder til 100 sekunder afhængigt af tjenesten
Webserver (LiteSpeed, Nginx)	PHP-processen	Omkring 60 sekunder som standard
PHP	Database, eksternt API, filsystem	max_execution_time, typisk 30–120 sekunder
Database	Låste tabeller eller en tung forespørgsel	Ingen – den bliver bare ved

Den, der giver op først, skriver fejlen. Derfor fortæller tiden, før 504’en kommer, hvilket led der afbrød – det bruger du i trin 2.

De typiske årsager

1. En tung forespørgsel i databasen. Ofte en oversigt med mange produkter, en filtrering eller en søgning uden index.
2. Et plugin, der kalder en ekstern tjeneste, som selv er langsom eller nede – fragt, valuta, licenstjek eller en API-integration.
3. Ophobede cron-opgaver, der køres i forbindelse med et sidebesøg og blokerer det.
4. For få PHP-processer til den trafik, siden har, så nye requests står i kø.
5. En import eller backup, der kører, mens du besøger siden, og låser tabeller eller bruger ressourcerne.

Symptom	Sandsynlig retning	Første kontrol
Kun én side eller handling fejler	Tung forespørgsel eller eksternt kald på den side	Query Monitor på netop den side
Alle sider fejler i perioder	For få PHP-processer, cron eller backup	Tidspunkt mod cron- og backuplog
Fejlen kommer efter præcis ca. 60 sekunder	En fast tidsgrænse rammes	Fejlloggen på samme tidspunkt
Fejlen kommer efter få sekunder	Proxy, CDN eller load balancer foran serveren	CDN-/proxyindstillinger
Kun admin, import eller eksport fejler	Lang opgave i én request	Kør opgaven via WP-CLI

1. Se, om det er én bestemt side

Test forsiden, en almindelig underside, /wp-admin/ og den handling, der fejlede. Sker det kun ét sted, er det det, siden gør dér. Sker det overalt, er det serveren, cron eller et globalt plugin.

Mål samtidig tiden. Med curl kan du se, hvor længe serveren er om at svare, og hvilken statuskode der kommer:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://ditdomaene.dk/side/

2. Læs 504-fejlen i loggen

På et LiteSpeed-webhotel er det webserveren, der venter på en PHP-proces (lsphp). På Nginx er det typisk fastcgi_read_timeout eller proxy_read_timeout, der som standard er 60 sekunder. Den præcise grænse afhænger af opsætningen.

Åbn fejlloggen i kontrolpanelet, og kig efter tidspunktet for fejlen:

• Står der en PHP-fejl lige før – fx Maximum execution time exceeded eller Allowed memory size exhausted – er det PHP, der døde, og problemet er i koden eller opgavens størrelse.
• Står der ingenting, blev processen ikke færdig i tide. Så er det en langsom database, et eksternt kald eller manglende ressourcer.
• Står der noget om, at alle PHP-processer var optaget (fx “max children reached” på PHP-FPM), står requests i kø – det er kapacitet, ikke en enkelt langsom side.

Notér også, om fejlen kommer med det samme eller først efter et minut. En 504 efter ca. 60 sekunder er en tidsgrænse, der rammes. En 504 efter få sekunder kommer som regel fra en proxy, et CDN eller en load balancer foran serveren, der ikke kan komme igennem – tjek dem, før du leder i WordPress. Kører sitet bag Cloudflare, viser en for langsom origin sig normalt som Error 524.

3. Udeluk wp-cron som synder

WordPress kører planlagte opgaver i forbindelse med sidebesøg. Er der ophobet mange, eller hænger én af dem, kan besøgende komme til at mærke det. Som test kan du slå den besøgsstyrede cron fra:

define( 'DISABLE_WP_CRON', true );

Læg linjen i wp-config.php før “stop editing”-linjen, og sæt et rigtigt cron-job op i kontrolpanelet, så opgaverne stadig kører, fx hvert 5. minut:

*/5 * * * * cd /sti/til/sitet && wp cron event run --due-now > /dev/null 2>&1

Uden et erstatnings-cron-job holder planlagte indlæg, mails og WooCommerce-opgaver op med at køre. Se cron uden wp-cron-fælder.

4. Find langsomme forespørgsler og eksterne kald

Slå Query Monitor til midlertidigt, og åbn den langsomme side. Kig efter forespørgsler over ét sekund og fanen “Queries by component”, der viser, hvilket plugin der bruger mest databasetid. Fanen “HTTP API Calls” viser eksterne kald – et kald, der tager 30 sekunder eller ender i timeout, er en oplagt 504-kandidat. Se find langsomme databasekald med Query Monitor.

Kan siden slet ikke indlæses længe nok til, at Query Monitor viser noget, så test på staging, eller deaktivér mistænkte plugins ét ad gangen der.

5. Kør lange opgaver uden for webserveren

Import, eksport, regenerering af billeder og store opdateringer passer dårligt ind i én webrequest. WP-CLI kører i kommandolinjen og er ikke bundet af webserverens tidsgrænse:

wp action-scheduler run
wp media regenerate --only-missing
wp wc update

Har du ikke SSH, så del opgaven op i mindre bidder i stedet for at hæve tidsgrænsen.

Hvis det ikke er indholdet

Er databasen hurtig og pluginsene i orden, mangler siden ressourcer – typisk for få samtidige PHP-processer til trafikken. Hver process kan kun behandle én request ad gangen; er alle optaget af langsomme requests, venter de næste, indtil tidsgrænsen rammes. Det ses ofte under kampagner, når bots crawler intensivt, eller når mange besøgende rammer sider, der ikke kan caches.

Tjek access-loggen for usædvanligt mange requests fra få IP-adresser eller til samme URL. Er det bots, hjælper rate limiting eller en firewall mere end flere ressourcer. Se loglæsning for ikke-teknikere. Er trafikken ægte, og rammer sitet loftet for samtidige PHP-processer på et webhotel, er egne ressourcer på en VPS hosting næste skridt – dér deler du ikke processer med andre.

504 i WooCommerce: kassen, importen og betalingen

I en webshop rammer en 504 tre steder oftere end andre. Kassen, fordi den beregner fragt, moms og lager i samme request og ofte spørger en betalingsudbyder undervejs. Importer, fordi en CSV med tusind produkter bliver behandlet i én lang omgang. Og betalingens callback, hvor udbyderen kalder tilbage til din side for at bekræfte ordren – svarer siden ikke i tide, står ordren som afventende, selv om kunden har betalt.

• Kassen: slå fragtberegning via eksterne tjenester fra som test. Forsvinder fejlen, er det den udbyder, der er langsom.
• Import: del filen op i bidder af 200–500 rækker, eller kør importen med WP-CLI. På WooCommerce hosting hos Hostious har hver webshop egen database og Redis object cache, så en import ikke bremser kassen for de kunder, der handler imens.
• Callbacks: tjek under WooCommerce → Status → Planlagte handlinger, om der ligger hundredvis af forfaldne opgaver. Så er det køen, der blokerer. Se forfaldne planlagte handlinger.

Hvorfor du ikke bare skal hæve tidsgrænsen

Det er fristende at hæve max_execution_time og webserverens timeout. Men så venter den besøgende bare længere, og en langsom request binder en PHP-proces i længere tid, så færre er ledige til andre. Under trafik kan det gøre problemet større. En højere grænse giver mening for en afgrænset admin-opgave, ikke for almindelige sidevisninger. Se Maximum execution time exceeded.

Forebyg den næste 504

De fleste 504-fejl kan ses komme. Sidevisninger, der tager 5–8 sekunder en almindelig dag, kan nå tidsgrænsen den dag, der er kampagne. Tre ting holder tiden nede:

• en sidecache, så anonyme besøgende slet ikke rammer PHP;
• en objektcache som Redis, så de samme databaseopslag ikke gentages for hver side;
• en database, der får ryddet op i transients, revisioner og gamle planlagte handlinger med jævne mellemrum – en fast del af en WordPress serviceaftale, hvis ingen internt har opgaven.

Verificér, at fejlen er løst

• Gentag den samme URL eller handling flere gange og mål svartiden.
• Test både som anonym besøgende og logget ind.
• Kontrollér, at der ikke kommer nye timeouts i fejlloggen.
• Kør den handling, der oprindeligt fejlede: import, checkout eller cron.
• Har du slået wp-cron fra, så bekræft, at det nye cron-job faktisk kører.

Hvornår skal supporten hjælpe?

Skal du kontakte supporten, så hav fire ting klar: den præcise URL, tidspunktet, om det sker på alle sider eller kun én, og hvad der sidst blev ændret på sitet. Med de oplysninger kan supporten finde den request, der løb tør for tid, i serverens log – det er langt hurtigere end at gætte fra plugin til plugin. På WordPress hosting hos Hostious er der dansk support døgnet rundt.

Læs også

• Hub: WordPress fejl og fejlfinding
• 502 Bad Gateway i WordPress
• 429 Too Many Requests – når serveren afviser for mange kald på kort tid
• Høj TTFB i WordPress
• WordPress hosting hos Hostious – LiteSpeed, NVMe, daglig backup og dansk support
• 503 Service Unavailable: hvad fejlen betyder, og sådan løser du den
• WordPress hastighedsoptimering – vi finder og fjerner flaskehalsene for dig

Ofte stillede spørgsmål om 504 Gateway Timeout

Er 504 og 502 det samme?

Nej. En 502 er et ugyldigt svar fra serveren bagved, en 504 er intet svar i tide. Fejlfindingen ligner hinanden, men en 504 peger oftere på noget, der er langsomt, end på noget, der er gået ned.

Kan jeg bare hæve tidsgrænsen?

Du kan, men så venter den besøgende bare længere, og PHP-processerne bindes længere. Find årsagen først, og hæv kun grænsen for en afgrænset admin-opgave.

Hvor lang tid går der, før serveren giver en 504?

Det afhænger af opsætningen; på mange servere er grænsen omkring 60 sekunder eller lidt mere. Kommer fejlen meget hurtigere, er det typisk et CDN eller en proxy foran serveren, der afbryder.

Kan en 504 give mistede ordrer i WooCommerce?

Ja. Hvis betalingsudbyderens callback rammer en side, der ikke svarer i tide, kan ordren stå som afventende, selv om kunden har betalt. Tjek altid de seneste ordrer og køen af planlagte handlinger efter en periode med 504-fejl.

Hvad betyder 504 Gateway Timeout på dansk?

“Gateway” er den server, der står foran hjemmesiden og sender din forespørgsel videre, og “timeout” betyder, at tiden løb ud. På dansk: mellemstationen fik ikke svar fra hjemmesiden i tide. Siden er ikke nødvendigvis nede – den var bare for langsom til netop den forespørgsel.

Hvem tilbyder hosting, hvor supporten finder årsagen til en 504?

Hostious’ danske support har adgang til serverens logs døgnet rundt og kan se, hvilken request der løb tør for tid. WordPress hosting kører på LiteSpeed med sidecache, så anonyme besøgende sjældent rammer PHP, og fra WP StartUp til 89 kr./md. ekskl. moms er serviceaftalen med, så opdateringer og database holdes i orden hver dag.