Cloudflare-indstillinger til WordPress: sikker basisopsætning

Kort svar: Start med at få DNS og HTTPS rigtigt, før du tænder flere hastigheds- eller sikkerhedsfunktioner. Webtrafik skal normalt være proxied, mailposter skal være DNS only, og forbindelsen til serveren bør bruge Full (strict), når origin-certifikatet er gyldigt. Lad dynamiske WordPress- og WooCommerce-sider gå uden om fuld sidecache. Skift én indstilling ad gangen, og kontrollér både en offentlig side, login og formularer efter hvert trin.

Risiko: Lav til høj, afhængigt af indstillingen Forventet tid: 30-60 minutter til en basisopsætning Hav klar: Cloudflare-adgang, hostingadgang, en frisk backup og en liste over domænets web- og mailposter

Fagligt gennemgået: 2. oktober 2026Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151. Hostious er ikke bag Cloudflare på gennemgangstidspunktet, så Cloudflare-forløbet er fagligt kontrolleret mod den aktuelle produktlogik og skal verificeres i din egen zone. Eventuelle testillustrationer fra Hostious Article Lab er syntetiske stagingeksempler, ikke bevis fra Cloudflare eller Hostious-produktion.

Cloudflare står mellem den besøgende og din WordPress-server. Det giver mulighed for at filtrere trafik, afslutte TLS-forbindelser og levere cachede filer tættere på brugeren. Det betyder også, at en forkert DNS-, SSL- eller cacheregel kan ramme hele siden på én gang. Den bedste opsætning er derfor ikke den med flest aktive funktioner, men den hvor hver funktion har et tydeligt formål og en eftertest.

Denne guide er basisopsætningen. Fejlkoder som 520, 521, 522 og 524 har deres egne diagnoseflows, fordi de ikke løses ved tilfældigt at skifte indstillinger.

Før du ændrer noget

Notér den nuværende værdi for hver indstilling, du vil ændre. Tag skærmbilleder af DNS-oversigten uden at vise origin-IP, og eksportér DNS-zonen, hvis din konto giver mulighed for det. Sørg også for, at du kan nå hostingpanelet uden at være afhængig af selve WordPress-siden.

Kontrollér derefter:

1. at WordPress-adresse og webstedsadresse bruger det ønskede HTTPS-domæne;
2. at serveren svarer på HTTPS med et certifikat til det rigtige værtsnavn;
3. at mail, verifikationer og andre ikke-webtjenester er identificeret;
4. at du ved, hvilke sider der er dynamiske, eksempelvis login, kurv, checkout og Min konto;
5. at der ikke allerede ligger overlappende redirects eller cache-regler i Cloudflare, WordPress og på serveren.

DNS: orange sky til webtrafik, grå sky til de rigtige undtagelser

En orange sky betyder, at HTTP- og HTTPS-trafikken går gennem Cloudflare. Det er normalt det rigtige valg for domænets A-, AAAA- og CNAME-poster, når de viser selve websitet. En grå sky betyder DNS only: DNS-opslaget afslører den faktiske destination, og Cloudflare leverer hverken webcache, WAF eller proxybeskyttelse for værtsnavnet.

Brug som udgangspunkt:

Postens funktion	Normal proxy-status	Hvorfor
Hoveddomæne og www med WordPress	Proxied	Webtrafikken skal gennem Cloudflare
Separat web-subdomæne	Proxied, hvis tjenesten understøtter det	Giver Cloudflare-funktioner på værtsnavnet
MX og TXT	Kan ikke proxieres	De er DNS-poster, ikke HTTP-trafik
mail, SMTP, IMAP eller anden ikke-HTTP-tjeneste	DNS only	Cloudflares almindelige proxy er ikke en mailproxy
CNAME til en ekstern SaaS-verifikation	DNS only, medmindre leverandøren siger andet	En orange sky kan forhindre validering eller routing

Skift ikke webdomænet til DNS only som permanent problemløsning. Det kan være en kort og kontrolleret diagnose, men eksponerer origin-adressen og fjerner Cloudflares beskyttelseslag.

SSL/TLS: vælg Full (strict), når origin er klar

Cloudflare håndterer to separate forbindelser: browser til Cloudflare og Cloudflare til din server. Et grønt hængelåsikon i browseren beviser derfor ikke alene, at den sidste del er korrekt beskyttet.

Full (strict) er det sikre mål. Her bruger Cloudflare HTTPS til origin og kontrollerer, at certifikatet ikke er udløbet, passer til værtsnavnet og kan valideres. Indstillingen kræver, at serveren lytter på port 443 og leverer en komplet certifikatkæde.

Undgå Flexible på en normal WordPress-side, der allerede tvinger HTTPS på serveren. Cloudflare sender i den tilstand HTTP til origin, og serverens tvungne HTTPS kan sende anmodningen tilbage i en uendelig redirect-loop.

Før du tænder HSTS, skal HTTPS virke stabilt på hoveddomænet og alle subdomæner, som politikken skal omfatte. HSTS lagres i browseren. En fejl kan derfor ikke altid rulles tilbage øjeblikkeligt, selv om du slår indstillingen fra igen.

Redirects: vælg ét tydeligt ansvar

En typisk stabil model er:

• Cloudflare sender HTTP til HTTPS med én regel eller Always Use HTTPS;
• WordPress bruger HTTPS i begge URL-felter;
• serveren accepterer HTTPS og sender ikke trafikken tilbage til HTTP;
• kun ét lag håndterer www til ikke-www eller omvendt.

Hvis både Cloudflare, serveren, et redirect-plugin og WordPress forsøger at normalisere den samme URL, bliver fejlsøgningen unødigt svær. Brug browserens netværksfane eller en headerkontrol til at følge hvert Location-hop. Den ønskede kæde er normalt højst ét permanent hop til den kanoniske URL og derefter 200 OK.

Cache: statiske filer først, HTML kun med en plan

Cloudflare cacher normalt kendte statiske filtyper. HTML bliver ikke automatisk en sikker fuld sidecache, blot fordi domænet er proxied. Hvis du aktivt gør HTML cache-egnet med Cache Rules eller en WordPress-integration, skal du først definere undtagelser.

Hold som minimum disse områder dynamiske:

• /wp-admin/ og WordPress-login;
• forhåndsvisninger og administrative forespørgsler;
• REST- eller API-kald, der ændrer data;
• WooCommerce-kurv, checkout og Min konto;
• besøgende med login- eller WooCommerce-sessioncookies.

Kontrollér ikke cache med et pluginbadge. Se i det faktiske svar: CF-Cache-Status fortæller, hvad Cloudflare gjorde, mens originens egne cacheheaders fortæller, hvad serveren bad om. HIT er passende for en offentlig cache-egnet side eller statisk fil, men er et faresignal på en personlig kurv eller en kontoside.

Hastighed: aktivér kun funktioner, du kan regressionsteste

HTTP/3 kan forbedre forbindelsen mellem besøgende og Cloudflare på netværk med pakketab. Det ændrer ikke forbindelsen fra Cloudflare til din WordPress-server. Komprimering og protokoloptimering er normalt lavrisiko, men de skal stadig måles med faktiske requests.

JavaScript-omskrivning som Rocket Loader kan ændre afviklingsrækkefølgen. På WordPress-sider med builders, samtykkeløsninger, formularer eller WooCommerce bør den være slukket, indtil en stagingtest viser, at menu, formular, kurv, checkout og tracking stadig virker. Kombinér heller ikke flere aggressive optimeringslag uden en klar ejer; to systemer, der begge udsætter JavaScript eller omskriver HTML, gør fejl sværere at isolere.

WAF og botbeskyttelse: se hændelsen før du laver en undtagelse

Brug den administrerede regelpakke, der passer til din plan, med standardhandlinger som udgangspunkt. Hvis en legitim WordPress-funktion blokeres, skal du finde den konkrete sikkerhedshændelse og regel-id'et. Lav derefter den smallest mulige undtagelse på den nødvendige sti, metode eller funktion.

Undgå brede regler som “skip al sikkerhed på /wp-admin/”. De fjerner beskyttelsen netop dér, hvor angreb ofte rammer. En god undtagelse beskriver den legitime request, har en begrænset matchbetingelse og eftertestes mod både den tilladte handling og en normal anonym request.

En sikker ændringsrækkefølge

1. Bekræft DNS-posterne uden at ændre dem.
2. Test originens HTTPS og certifikat gennem hostingudbyderen.
3. Sæt SSL/TLS til Full (strict), når forudsætningerne er opfyldt.
4. Normalisér HTTPS og værtsnavn med én redirect-ejer.
5. Kontrollér offentlig side, WordPress-login, REST API og formular.
6. Aktivér cache for statiske filer og verificér response headers.
7. Tilføj eventuel HTML-cache sammen med bypass-regler.
8. Aktivér sikkerheds- og hastighedsfunktioner én ad gangen.
9. Gem et før/efter-notat med klokkeslæt, indstilling og testresultat.

Sådan eftertester du opsætningen

• Hoveddomænet svarer med HTTPS og ender på den valgte kanoniske URL.
• En HTTP-request har en kort, forståelig redirect-kæde.
• Origin-certifikatet kan valideres i Full (strict).
• Offentlige statiske filer viser forventet Cloudflare-cacheadfærd.
• Login, WordPress-editor, formularer og REST API virker.
• En WooCommerce-test kan tilføje en vare, opdatere kurven og åbne checkout uden at vise en anden sessions data.
• Sikkerhedshændelser viser ingen ny blokering af legitime admin- eller checkout-requests.
• Serverloggen registrerer den rigtige klient-IP via en korrekt betroet proxyopsætning; du har ikke blot erstattet alle besøgende med en Cloudflare-IP.

Rul tilbage

Rul kun den seneste ændring tilbage, og test igen. Hvis du ændrede en Cache Rule, deaktivér eller gendan netop den regel. Hvis SSL-skiftet gav 525 eller 526, skal certifikatet på origin rettes; en midlertidig mindre streng tilstand må ikke blive den skjulte permanente løsning. Slå ikke hele Cloudflare fra, medmindre du på forhånd har kontrolleret origin-kapacitet, offentligt certifikat og konsekvensen af at eksponere serverens adresse.

Hvornår skal hosting eller udvikler hjælpe?

Kontakt hosting, når origin ikke svarer på port 80/443, certifikatkæden er forkert, Cloudflare-IP'er blokeres, eller serverlog og ressourceforbrug skal undersøges. En udvikler bør se på gentagne redirect-loops, cache af personligt indhold, REST-fejl og JavaScript-regressioner. Hvis du vil samle server-, WordPress- og cacheansvaret ét sted, kan du læse om WordPress-hosting hos Hostious.

Ofte stillede spørgsmål om Cloudflare og WordPress

Hvilken SSL-tilstand skal Cloudflare stå i til WordPress?

Full (strict), så snart origin-serveren har et gyldigt certifikat. Flexible giver redirect-løkker og sender trafik ukrypteret til serveren, så den bør kun være en midlertidig nødløsning.

Skal alle DNS-poster have orange sky?

Nej. Webtrafik (A-, AAAA- og CNAME-poster til sitet) skal være proxied, mens mail- og verifikationsposter skal stå til DNS only. En proxied mailpost er en klassisk årsag til post, der pludselig fejler.

Må Cloudflare cache HTML på en WordPress-side?

Kun med en plan. Statiske filer kan caches frit, men HTML på login, kurv og checkout skal undtages. Uden bypass-regler risikerer du at vise én kundes indhold til en anden.

Læs også

• Start ved Cloudflare DNS: orange eller grå sky, hvis du er i tvivl om proxy-status.
• Brug Cloudflare 525 og 526, når fejlen handler om forbindelsen til origin-certifikatet.
• Se CF-Cache-Status: DYNAMIC, BYPASS og MISS, før du ændrer cachen.
• På en webshop skal du følge Cloudflare Cache Rules til WooCommerce.
• Hele emnet er samlet i Cloudflare-guides til WordPress.
• WordPress hosting hos Hostious – hosting der er hurtig uden ekstra lag ovenpå

Sådan dokumenterer du din egen opsætning

Tag et billede eller en eksport før hver ændring, men beskær altid konto-id, zone-id, origin-adresse og andre interne oplysninger væk. Til en basisopsætning er fem registreringer nok: DNS-postens navn og proxy-status, den valgte SSL/TLS-mode, den regel der påvirker cachen, et headerudsnit fra en offentlig side og resultatet af en funktionsprøve på login eller formular.

Notér ændringen i en enkel log med klokkeslæt, gammel værdi, ny værdi og rollback. Skriv for eksempel: “14.20: SSL-mode Full → Full (strict); forside 200, login 200, certifikat accepteret; rollback: Full.” Så kan du knytte en efterfølgende fejl til det rigtige trin i stedet for at forsøge at huske hele dashboardet.

Dokumentationen er stærk, når den viser både den tekniske respons og brugerens oplevelse. En korrekt header er ikke nok, hvis formularen fejler; en side, der ser rigtig ud, beviser heller ikke, at origin-certifikatet eller cachegrænsen er korrekt. Gem derfor altid ét maskinelt signal og én konkret funktionstest pr. ændring.