Kort svar: En 520 betyder, at Cloudflare fik et tomt, ugyldigt eller uventet svar fra origin-serveren. Gem URL, tidspunkt, tidszone og Ray ID, og kontrollér server- og PHP-log på samme tidspunkt. Et privat vindue kan vise et cookieafhængigt mønster, men beviser ikke årsagen. Store requestheaders giver typisk 413; ved 520 undersøges især originens responseheaders, eksempelvis mange
Set-Cookie, samt tidlige afbrudte svar.
Risiko: Middel Forventet tid: 20-60 minutter Hav klar: Fejlens Ray ID og klokkeslæt, adgang til serverlog og mulighed for en sikker origin-test
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Fejlklassifikationen er gennemgået fagligt; Hostious er ikke bag Cloudflare, og der er ikke fremprovokeret en 520 i produktion. Et eventuelt syntetisk stagingeksempel viser derfor kun symptomet og aldrig årsagen i en virkelig Cloudflare-zone.
En 520 er Cloudflares samlebetegnelse for et origin-svar, som ikke kan behandles som et normalt HTTP-svar. Det er ikke det samme som, at Cloudflare har bevist en bestemt WordPress-fejl. PHP kan være stoppet, webserveren kan have lukket forbindelsen, originens responseheaders kan være for store, eller en firewall kan have behandlet Cloudflare-trafik anderledes end direkte trafik.
På denne side
Gem disse fire oplysninger, før du genindlæser:
Cloudflare Error 520 fra fejlsiden;En almindelig WordPress-500-side eller en 502 fra webserveren har et andet diagnoseflow. Hvis fejlen kun ses af én browser eller én bruger, er et cookie- eller sessionsafhængigt programflow mere sandsynligt end et globalt servernedbrud. Det fortæller endnu ikke, om fejlen ligger i requesten, det svar WordPress genererer eller et efterfølgende proxyled.
| Observation | Sandsynlig retning | Sikker kontrol | Næste skridt |
|---|---|---|---|
| 520 på alle sider | Webserver, firewall eller origin-protokol | Sammenhold Ray-tidspunkt med webserverlog | Kontrollér service og Cloudflare-adgang |
| 520 kun på én WordPress-handling | PHP-fatal, plugin eller stor response header | Find requesten i PHP-/webserverlog | Ret den konkrete kode eller headerkilde |
| Virker i privat vindue | Cookie- eller sessionsafhængigt programflow | Sammenlign cookienavne samt originens responseheaders uden værdier | Find komponenten; privat vindue er et signal, ikke et årsagsbevis |
| Kun proxied trafik fejler | Firewall, HTTP/2 til origin eller origin pull | Hosting tester samme hostname med korrekt SNI | Ret originens proxyforudsætninger |
| Fejlen er kortvarig under belastning | Worker-/PHP-crash eller ressourcepres | Ressourcegraf og log på samme minut | Find processen, ikke blot symptomet |
Er fejlen global? Test en offentlig HTML-side og en statisk fil. Hvis begge fejler, start ved webserver, netværk og firewall. Hvis kun en dynamisk WordPress-URL fejler, gå direkte til PHP-log og den handling, der udløser requesten.
Ændrer privat vindue resultatet? Hvis ja, undersøg cookie- og sessionsflowet, men konkludér ikke, at requestens cookies alene skabte en 520. Cloudflare afviser typisk for store requestheaders med 413. En 520 kan derimod skyldes for store responseheaders fra origin, eksempelvis mange eller store Set-Cookie-felter. Gem antal og samlet størrelse, aldrig værdierne.
Kan hosting reproducere mod origin? En korrekt origin-test skal bruge det rigtige værtsnavn og SNI. Et råt kald til IP-adressen kan ramme forkert virtual host og give et misvisende resultat. Origin-IP må ikke skrives i artiklen eller et offentligt screenshot.
Start ved serverens error log og PHP-log med det gemte tidspunkt. Se efter:
Ret den første konkrete fejl i kæden. Hvis loggen for eksempel viser en fatal fejl i et plugin, er den sikre test at deaktivere netop det plugin på staging eller rulle den seneste ændring tilbage. At øge memory_limit kan skjule problemet, hvis årsagen er en løkke eller en fejlbehæftet forespørgsel.
Cloudflare dokumenterer responseheaders over den understøttede grænse som en 520-årsag. Origin kan eksempelvis sende mange eller store Set-Cookie-felter fra plugins, samtykkeløsninger, splittests eller sessioner. For store requestheaders er en anden fejlklasse og giver typisk 413. Hold derfor request- og responsesiden adskilt i målingen.
Test URL'en i et nyt privat vindue. Hvis fejlen forsvinder, har du et nyttigt signal om et cookie- eller sessionsafhængigt flow, men ikke bevis for hvilken header der overskred en grænse. Du kan rydde domænets cookies i den berørte testbrowser og gentage, men den egentlige opgave er at finde komponenten, der ændrer originens svar. Brug browserens Network-panel og originloggen til at notere antal, samlet headerstørrelse og cookienavne; skær værdier, bruger-id'er og tokens væk fra screenshots.
Origin kan også sende usædvanligt store eller fejlformede response headers. Hosting kan sammenligne et normalt 200-svar med den fejlende route. Kig særligt efter gentagne Set-Cookie, duplikerede redirects og headers genereret af cache- eller sikkerhedslag.
Originens firewall, rate limit eller sikkerhedsplugin må ikke blokere legitime Cloudflare-forbindelser. Hosting bør kontrollere, om alle aktuelle Cloudflare-IP-ranges er tilladt, og om serveren samtidig bevarer den rigtige besøgende-IP gennem en betroet proxykonfiguration.
Lav ikke en global allow-regel baseret på en IP-liste kopieret fra en gammel artikel. Listen skal hentes og vedligeholdes af den ansvarlige driftsfunktion. Deaktiver heller ikke WordPress-sikkerhed permanent; afgræns testen til den konkrete regel og det konkrete tidspunkt.
En origin kan annoncere HTTP/2 og alligevel håndtere forbindelsen forkert. Hvis log og headerkontrol ikke forklarer fejlen, kan du i Cloudflare midlertidigt slå HTTP/2 to Origin fra som en afgrænset test. Hvis 520 forsvinder, er den langsigtede løsning at rette webserverens HTTP/2-konfiguration eller beholde funktionen slukket, indtil serveren er opgraderet.
Hvis Authenticated Origin Pulls er aktiv, skal origin være konfigureret til at validere forbindelsen korrekt. En halvfærdig opsætning kan afvise Cloudflare. Sammenlign Cloudflare-indstillingen med webserverens certifikat- og klientvalidering; slå ikke bare sikkerhedslaget permanent fra.
At sætte posten til DNS only kan vise, om problemet kun opstår gennem Cloudflare, men handlingen eksponerer origin-IP og fjerner WAF- og DDoS-laget. Før testen skal du vide, om origin-certifikatet er offentligt gyldigt, og om serveren kan håndtere direkte trafik. Brug helst en sikker origin-test fra hosting i stedet.
Hvis en kort test er nødvendig, notér starttid, gendan proxy-status straks efter kontrollen, og verificér at DNS igen svarer med Cloudflare-adresser. Del aldrig origin-IP i en supportsag eller et screenshot, der bliver offentliggjort.
Gendan den ene ændring, du netop testede: genaktivér den konkrete pluginversion, gendan den ændrede webserverindstilling eller slå HTTP/2 to Origin tilbage til udgangspunktet. Hvis årsagen kommer igen efter rollback, har du et stærkt bevis. Gendan aldrig store cookie-værdier eller en kendt defekt kodeændring blot for at “bevare opsætningen”.
Hosting skal involveres, når origin lukker forbindelsen, worker-processer crasher, firewall rammer Cloudflare eller en sikker SNI-test kræver serveradgang. En udvikler skal ind, når 520 følger en bestemt WordPress-action, plugin-hook eller session. WordPress-hosting hos Hostious kan være relevant, hvis du vil have server- og WordPress-fejlen undersøgt samlet.
At origin-serveren svarede tomt, ugyldigt eller uventet på Cloudflares request. Fejlen ligger næsten altid på serveren eller i dens svar – ikke hos Cloudflare selv.
PHP-nedbrud midt i svaret, for store headers eller cookies, en webserver der resetter forbindelsen, eller sikkerhedssoftware der klipper svaret. Serverloggen på samme tidspunkt som Ray ID’et afslører det.
Slå op mod serverens IP direkte (fx via hosts-fil eller curl med –resolve) og sammenlign svaret. Svarer origin korrekt direkte, ligger problemet i størrelsen eller formen på svaret, som Cloudflare afviser.
Opret én række pr. hændelse med URL, lokal tid og tidszone, Ray ID, om brugeren var indlogget, og hvilken handling der blev udført. Tilføj den første relevante linje fra webserver- eller PHP-loggen på samme tidspunkt. Kopiér ikke hele loggen; den ene tidsmæssigt matchende hændelse er mere nyttig end hundrede linjer uden sammenhæng.
Hvis fejlen afhænger af cookies, så notér kun cookienavne og den samlede størrelse på request- og responseheaders. Værdier, tokens og session-id'er skal fjernes. Husk at en stor request normalt peger mod 413, mens 520-analysen især skal undersøge et afbrudt eller ugyldigt origin-svar og usædvanligt store responseheaders.
En god sag til hosting indeholder et fejleksempel og en negativ kontrol: samme hostname og path, men en request som virker. Skriv også, om statiske filer virker, og om fejlen kan reproduceres sikkert mod origin med korrekt Host og SNI. Så kan driftsteamet skelne mellem webserver, PHP, firewall og en bestemt WordPress-handling uden at starte med brede ændringer.