wp-admin bag Cloudflare: cache-bypass og undtagelser, der virker

Kort svar: wp-admin skal have tre garantier bag Cloudflare: aldrig cache (en Cache Rule med bypass på /wp-admin/, wp-login.php og login-cookien), ingen challenges for redaktionen (en WAF-regel med Skip for jeres faste IP-adresser eller beskyttelse via Cloudflare Access) og fri passage for admin-ajax.php og REST-kaldene, som editoren bruger. Får du de tre på plads, forsvinder de klassiske spøgelser: udløbne login-tokens, captcha midt i arbejdet og en editor, der ikke kan gemme.

Fagligt gennemgået: 2. oktober 2026

Cloudflare beskytter forsiden glimrende, men wp-admin har andre behov end forsiden. Bag proxyen opstår tre typiske gener for redaktionen: login-sider fra cache med udløbne tokens, challenges der afbryder arbejdet, og gemmefejl, fordi sikkerhedslaget fanger editorens baggrundskald. Alle tre kan løses med målrettede regler – uden at åbne noget for offentligheden.

Guiden gennemgår først, hvordan du genkender hvilket af de tre problemer, du har. Derefter kommer reglerne én ad gangen, og til sidst hvordan du verificerer og ruller tilbage. Cloudflares dashboard omdøber og flytter menuer jævnligt, så navnene nedenfor er de funktioner, du skal finde – ikke nødvendigvis den præcise menusti i din konto.

Før du ændrer noget: Notér de regler, der allerede ligger under Cache Rules, WAF custom rules og eventuelle Configuration Rules, inklusive rækkefølgen. Lav én ændring ad gangen, og test efter hver. Så kan du altid rulle præcis den ene regel tilbage, hvis noget går galt.

1. Find ud af, hvilket problem du har

Symptomerne i wp-admin ligner hinanden, men årsagerne er forskellige. Start med at tjekke cache-headeren og Cloudflares sikkerhedshændelser, før du laver nye regler.

Symptom	Sandsynlig årsag	Sådan bekræfter du det
—	—	—
Du bliver logget ud, eller login-formularen siger, at sessionen er udløbet	Login-siden eller admin-HTML er serveret fra cache	cf-cache-status: HIT på wp-login.php eller en admin-side
Captcha eller „Verifying you are human“ midt i arbejdet	En WAF-regel, Bot Fight Mode eller en challenge rammer redaktøren	Hændelsen står i Security Events med regel-ID og din IP
„Opdatering mislykkedes“ eller „Not a valid JSON response“ i editoren	REST- eller admin-ajax.php-kald bliver blokeret eller udfordret	Browserens Network-fane viser 403 eller en HTML-challenge i stedet for JSON
Knapper og menuer i wp-admin virker ikke	En hastighedsfunktion som Rocket Loader ændrer admin-scripts	Fejl i browserkonsollen, der forsvinder, når funktionen er slået fra

Du kan tjekke cache-headeren direkte fra en terminal. Svaret skal vise DYNAMIC eller BYPASS – aldrig HIT:

curl -sI https://ditdomæne.dk/wp-login.php | grep -i cf-cache-status

2. Garanti 1: Aldrig cache på admin

Som standard cacher Cloudflare ikke HTML – så på en ny opsætning er admin allerede sikker. Problemet opstår, når der bygges Cache Rules med „cache everything“ (Eligible for cache på alle sider): så skal admin-stierne eksplicit undtages, ellers ender login-sider og admin-HTML i cachen. Reglen, der løser det, oprettes under Cache Rules i zonens caching-indstillinger:

Udtrykket i reglen kan se sådan ud, med handlingen Bypass cache:

(starts_with(http.request.uri.path, "/wp-admin/"))
or (http.request.uri.path eq "/wp-login.php")
or (http.cookie contains "wordpress_logged_in")

Bemærk rækkefølgen: Cloudflare evaluerer Cache Rules oppefra, og når flere regler matcher, vinder den senere regel ved modstridende indstillinger. Placér derfor bypass-reglen efter „cache everything“-reglen, så den ikke overskrives – eller undtag admin-stierne direkte i selve cache-reglens udtryk. Test bagefter med curl-kommandoen ovenfor.

Cookie-betingelsen (wordpress_logged_in) sikrer, at indloggede brugere aldrig får cachede sider – heller ikke på frontend, hvor de ellers ville se en cachet version uden admin-bjælke eller med forkerte forhåndsvisninger. Hele WooCommerce-varianten af samme øvelse, med kurv og checkout, står i Cache Rules-guiden til WooCommerce.

Pas også på indstillingen, der tilsidesætter originens Cache-Control-headere (Edge TTL sat til at ignorere originen). WordPress sender selv no-cache-headere på admin og login, og dem respekterer Cloudflare som udgangspunkt. Tvinger du en fast Edge TTL på alt, sætter du den beskyttelse ud af spil.

3. Garanti 2: Ingen challenges for redaktionen

Sikkerhedsregler må gerne være strenge på login-stien – bare ikke for jer selv. Den rene løsning er en WAF custom rule med handlingen Skip, der undtager jeres faste kontor- eller hjemme-IP-adresser fra de øvrige regler på /wp-login.php og /wp-admin/:

(http.request.uri.path eq "/wp-login.php"
 or starts_with(http.request.uri.path, "/wp-admin/"))
and ip.src in {203.0.113.10 198.51.100.0/24}

IP-adresserne ovenfor er eksempeladresser – udskift dem med jeres egne. Skip-reglen skal stå over de regler, den skal springe over, og du vælger selv, hvad den springer over: de resterende custom rules, rate limiting, managed rules og Super Bot Fight Mode. Ifølge Cloudflares dokumentation kan den gratis Bot Fight Mode derimod ikke springes over med en Skip-regel. Driller den redaktionen, er alternativet at slå den fra eller opgradere til en plan med Super Bot Fight Mode, hvor undtagelser er mulige. Se også guiden om Bot Fight Mode.

Har I skiftende IP-adresser, er der to bedre veje end interaktive captchas:

• Cloudflare Access: kræver login via e-mailkode eller jeres identitetsudbyder, før wp-admin overhovedet nås. Undtag /wp-admin/admin-ajax.php fra Access-applikationen, da mange temaer og plugins kalder den fra frontend for anonyme besøgende.
• Managed Challenge: løses oftest usynligt i browseren og er langt mindre forstyrrende end et interaktivt captcha på login.

Baggrunden om challenge-typerne står i challenge-guiden.

Husk også serversiden: Hvis et sikkerhedsplugin i WordPress ser Cloudflares IP-adresser i stedet for de besøgendes, kan én mistænkelig bot låse alle ude, fordi alle ser ud til at komme fra samme få adresser. Sørg for, at serveren gendanner den rigtige besøgende-IP, som beskrevet i guiden om rigtige IP-adresser bag Cloudflare.

4. Garanti 3: Fri passage for editorens kald

Blok-editoren gemmer via REST (/wp-json/), og mange plugins arbejder gennem admin-ajax.php. WordPress’ Heartbeat-API sender desuden baggrundskald med faste intervaller, mens du arbejder, for at holde sessionen i live og låse indlæg, så to redaktører ikke overskriver hinanden. Rammer en WAF-regel eller rate limiting de stier, får redaktører „Opdatering mislykkedes“-fejl, selvom siden ser normal ud.

Fremgangsmåden, når editoren driller:

1. Åbn browserens udviklerværktøjer på fanen Network, og gem en ændring i editoren.
2. Find det fejlende kald til /wp-json/ eller admin-ajax.php, og notér statuskode og tidspunkt.
3. Find samme tidspunkt i Cloudflares Security Events, og notér regel-ID og handling.
4. Lav en præcis undtagelse for netop den regel – fx sti plus jeres IP eller login-cookie – i stedet for at slukke reglen.

Svarer kaldet med en HTML-side i stedet for JSON, er det næsten altid en challenge eller blokering, der er sluppet ind foran WordPress. Fejlbilledet i WordPress er beskrevet i JSON-fejlguiden og REST API-guiden.

5. Slå hastighedsfunktioner fra i admin

Nogle af Cloudflares hastighedsfunktioner omskriver HTML og JavaScript undervejs. Det er fint på forsiden, men kan ødelægge wp-admin, hvor scripts er tæt koblet til hinanden. Den mest kendte synder er Rocket Loader, som udskyder JavaScript og kan få menuer, mediebibliotek og page builders til at gå i stå.

Med en Configuration Rule kan du slå den slags funktioner fra på /wp-admin/ og wp-login.php uden at røre resten af sitet. Brug samme udtryk som i bypass-reglen, og slå Rocket Loader og eventuelle andre HTML-omskrivende funktioner fra for de stier. Detaljerne står i guiden om Rocket Loader.

Hvad du ikke skal gøre

• Sæt ikke wp-admin på grå sky: At tage admin ud af proxyen afslører serverens IP og fjerner beskyttelsen. Undtagelser i reglerne er den rigtige vej.
• Slå ikke hele WAF’en fra, fordi én editor-request blev blokeret. Find regel-ID’et i Security Events, og undtag præcist.
• Læg ikke rate limiting på admin-ajax uden måling: Én travl redaktør kan generere mange legitime kald i minuttet, og Heartbeat kommer oveni.
• Kopiér ikke en IP-liste fra en gammel artikel: Undtagelser skal pege på jeres egne, aktuelle adresser og vedligeholdes, når I skifter internetforbindelse.

Sådan verificerer du

Opsætningen holder, når alle punkter nedenfor er opfyldt:

• wp-login.php og en admin-side viser aldrig cf-cache-status: HIT.
• Redaktører kan logge ind og arbejde en hel session uden challenges.
• Editoren gemmer uden fejl, og konsollen viser ingen blokerede REST-kald.
• Security Events viser ingen blokeringer af jeres egne IP-adresser.
• Mediebibliotek, menuer og eventuel page builder virker som uden Cloudflare.

Test fra både kontoret og mobilnettet – og gentag tjekket, når I strammer sikkerheden. Hver ny regel skal bevise, at den ikke rammer redaktionen.

Rul tilbage

Går noget galt efter en ændring, så deaktivér den ene regel, du lige har oprettet eller ændret – ikke hele WAF’en eller cachen. Cloudflare lader dig slå enkeltregler fra uden at slette dem, så du kan genaktivere dem efter rettelsen. Har du ryddet cachen undervejs, så purge igen efter tilbagerulningen, så ingen gamle admin-svar ligger tilbage.

Læs også

• Hub: Cloudflare til WordPress
• Cloudflare Cache Rules til WooCommerce
• Besøgende møder captcha eller challenge
• Login-loop og cookies
• WordPress REST API-fejl
• WordPress hosting hos Hostious – LiteSpeed, NVMe og dansk support døgnet rundt

Ofte stillede spørgsmål om wp-admin bag Cloudflare

Skal jeg skjule wp-admin bag en anden URL?

Det er valgfrit og primært støjreduktion – botterne stopper ikke af det. Kombinationen af stærke kodeord, totrinslogin og Cloudflares regler beskytter reelt; en flyttet login-URL skal blot huskes i alle undtagelser.

Hvorfor bliver jeg logget ud hele tiden bag Cloudflare?

Det klassiske tegn på, at login-sider rammer cachen – eller at en regel fjerner cookies. Tjek cache-status på wp-login.php først; mekanikken er den samme som i login-loop-guiden.

Kan jeg låse wp-admin til kun danske IP-adresser?

Ja – en WAF-regel kan challenge eller blokere login-stien for alle lande undtagen Danmark. Husk bare rejser og udenlandske samarbejdspartnere: Managed Challenge er mere tilgivende end en blokering.

Hvorfor virker min Skip-regel ikke mod Bot Fight Mode?

Fordi den gratis Bot Fight Mode ifølge Cloudflares dokumentation ikke kan springes over med en Skip-regel. Slå den fra, hvis den rammer redaktionen, eller brug en plan med Super Bot Fight Mode, hvor undtagelser er mulige.