Cloudflare Error 520 på WordPress: ukendt svar fra origin

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.

Bekræft, at det faktisk er en 520

Gem disse fire oplysninger, før du genindlæser:

1. den præcise URL, inklusive query string hvis den er relevant;
2. lokalt klokkeslæt og tidszone;
3. Cloudflare Error 520 fra fejlsiden;
4. Ray ID og det viste Cloudflare-datacenter.

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

Beslutningsflow

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.

Løsning 1: find den første relevante loghændelse

Start ved serverens error log og PHP-log med det gemte tidspunkt. Se efter:

• PHP fatal error eller worker, der blev afsluttet;
• webserver, der blev genstartet eller nåede en grænse;
• sikkerhedssoftware, der afviste Cloudflare-IP;
• forbindelse, der blev lukket uden statuslinje eller body;
• plugin- eller tema-hook, som kun kører på den berørte URL.

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.

Løsning 2: undersøg cookies og response headers

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.

Løsning 3: kontrollér firewall og Cloudflare-trafik

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.

Løsning 4: HTTP/2 til origin og Authenticated Origin Pulls

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.

Løsning 5: brug DNS only kun som kontrolleret diagnose

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.

Sådan eftertester du

• Den oprindeligt fejlende URL svarer tre gange i træk uden 520.
• En privat browser og en normal browser giver samme korrekte resultat.
• En statisk fil og en dynamisk WordPress-side svarer korrekt.
• Der kommer ingen ny fatal-, reset- eller firewallhændelse i loggen ved testen.
• Cloudflare-proxyen er aktiv igen, hvis den kortvarigt blev ændret.
• Login, formular og eventuel checkout virker; en rettelse må ikke kun få forsiden online.

Rul tilbage

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”.

Hvornår skal hosting eller udvikler hjælpe?

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.

Ofte stillede spørgsmål om Error 520

Hvad betyder Cloudflare Error 520?

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.

Hvad er de typiske årsager til 520 på WordPress?

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.

Hvordan tester jeg origin uden om Cloudflare?

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.

Læs også

• Hvis origin afviser forbindelsen, brug Cloudflare Error 521.
• Hvis forbindelsen slet ikke bliver etableret i tide, brug Cloudflare Error 522.
• Hvis origin er for langsom efter en vellykket forbindelse, brug Cloudflare Error 524.
• En almindelig upstream-fejl uden Cloudflare-branding hører til guiden om 502 Bad Gateway i WordPress.
• Find hele rækkefølgen i Cloudflare-guides til WordPress.
• WordPress hosting hos Hostious – hosting der er hurtig uden ekstra lag ovenpå

Sådan dokumenterer du din egen 520-sag

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.