CDN einrichten: in sieben Schritten zum ersten Cache-Treffer

Bei den meisten CDN-Anbietern folgt die Einrichtung demselben Muster. Dein eigener Webserver bleibt die Quelle der Inhalte, im Fachjargon heißt er Origin. Das CDN stellt sich davor, holt Dateien beim ersten Abruf dort ab und hält Kopien an vielen Standorten bereit ^[1]. Was dabei technisch passiert, erklärt der Beitrag Was ist ein CDN?. Hier geht es um die Handgriffe, mit Cloudflare und Bunny.net als Beispielen für die zwei üblichen Bauarten.

Schritt 1: Bauart und Anbieter festlegen

Vor der Anbieterwahl steht die Frage, wie viel deiner Website über das CDN laufen soll. Zwei Wege sind verbreitet.

Beim Full-Site-Betrieb laufen alle Anfragen an deine Domain über das CDN, auch die HTML-Seiten. Cloudflare arbeitet so. In der üblichen Einrichtung, bei Cloudflare "Primary setup" genannt, verwaltet der Anbieter das DNS der Domain, und du trägst seine Nameserver beim Registrar ein. Die Variante, bei der dein bisheriger DNS-Anbieter bleibt und nur einzelne Subdomains über Cloudflare laufen ("CNAME setup"), gibt es nur in den Tarifen Business und Enterprise ^[2].

Bei einer Pull-Zone läuft nur ein Teil der Website über das CDN, meist Bilder, Skripte, Stylesheets und Schriften. Bunny.net ist ein Beispiel dafür. Du legst eine Pull-Zone an, gibst die Adresse deines Servers als Origin an und bekommst eine Adresse der Form name.b-cdn.net. Das CDN holt eine Datei beim ersten Abruf vom Origin und speichert sie danach an seinen Standorten ^[3]. Im Quelltext deiner Seiten müssen die Adressen dieser Dateien dann auf die CDN-Adresse zeigen. Bei WordPress übernimmt das meist ein Plugin.

Welcher Anbieter zu deiner Website passt, zeigt der CDN-Vergleich.

Schritt 2: Origin-Server vorbereiten

Das CDN liefert nur so gut aus, wie der Origin antwortet. Vor der Umstellung lohnt ein Blick auf zwei Punkte.

Der Server sollte selbst HTTPS mit einem gültigen Zertifikat sprechen. Sonst ist zwar die Strecke zwischen Besucher und CDN verschlüsselt, die Strecke zwischen CDN und deinem Server aber nicht oder nur ungeprüft. Schritt 4 geht darauf genauer ein.

Außerdem sollte der Server passende Cache-Header senden. Der Header "Cache-Control" legt fest, ob und wie lange ein Zwischenspeicher eine Antwort aufheben darf. Die Angabe "max-age" nennt die Frische in Sekunden. "s-maxage" gilt nur für gemeinsam genutzte Zwischenspeicher wie ein CDN und hat dort Vorrang vor "max-age" ^[4]. Viele CDNs richten sich nach diesen Angaben. Cloudflare etwa speichert keine Antwort, die mit "private", "no-store", "no-cache" oder "max-age=0" kommt ^[5].

Schritt 3: DNS umstellen oder Pull-Zone anlegen

Beim Full-Site-Betrieb wechselst du die Nameserver der Domain beim Registrar auf die des CDN-Anbieters. Vorher übernimmst du alle bestehenden DNS-Einträge in die Verwaltung des Anbieters, auch MX- und TXT-Einträge für E-Mail. Fehlen sie nach dem Wechsel, kommen keine Mails mehr an. Wie der Wechsel abläuft, beschreibt der Beitrag Nameserver ändern.

Bei einer Pull-Zone bleibt das DNS, wo es ist. Du legst für eine Subdomain wie cdn.example.de einen CNAME-Eintrag an, der auf die Adresse der Pull-Zone zeigt. Bunny.net nennt das Ziel im Bereich "Hostnames" der Pull-Zone. Liegt dein DNS bei Cloudflare, schaltest du für diesen Eintrag den Proxy (die orange Wolke) aus ^[6]. Sonst stünden zwei CDNs hintereinander. Mehr zu diesem Eintragstyp steht unter CNAME-Eintrag: wann er passt und wann nicht.

Senke die TTL der betroffenen Einträge rechtzeitig vor der Umstellung, und zwar mindestens so lange vorher, wie die alte TTL beträgt. Dann greift die Änderung schneller, und du kannst bei Problemen zügig zurück.

Schritt 4: Zertifikat aktivieren

Nach der Umstellung verbinden sich die Besucher mit dem CDN, also braucht das CDN ein Zertifikat für deine Domain. Bei Cloudflare gehört ein Universal-SSL-Zertifikat schon zum kostenlosen Tarif ^[7]. Bei Bunny.net fordert ein Klick auf "Verify & Activate SSL" ein kostenloses Zertifikat von Let's Encrypt für die eigene Subdomain an. Ein eigenes Zertifikat kannst du dort auch hochladen ^[6].

Genauso wichtig ist die zweite Strecke vom CDN zum Origin. Cloudflare bietet dafür mehrere Modi. Im Modus "Flexible" fragt Cloudflare deinen Server über unverschlüsseltes HTTP an ^[8]. Im Modus "Full (strict)" prüft Cloudflare das Zertifikat des Origins: Es muss gültig sein, von einer öffentlich vertrauenswürdigen Stelle oder der Origin CA von Cloudflare stammen und zum Hostnamen passen. Der Server muss HTTPS auf Port 443 annehmen, sonst sehen Besucher den Fehler 526 ^[9]. Sobald dein Origin ein gültiges Zertifikat hat, ist "Full (strict)" die richtige Wahl.

Schritt 5: Cache-Regeln festlegen

An den Cache-Regeln entscheidet sich, ob das CDN die Seite schneller macht und ob es versehentlich etwas Falsches ausliefert. Eine bewährte Aufteilung sieht so aus:

• Dateien mit Versionsnummer oder Prüfsumme im Namen, etwa style.3f9a.css, bekommen eine lange Lebensdauer, zum Beispiel "Cache-Control: max-age=31536000, immutable". Das entspricht 365 Tagen. Ändert sich die Datei, ändert sich ihr Name, und der alte Eintrag wird nie wieder abgerufen ^[4].
• Die HTML-Seite selbst wird bei jedem Abruf neu geprüft, damit sie auf neue Dateinamen zeigen kann. MDN nennt dafür "no-cache" ^[4].
• Persönliche Inhalte, etwa nach dem Login oder im Warenkorb, bekommen "private". Solche Antworten darf nur der Browser speichern, kein gemeinsam genutzter Zwischenspeicher ^[4].
• Was nirgends gespeichert werden darf, bekommt "no-store" ^[4].

Schau dir auch an, was dein Anbieter ohne eigene Regeln tut. Cloudflare speichert HTML und JSON standardmäßig nicht. Bilder, Skripte, Stylesheets, Schriften und Dokumente speichert es nach Dateiendung. Antworten mit einem "Set-Cookie"-Header landen dort ebenfalls nicht im Cache ^[5]. Wer HTML über das CDN zwischenspeichern will, braucht also eine eigene Regel und muss Anmeldebereiche und Verwaltungsoberflächen ausdrücklich ausnehmen.

Schritt 6: Auslieferung testen

Nach der Umstellung prüfst du, ob die Anfragen wirklich über das CDN laufen. Eine DNS-Abfrage der Domain oder der CDN-Subdomain sollte Adressen des Anbieters liefern und nicht mehr die deines Servers.

Danach siehst du dir die Antwort-Header an, zum Beispiel in den Entwicklerwerkzeugen des Browsers im Reiter "Netzwerk". Cloudflare setzt dort den Header "cf-cache-status". "HIT" heißt, die Datei kam aus dem Cache. "MISS" heißt, sie war speicherbar, lag aber noch nicht vor und kam vom Origin. "BYPASS" bedeutet, dass der Origin die Antwort als nicht speicherbar gekennzeichnet hat. Bei "DYNAMIC" hat Cloudflare die Datei gar nicht erst im Cache gesucht ^[10]. Beim zweiten Abruf derselben Datei sollte aus einem MISS ein HIT werden. Andere Anbieter setzen ähnliche Header unter eigenem Namen.

Zum Schluss misst du die Ladezeit vor und nach der Umstellung mit demselben Werkzeug und von denselben Messorten aus, etwa mit PageSpeed.de. Nur so lassen sich die Werte vergleichen.

Schritt 7: Betrieb beobachten und Cache leeren

Im laufenden Betrieb geht es vor allem darum, veraltete Kopien loszuwerden. Bei Dateien mit Versionsnummer erledigt sich das von selbst. Für alles andere bieten die Anbieter das Leeren des Caches an. Cloudflare erlaubt es in allen Tarifen nach Adresse, nach Hostname, nach Cache-Tag, nach Präfix oder für alles auf einmal und empfiehlt, einzelne Adressen zu leeren ^[11]. Leerst du alles, gehen die folgenden Anfragen erst einmal zum Origin, was ihn kurzzeitig stark belasten kann.

Behalte außerdem die Trefferquote im Dashboard im Blick. Ist sie niedrig, obwohl die Seite viele statische Dateien ausliefert, sind häufig die Cache-Zeiten des Origins zu kurz, oder Abfrageparameter in den Adressen erzeugen viele Varianten derselben Datei.

Typische Fehler bei der Einrichtung

• Nach dem Nameserverwechsel kommen keine Mails mehr an, weil die MX-Einträge nicht übernommen wurden.
• Die Website hängt in einer Weiterleitungsschleife. Das passiert, wenn der Origin von HTTP auf HTTPS umleitet und das CDN ihn im Modus "Flexible" per HTTP anfragt. Cloudflare rät dann zum Modus "Full" oder höher, der ein Zertifikat auf dem Origin voraussetzt ^[8].
• Bilder und Skripte laden nicht, weil die CDN-Subdomain noch kein Zertifikat hat.
• Angemeldete Nutzer sehen fremde Daten, weil HTML ohne Ausnahmen zwischengespeichert wird.
• Änderungen erscheinen nicht, weil Dateien ohne Versionsnummer lange im Cache liegen.

Für WordPress gibt es eigene Plugins und einige Besonderheiten bei den Cache-Ausnahmen. Sie stehen im Beitrag CDN für WordPress.

1. Organisation What is a CDN?. Amazon Web Services. Stand ohne Datum. abgerufen am 29.10.2026
2. Organisation Zone setups. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
3. Organisation CDN Quickstart. bunny.net Docs. Stand ohne Datum. abgerufen am 29.10.2026
4. Organisation Cache-Control header. MDN Web Docs. Stand ohne Datum. abgerufen am 29.10.2026
5. Organisation Default cache behavior. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
6. Organisation Custom hostname. bunny.net Docs. Stand ohne Datum. abgerufen am 29.10.2026
7. Organisation Network and CDN plans. Cloudflare. Stand ohne Datum. abgerufen am 29.10.2026
8. Organisation ERR_TOO_MANY_REDIRECTS. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
9. Organisation Full (strict) encryption mode. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
10. Organisation Cloudflare cache responses. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026
11. Organisation Purge cache. Cloudflare Docs. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.