Hvad er et CDN? Kantservere og cache forklaret

Kort svar: Et CDN (Content Delivery Network) er et net af servere fordelt over hele verden, der gemmer kopier af dit sites statiske filer – billeder, CSS og JavaScript – og udleverer dem fra den server, der er tættest på den besøgende. Resultatet er kortere afstand, lavere svartider og mindre belastning på din egen server. For et dansk site med danske kunder er hastighedsgevinsten ofte lille; for internationale besøgende, og som skjold mod trafiktoppe og angreb, kan den være betydelig.

Fagligt gennemgået: 2. oktober 2026

CDN er et af de ord, der dukker op i næsten alle samtaler om hastighed og sikkerhed – ofte som en løsning på problemer, det slet ikke løser. Her får du mekanikken forklaret, hvad et CDN kan og ikke kan, hvordan du ser, om det faktisk virker, og de faldgruber, der oftest giver fejl efter opsætningen.

Sådan virker et CDN

Din egen server kaldes origin. CDN’ets servere – kaldet edge- eller kantservere – står mellem origin og de besøgende. Første gang en fil efterspørges i fx Sydney, hentes den fra origin og gemmes på kantserveren dér. De næste besøgende i området får kopien direkte, uden turen hele vejen til origin.

Hver kopi har en levetid (TTL), som typisk styres af cache-control-headeren fra din server eller af regler i CDN’et. Når du ændrer en fil, kan du tvinge kopierne opdateret med en purge. Kendte eksempler er Cloudflare, der også lægger sikkerhed foran sitet, og QUIC.cloud, der er bygget til LiteSpeed-servere og også kan cache selve HTML’en – ikke kun de statiske filer.

Ud over cachen håndterer kantserveren som regel også krypteringen: den besøgendes browser laver TLS-forbindelsen til den nærmeste kant, og CDN’et taler derefter videre med origin over en genbrugt forbindelse. Mange CDN’er tilbyder samtidig nyere protokoller som HTTP/3 og komprimering med Brotli, uden at du skal ændre noget på serveren.

Hvad caches på kanten – og hvad gør ikke?

Indhold	Caches typisk på kanten?	Bemærkning
Billeder, CSS, JavaScript, fonte	Ja, som standard	Den klassiske CDN-opgave
Offentlige HTML-sider	Kun hvis du slår det til	Kræver en regel eller en tjeneste som Cloudflare APO eller QUIC.cloud-sidecache
Kurv, kasse, Min konto	Nej – må ikke	Personligt indhold skal altid hentes fra origin
wp-admin og indloggede brugere	Nej	Undtages via cookies og stier
Søgeresultater og formularer	Sjældent	Query strings og POST-requests går normalt til origin

Den store forskel ligger i HTML. Når kun de statiske filer caches, skal din server stadig bygge hver side. Caches HTML’en også, kan kanten svare på hele sidevisningen – men så skal du styre undtagelser og purge meget mere omhyggeligt.

Hvad et CDN ikke løser

Et CDN gør ikke en langsom hjemmeside hurtig – det gør en hurtig hjemmeside hurtig for flere. Dynamiske sider som kurv, checkout, wp-admin og personaliseret indhold kan typisk ikke caches på kanten, så deres hastighed afgøres stadig af origin: PHP, database og servercache.

Er problemet høj TTFB på dynamiske sider, skal løsningen findes i cache-lagene på serveren og i hastighedsoptimering – ikke i endnu et lag foran. Et fejlkonfigureret CDN kan oven i købet selv skabe problemer: forældede kopier efter opdateringer eller cache af sider, der aldrig burde have været delt mellem besøgende.

Hvad betyder det for dit site?

Tommelfingerreglen: dansk site, danske kunder og hurtig hosting betyder, at et CDN er valgfrit. Internationale besøgende, tunge billeder eller ønsket om et ekstra sikkerhedslag gør det oplagt.

Kører dit site på LiteSpeed – som hos Hostious – er QUIC.cloud en naturlig første kandidat, fordi cache-plugin og CDN taler samme sprog. Vælger du Cloudflare, viser Cloudflare-guiderne den sikre opsætning uden redirect-loops og cache-fælder.

Sådan ser du, om CDN’et svarer – og hvorfra

Et CDN afslører sig i svarets headere. Hent headerne for en fil to gange i træk:

curl -sI https://dit-domæne.dk/wp-content/uploads/billede.webp | grep -iE "cf-cache-status|cf-ray|x-qc-cache|x-cache|cache-control"

Cloudflare skriver cf-cache-status (fx HIT, MISS, DYNAMIC eller EXPIRED) og cf-ray, hvis sidste tre bogstaver er lufthavnskoden for den kantserver, der svarede – CPH for København, FRA for Frankfurt, LHR for London. QUIC.cloud og andre CDN’er har tilsvarende headere som x-qc-cache og x-cache.

Første kald er typisk et MISS (kanten hentede filen fra origin), andet kald et HIT. Ser du kun MISS, uanset hvor mange gange du kalder, cacher kanten ikke – ofte fordi origin sender cache-control: no-cache eller sætter en cookie på filen. Ser du DYNAMIC på HTML, er det forventet: de fleste CDN’er cacher ikke sider som standard.

En rigtig besøgendes oplevelse måler du med et værktøj, der tester fra flere lande. For et dansk site er tallet fra København eller Stockholm det, der tæller. Ligger origin i EU på en hurtig server, er forskellen med og uden CDN for danske besøgende ofte lille på billeder og ingen på HTML, der ikke caches på kanten.

CDN som skjold: DDoS, bots og WAF

For mange sites er sikkerheden den største grund til at lægge et CDN foran. Fordi al trafik går gennem kanten, kan den stoppe angreb, før de når din server: volumenangreb (DDoS) absorberes af et net, der er bygget til det, kendte skadelige robotter blokeres, og en web application firewall (WAF) filtrerer forespørgsler mod wp-login.php, xmlrpc.php og kendte plugin-sårbarheder.

Det kræver én ting for at virke: at din servers rigtige IP-adresse ikke er kendt. Peger et gammelt underdomæne (mail., ftp., direct.) stadig direkte på serveren, kan angribere gå uden om skjoldet. Tjek DNS-zonen for poster, der ikke går gennem CDN’et, og lad serverens firewall kun acceptere webtrafik fra CDN’ets IP-serier på port 80 og 443. Mailposter (MX) skal derimod aldrig proxies – de skal pege direkte på mailserveren.

Fire faldgruber, når CDN’et er sat op

• Uendelige omdirigeringer. Cloudflare i SSL-tilstanden Flexible taler http til din server, som omdirigerer til https, som Cloudflare igen henter over http. Brug Full (strict) med et gyldigt certifikat på origin.
• Forkerte IP-adresser i loggen. Alle besøgende ser ud til at komme fra CDN’ets adresser, så sikkerhedsplugins og statistik går i kludder. Serveren skal læse den rigtige IP fra CF-Connecting-IP eller X-Forwarded-For – og kun stole på de headere, når requesten kommer fra CDN’ets IP-serier.
• Cachet kurv. Sætter du en regel, der cacher HTML, skal kurv, kasse, Min konto og alt med WooCommerce-cookies undtages – ellers kan kunder se hinandens kurve og oplysninger.
• Gamle filer efter opdatering. Ændrer du et billede uden nyt filnavn, serverer kanten det gamle, til levetiden udløber. Purge filen, eller brug versionerede filnavne.

CDN og persondata

Når al trafik går gennem et CDN, behandler udbyderen de besøgendes IP-adresser og requestdata. Det gør CDN’et til en databehandler i GDPR-forstand, og du bør kende udbyderens databehandleraftale, hvor data behandles, og om der sker overførsel til lande uden for EU. Det er ikke en grund til at fravælge et CDN, men det hører med i vurderingen – især for offentlige kunder og brancher med strenge krav. Guiden om CDN og datasuverænitet gennemgår spørgsmålene.

Bruger du Cloudflare eller QUIC.cloud foran WordPress hosting, så kontrollér SSL-tilstand, cache-undtagelser og den rigtige besøgende-IP lige efter opsætningen – så bliver skjoldet ikke selv en fejlkilde. Dansk support døgnet rundt kan hjælpe, hvis noget ikke opfører sig som forventet.

Læs også

• Ordbog: Hosting-ordbogen
• Page cache, object cache og browser cache: hvem gør hvad?
• Cloudflare vs QUIC.cloud – hvad skal du vælge?
• Hvorfor viser CF-Cache-Status DYNAMIC, BYPASS eller MISS?
• Hastighedsoptimering hos Hostious – når origin selv skal være hurtigere

Ofte stillede spørgsmål om CDN

Gør et CDN mit site hurtigere i Danmark?

Kun lidt, hvis din server allerede står tæt på dine besøgende og svarer hurtigt. Gevinsten vokser med afstanden og med andelen af statiske filer. Mål før og efter frem for at antage.

Er CDN og cache det samme?

CDN er ét af flere cache-lag – det geografiske. Browser-, server- og objektcache arbejder tættere på din server og løser andre problemer. Lagene supplerer hinanden og erstatter ikke hinanden.

Hvorfor ser mit site gammelt ud efter en opdatering?

Fordi kantserverne stadig udleverer den gamle kopi. Løsningen er en purge af CDN-cachen efter større ændringer og en opsætning, hvor opdateringer automatisk udløser den.

Hvordan ser jeg, hvilken kantserver der svarede?

I Cloudflares cf-ray-header: de sidste tre bogstaver er lufthavnskoden for kantserveren, fx CPH for København eller FRA for Frankfurt. cf-cache-status viser samtidig, om filen kom fra kanten (HIT) eller fra din server (MISS).

Beskytter et CDN mod angreb, hvis min servers IP er kendt?

Kun delvist. Kan angribere finde serverens rigtige IP-adresse via gamle DNS-poster, går de uden om skjoldet. Fjern poster, der peger direkte på serveren, og lad firewallen kun acceptere webtrafik fra CDN’ets IP-serier.