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. Test først, om sitet svarer udefra. Gør det det, ligger blokeringen mellem serveren og den selv: firewall, DNS på serveren, et sikkerhedsplugin eller alle PHP-processer optaget. Ret blokeringen – hæv ikke bare timeouten.
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 blokeringstjek, REST-kald og plugin-opdateringer. En fejl her giver diffuse problemer andre steder – fx planlagte opgaver, der aldrig kører.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt på et anonymiseret domæne og viser mekanismen – det er ikke målinger af hostious.io.
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.
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:
Fire udfald: Virker begge veje, var fejlen forbigående (fx belastning). Fejler kun indefra, har du en ægte loopback-blokering – gå til trin 2. 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.
| 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 |
| Proxy/CDN uden undtagelse | Kaldet går ud gennem Cloudflare og rammer challenge eller rate limit | Orange sky på domænet – se Cloudflare-hubben |
| Alle PHP-processer optaget | Fejlen kommer kun under belastning; svartider svinger | Få workers + tunge samtidige requests |
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 lavpraktisk set harmløs – nogle opsætninger blokerer bevidst interne kald af sikkerhedshensyn. Men dokumentér i så fald hvorfor, så den næste, der åbner Site Health, ikke starter en undersøgelse forfra.
Rettelsen er dokumenteret, 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. 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.
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.
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.
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.
