cURL error 28 og loopback-fejl i Site Health – hvad de betyder

Kort svar: cURL error 28 betyder timeout: serveren ventede på et svar, der aldrig kom. I Site Health handler det næsten altid om loopback – serverens evne til at kalde sit eget domæne. Svarer sitet fint udefra, ligger blokeringen på den indvendige rute: firewall, DNS eller IPv6 på serveren, en proxy, en låst PHP-session eller optagne PHP-processer. Find og ret blokeringen – en højere timeout skjuler kun problemet.

Fagligt gennemgået: 2. oktober 2026

Site Health (Webstedstilstand) melder “cURL error 28: Operation timed out” eller “Loopback-anmodningen mislykkedes” – men sitet virker tilsyneladende fint. Skal du så gøre noget? Ja, som regel: loopback bruges af wp-cron, editorens fejltjek, REST-kald og plugin-opdateringer. En fejl her giver diffuse problemer andre steder – fx planlagte opgaver, der aldrig kører.

Guiden tager dig gennem fejlfindingen i den rækkefølge, der giver svar hurtigst: først hvilken type kald der fejler, derefter en test udefra og indefra, og til sidst den konkrete blokering og rettelsen.

Før du ændrer noget: Tag en backup, og notér præcis hvilken meddelelse Site Health viser, og hvornår. Slå ikke firewall eller sikkerhedsplugin fra for alle – lav en afgrænset undtagelse for serverens egen IP, så du ikke åbner sitet for angreb, mens du fejlsøger.

Hvad er en loopback-request?

En loopback er, når din server sender en HTTP-request til sit eget domæne – altså kalder sig selv udefra-ind. WordPress bruger det til at afvikle wp-cron i baggrunden, til at teste om kodeændringer vælter sitet, og til interne REST-kald. Requesten skal hele vejen gennem DNS, eventuel proxy og webserver, præcis som en besøgendes request. Derfor kan den fejle, selvom sitet virker i browseren: din browser og din server tager ikke nødvendigvis samme vej.

Selve fejlkoden kommer fra cURL-biblioteket, som WordPress bruger til HTTP-kald. Kode 28 betyder “operation timed out”: forbindelsen blev enten aldrig oprettet, eller svaret kom ikke inden for den tid, WordPress ventede. Site Healths loopback-test venter omkring 10 sekunder, mens almindelige HTTP-kald i WordPress som standard har en timeout på 5 sekunder. Et sundt site svarer sig selv på langt under et sekund – så en timeout er et tydeligt tegn på, at noget er galt.

1. Find ud af, hvilket kald der fejler

Læs hele meddelelsen i Site Health under Værktøjer → Webstedstilstand. cURL error 28 kan stå ved flere forskellige test, og de peger i hver sin retning:

• Loopback-anmodning: serveren kan ikke kalde sit eget domæne. Det er hovedemnet i denne guide.
• REST API: kaldet til /wp-json/ på dit eget site timer ud. Samme fejlfinding som loopback, men tjek også REST API-guiden, fordi sikkerhedsplugins ofte begrænser netop REST.
• Kommunikation med WordPress.org: fejlen nævner api.wordpress.org. Så er det et udgående kald, der fejler – typisk en udgående firewall, en langsom DNS-resolver på serveren eller manglende IPv6-rute. Det er ikke loopback, men serverens forbindelse til omverdenen.
• Planlagte begivenheder: Site Health melder om forsinkede eller mislykkede cron-job. Det er ofte en følgevirkning af en loopback-fejl.

Ser du også advarslen “En aktiv PHP-session blev fundet”, så notér den – den er en af de hyppigste skjulte årsager til loopback-timeouts og behandles nedenfor.

2. Test udefra og indefra

Sammenlign de to veje. Udefra: åbn sitet i browseren eller kør curl fra din egen maskine. Indefra: brug WP-CLI eller et diagnostik-plugin til at lave requesten fra serveren selv:

Har du SSH-adgang, kan du lave begge test med de samme kommandoer. Kør først denne fra din egen computer og derefter fra serveren (udskift domænet med dit eget):

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://ditdomæne.dk/wp-cron.php

Fra serveren kan du også bede WordPress selv om at lave kaldet. Så går det gennem præcis samme kode som Site Health:

wp cron test

wp eval '$r = wp_remote_get( home_url( "/" ), array( "timeout" => 10 ) ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_response_code( $r );'

Fire udfald: Virker begge veje, var fejlen forbigående (fx belastning). Fejler kun indefra, har du en ægte loopback-blokering – gå til trin 3. Fejler begge veje, har du et alvorligere problem – start med 504-guiden. Og svarer sitet, men meget langsomt, er det TTFB-sporet, du skal følge.

3. Find den typiske blokering

Blokering	Sådan opdager du den	Typisk kontekst
Firewall afviser serverens egen IP	Indefra-kald får timeout eller 403; firewall-loggen viser drop	Sikkerhedsplugin, geoblokering, fail2ban
DNS på serveren peger forkert	Domænet slås op til en anden IP indefra end udefra	Site flyttet for nylig; gammel hosts-fil
IPv6 uden fungerende rute	Domænet har en AAAA-record, og kaldet hænger, indtil det opgives	AAAA-record sat op, men serveren kan ikke nå den adresse
Proxy/CDN uden undtagelse	Kaldet går ud gennem Cloudflare og rammer challenge eller rate limit	Orange sky på domænet – se Cloudflare-hubben
Låst PHP-session	Site Health viser også “aktiv PHP-session”; fejlen følger et bestemt plugin	Plugin kalder session_start() uden at lukke sessionen igen
Adgangskode på sitet	Kaldet får 401 i stedet for 200	Staging eller site under udvikling bag HTTP-login
Alle PHP-processer optaget	Fejlen kommer kun under belastning; svartider svinger	Få workers + tunge samtidige requests

Sådan sammenligner du DNS indefra og udefra

Kør et opslag på serveren og et på din egen maskine, og sammenlign IP-adresserne. getent bruger serverens egen opslagsrækkefølge, inklusive hosts-filen, og viser derfor det, PHP faktisk ser:

getent hosts ditdomæne.dk
dig +short ditdomæne.dk A
dig +short ditdomæne.dk AAAA

Peger serveren på en gammel IP, sender den sine egne kald til det tidligere webhotel – som ikke svarer, eller svarer med et helt andet site. Har domænet en AAAA-record, kan du teste IPv4 og IPv6 hver for sig med curl -4 og curl -6. Hænger kun IPv6-kaldet, skal enten AAAA-recorden rettes, eller serverens IPv6-forbindelse bringes i orden.

Hvorfor en PHP-session kan låse loopback

Når et plugin starter en PHP-session med session_start(), låses sessionsfilen, indtil requesten er færdig. Site Healths loopback sender din login-cookie med. Bruger den samme session, venter loopback-kaldet på, at din egen request slipper låsen – og din request venter på loopback-svaret. Resultatet er en timeout. Løsningen er at finde pluginnet (typisk formular-, statistik- eller medlemsplugins) og opdatere det, så det lukker sessionen med session_write_close(), eller erstatte det.

4. Ret blokeringen

• Firewall: tilføj serverens egen IP (og 127.0.0.1) som undtagelse i sikkerhedspluginnet eller serverens firewall – fjern ikke beskyttelsen for alle andre.
• DNS: en hosts-linje på serveren, der peger domænet direkte på serverens egen IP, fjerner både DNS-fejl og unødig omvej gennem proxyen. På delt hosting har du normalt ikke adgang til hosts-filen – så er det hostingudbyderen, der skal rette det. Kunder hos Hostious kan skrive til supporten, hvis fejlen dukker op efter en flytning.
• IPv6: fjern en AAAA-record, der peger på en adresse, serveren ikke svarer på – eller få den rettet, så IPv6 faktisk virker hele vejen.
• Cloudflare: undtag serverens IP fra challenges og rate limiting, eller lad loopback gå udenom proxyen via hosts-linjen ovenfor.
• PHP-session: find pluginnet ved at deaktivere mistænkte plugins ét ad gangen på staging, og opdatér eller udskift det.
• Adgangskode på sitet: på staging bag HTTP-login er loopback-advarslen forventelig. Undtag serverens egen IP fra adgangskoden, hvis wp-cron skal virke dér.
• Optagne processer: hændelsen er et kapacitetssignal. Fjern det, der holder processerne i live for længe (langsomme eksterne kald, tunge sider uden cache), eller opgrader til en pakke med flere samtidige PHP-processer.

5. Gør wp-cron uafhængig af loopback

wp-cron starter normalt, når en besøgende rammer sitet, og WordPress sender så et loopback-kald til wp-cron.php. Fejler loopback, kører de planlagte opgaver ikke. Uanset om du får rettet blokeringen, er det en god idé at lade en rigtig server-cron overtage. Slå først den indbyggede udløsning fra i wp-config.php:

define( 'DISABLE_WP_CRON', true );

Opret derefter et cron-job i kontrolpanelet, der kører hvert 5. minut. Med WP-CLI kører opgaverne direkte i PHP uden at gå over HTTP:

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

Det fjerner ikke loopback-advarslen i Site Health – editorens fejltjek og REST-kald bruger stadig loopback – men det sikrer, at planlagte indlæg, ordrestatusser og opdateringstjek kører til tiden. Læs mere i guiden om cron uden wp-cron-fælder.

Hvornår kan advarslen ignoreres?

Hvis wp-cron kører via en rigtig server-cron, planlagte indlæg udgives til tiden, og editoren gemmer uden fejl, så er en enkeltstående loopback-advarsel i praksis harmløs – nogle opsætninger blokerer bevidst interne kald af sikkerhedshensyn, og staging bag adgangskode giver den altid. Men dokumentér i så fald hvorfor, så den næste, der åbner Site Health, ikke starter en undersøgelse forfra.

6. Verificér rettelsen

Rettelsen holder, når Site Health ikke længere viser loopback- eller cURL-advarsler efter en genindlæsning, når et indefra-kald svarer 200 på under et sekund, og når advarslen ikke vender tilbage under belastning. Tjek også, at wp cron test melder succes, og at et planlagt testindlæg udgives til tiden. Hæv aldrig timeout-værdier som første greb: en hævet grænse skjuler kun, at svaret kommer for sent – den får det ikke frem.

Læs også

• Hub: WordPress fejl og fejlfinding
• wp-cron virker ikke: planlagte opgaver kører aldrig
• WordPress REST API-fejl i Site Health
• 504 Gateway Timeout i WordPress
• Cloudflare til WordPress – når proxyen står i vejen for serverens egne kald
• WordPress hosting hos Hostious – LiteSpeed, daglig backup og dansk support døgnet rundt

Ofte stillede spørgsmål om cURL error 28

Er cURL error 28 farlig?

Den vælter ikke sitet, men den bremser alt, der afhænger af interne kald: cron-opgaver, opdateringstjek og dele af editoren. Behandl den som et symptom, der skal forklares – ikke som støj.

Hvorfor virker sitet fint, når loopback fejler?

Fordi besøgende og serveren tager forskellige veje. Din browser rammer sitet udefra; serveren skal kalde sig selv og kan blive stoppet af firewall, DNS eller proxy på den indvendige rute.

Skal jeg bare hæve timeout-grænsen?

Nej. Timeout er måleinstrumentet, ikke fejlen. Find ud af, hvorfor svaret udebliver – firewall, DNS, proxy eller kapacitet – og ret det. En højere grænse gør kun ventetiden længere.

Hvad betyder det, når fejlen nævner api.wordpress.org?

Så er det serverens udgående forbindelse, der fejler, ikke loopback. Typiske årsager er en udgående firewall, en langsom DNS-resolver på serveren eller en IPv6-rute, der ikke virker. Det skal som regel rettes af hostingudbyderen.