
Kort svar: En 521 betyder, at Cloudflare forsøgte at forbinde til origin-serveren, men forbindelsen blev afvist. Kontrollér først, om webserveren kører og lytter på den port, som Cloudflares SSL-tilstand kræver: typisk 80 ved Flexible og 443 ved Full eller Full (strict). Derefter skal hosting kontrollere firewall, rate limits og Cloudflare-IP-ranges. Skift ikke SSL-tilstand på må og få; match den med originens faktiske HTTPS-opsætning.
Risiko: Middel Forventet tid: 15-45 minutter Hav klar: Fejltidspunkt, Ray ID, SSL/TLS-mode og adgang til webserver-/firewallstatus
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Fejlforløbet er kontrolleret som faglig procedure; Hostious er ikke bag Cloudflare, og der er ikke udført en 521-test mod produktion. Syntetiske stagingvisninger må kun læses som illustration af et symptom.
En afvist forbindelse er noget andet end en langsom forbindelse. Ved 521 når Cloudflare frem til originens adresse, men webserveren tager ikke imod forbindelsen på den forventede port, eller et sikkerhedslag afviser Cloudflares IP. Derfor hjælper det sjældent at rydde WordPress-cache eller deaktivere et tilfældigt plugin.
På denne side
Gem URL, tidspunkt med tidszone og Ray ID. Kontrollér om fejlen rammer både hoveddomænet og www, og om den gælder HTTP, HTTPS eller begge. Notér Cloudflares aktuelle SSL/TLS-mode uden at ændre den.

| Observation | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| 521 på hele websitet | Webserver nede eller forkert port | Hosting kontrollerer service og lytteporte | Start/reparer service og find nedbrudsårsag |
| 521 efter skift til Full (strict) | Origin tager ikke imod HTTPS | Test port 443 og certifikat med korrekt hostname | Installer/reparer certifikat og HTTPS-vhost |
| 521 kommer og går | Firewall/rate limit eller serviceflap | Sammenhold firewall- og servicelog med Ray-tid | Ret den konkrete grænse eller blokering |
| Direkte origin-test virker, proxied gør ikke | Cloudflare-IP'er blokeres | Hosting gennemgår firewall og allowlist | Tillad aktuelle ranges korrekt |
| Kun ét hostname fejler | Forkert DNS-destination eller vhost | Sammenlign DNS og serverens host binding | Ret den specifikke post/vhost |
Hosting bør kontrollere webserverens service-status, proceslog og seneste restart. Hvis Nginx, Apache eller LiteSpeed er stoppet, er en genstart kun førstehjælp. Find efterfølgende, om årsagen var en konfigurationsfejl, udløbet licens, portkonflikt, manglende hukommelse eller automatisk deployment.
Efter en genstart skal serviceovervågningen vise stabil drift, og serveren skal tage imod flere forbindelser på den relevante port. En enkelt vellykket request er ikke nok, hvis processen straks falder igen.
Ved Full eller Full (strict) skal origin acceptere HTTPS. Kontrollér:
www;Hvis 521 begyndte umiddelbart efter et SSL-skift, bør du ikke vælge Flexible som permanent genvej. Gør origin klar til Full (strict), og genaktiver derefter den sikre tilstand. En 525 eller 526 efter forbindelsen åbnes betyder, at du er kommet videre til TLS-diagnosen.
Cloudflare forbinder fra sine egne IP-ranges. En origin-firewall, fail2ban-regel eller DDoS-løsning kan derfor blokere mange legitime besøgende på én gang, hvis den ikke forstår proxytrafikken.
Hosting skal bruge den aktuelle officielle IP-liste og automatisere vedligeholdelsen, hvor det er muligt. Tillad kun de nødvendige webporte, og konfigurer real-IP korrekt. Ellers kan webserveren registrere Cloudflare-adressen som klient og udløse rate limit for hele datacentret.
Deaktiver ikke firewallen globalt som “test”. Find den konkrete reject-hændelse, lav en afgrænset rettelse, og bekræft både at Cloudflare får adgang, og at origin ikke er åbnet unødigt for direkte trafik.
Efter migrering kan A- eller AAAA-posten pege på en gammel server. Sammenlign Cloudflares DNS-indhold med den origin-destination, hosting har oplyst, uden at dele adressen offentligt. Kontroller både apex, www og eventuelle IPv6-poster. En forkert AAAA-post kan give ujævne resultater, hvis origin ikke har den forventede webservice på IPv6.
Ændr én post ad gangen, gem den gamle værdi til rollback, og verificér det ønskede hostname gennem Cloudflare. DNS-opslag skal efter testen fortsat returnere Cloudflare-adresser for proxied webposter.
Webserveren er stoppet efter en opdatering. Fejlen rammer alle sider, og der står ingen accepteret request i accessloggen. Servicejournalen viser, at processen stoppede eller ikke kunne binde porten. Her er løsningen at få webserveren stabilt op og forstå, hvorfor den stoppede. En firewall-allowlist ændrer ikke en proces, der slet ikke lytter.
Kun Cloudflare-trafik bliver afvist. En kontrolleret origin-test med korrekt hostname og SNI virker, mens offentlige requests giver 521. Firewall- eller sikkerhedsloggen viser afvisninger fra proxytrafikken på samme tidspunkt. Her skal den konkrete regel og håndteringen af rigtig klient-IP rettes. Et bredt “allow all” er en dårlig sluttilstand, fordi det fjerner beskyttelse uden at forklare, hvilken kontrol der var forkert.
Det ene hostname virker, det andet gør ikke. Forsiden svarer, men www eller et underdomæne giver 521. Det peger på DNS, en manglende virtual host eller en port-/certifikatopsætning for netop navnet. Sammenlign A og AAAA, proxy-status og den serverblok, som vælges ved SNI. At genstarte hele serveren kan midlertidigt ændre symptomet, men løser ikke en forkert destination.
Brug mønstret til at vælge ejer: drift ved service og port, sikkerhed ved dokumenterede afvisninger og DNS/webserver ved hostname-forskelle. WordPress kommer først ind i billedet, hvis applikationen udløser gentagne processammenbrud; selve 521 sker, før en normal WordPress-response kan leveres.
Stop, så snart et trin giver et konkret bevis. Hvis port 443 ikke lytter, er det spild af tid at ændre WordPress-plugins. Hvis porten lytter og den SNI-korrekte origin-test virker, flyttes fokus derimod til proxytrafik og firewall.
www følger den planlagte redirect og ender i 200.Gendan den tidligere DNS-værdi eller firewallregel, hvis den nye ændring rammer forkert. Hvis du midlertidigt ændrede SSL-mode, skal den sikre måltilstand gendannes, når originens HTTPS er rettet. Dokumentér den fungerende port, vhost og regel, så en senere serveropdatering ikke genindfører fejlen.
521 er næsten altid en driftsopgave: hosting skal kontrollere service, porte, firewall og den aktuelle origin-destination. En WordPress-udvikler er først relevant, hvis et deployment eller en applikationsproces gentagne gange får webserveren til at stoppe. Se WordPress-hosting hos Hostious, hvis du vil samle fejlsøgningen hos ét driftsteam.
At Cloudflare bankede på, men origin-serveren afviste forbindelsen – webserveren er nede, lytter på forkert port eller blokerer Cloudflares IP-områder i firewallen.
Fordi SSL-tilstanden bestemmer porten: Flexible går til port 80, Full til 443. Skifter du tilstand uden at origin lytter på den nye port, opstår 521 med det samme.
Tjek at serverens firewall tillader Cloudflares offentliggjorte IP-intervaller. Ser du ingen indgående forsøg i serverloggen ved fejltidspunktet, er blokeringen sket før webserveren – altså i firewall eller netværk.
Gem tidspunkt, tidszone, Ray ID, hostname og den SSL/TLS-mode, der var aktiv, da fejlen opstod. Bed derefter hosting om en kort servicekontrol for den tilsvarende port: kørte webserveren, lyttede den på den forventede adresse, og blev Cloudflare-forbindelsen afvist af serveren eller et sikkerhedslag? En skærm med “service running” alene er ikke nok; porten og tidspunktet skal passe til sagen.
Hvis en firewallregel er mistænkt, skal dokumentationen vise et redigeret rule-id eller en logkategori før ændringen og en accept efter. IP-adresser kan maskeres i materiale, der deles bredt. Den tekniker, der vedligeholder allowlisten, bør derimod have de aktuelle adresser fra sin autoritative driftskilde og ikke fra et gammelt screenshot.
Afslut med to eftertests: en offentlig request gennem Cloudflare og en kontrolleret origin-test med korrekt hostname og SNI. Begge skal ramme den tiltænkte virtual host. Notér samtidig, at ingen DNS-, SSL- eller firewallændring blev efterladt som midlertidig genvej. Det gør det muligt at skelne en reel løsning fra en fejl, der blot forsvandt under genstart.