Was ist ein CDN (Content Delivery Network)?

• Server und Infrastruktur
• Aktualisiert: 04.10.2026
• Ca. 11 Min. Lesezeit

Wie ein CDN arbeitet und wie es in Betrieb geht

1. 1

   Das CDN schaltet sich zwischen Besucher und Server

   Technisch lässt sich ein CDN als weltweit verteilter Reverse Proxy verstehen. Ein Reverse Proxy, den Sie vor Ihren eigenen Server setzen, nimmt Anfragen entgegen, antwortet aus dem Cache und verbirgt die Anwendung dahinter; ein CDN erledigt dieselbe Aufgabe an Ihrer Stelle, an vielen Standorten zugleich.

   In diesem Aufbau heißt der Server, auf dem Ihre Website tatsächlich liegt, Ursprungsserver (Origin), und die besuchernahen Server des CDN heißen Edge-Server. Die Anfrage erreicht zuerst den Edge-Server:

   • Cache-Treffer: Liegt die angefragte Datei auf dem Edge-Server, wird sie direkt von dort ausgeliefert; an den Ursprungsserver geht keine Anfrage.
   • Cache-Fehltreffer: Fehlt die Datei oder ist sie abgelaufen, holt der Edge-Server sie vom Ursprungsserver, gibt sie an den Besucher weiter und speichert sie, sofern das erlaubt ist.

   : Vergrößern

2. 2

   Was leistet ein CDN?

   • Auslieferung von einem nahen Server: Da die Strecke zwischen Besucher und Server kürzer wird, sinkt die Wartezeit, vor allem für Besucher aus entfernten Ländern.
   • Cache: Unveränderliche Inhalte wie Bilder, Stylesheets und Skripte werden von den Edge-Servern ausgeliefert; die Zahl der Anfragen an Ihren Ursprungsserver und dessen Bandbreitenverbrauch gehen zurück.
   • Filtern von Angriffsverkehr: Ein CDN-Netz ist darauf ausgelegt, starken Datenverkehr aufzufangen, den ein einzelner Server nicht verkraften würde; viele Anbieter bieten zudem DDoS-Schutz und eine WAF (Web Application Firewall). Einzelheiten finden Sie in der Anleitung DDoS- und Bot-Angriffe.
   • SSL: Die HTTPS-Verbindung zwischen Besucher und CDN baut das CDN auf; das Zertifikat stellt es meist selbst bereit und erneuert es auch. Was SSL ist, erklärt die Anleitung Was ist SSL?.

   Ein CDN löst nicht jedes Problem: Seiten, die für jeden Besucher eigens erzeugt werden (Warenkorb, Mein Konto, Verwaltungsbereich), lassen sich nicht aus dem Cache ausliefern und entstehen weiterhin auf Ihrem Ursprungsserver. Eine langsame Datenbankabfrage wird durch ein CDN nicht schneller.

   : Vergrößern

3. 3

   Inbetriebnahme: Das DNS zeigt auf das CDN

   Die Einzelheiten unterscheiden sich von Anbieter zu Anbieter, der grundsätzliche Ablauf ist aber derselbe:

   1. Website beim CDN anlegen: Tragen Sie Ihren Domainnamen in der Verwaltungsoberfläche des Anbieters ein und geben Sie die Adresse Ihres Ursprungsservers an.
   2. DNS umstellen: Entweder werden die Nameserver der Domain auf den CDN-Anbieter umgestellt, oder der betreffende Eintrag (zum Beispiel www) zeigt auf die Adresse, die das CDN vorgibt. Von da an erhalten Besucher, die Ihre Domain abfragen, die Adresse des CDN.
   3. SSL-Modus wählen: Stellen Sie ihn so ein, dass sowohl zwischen Besucher und CDN als auch zwischen CDN und Ursprungsserver HTTPS verwendet wird.
   4. Cache-Regeln prüfen: Legen Sie fest, was wie lange gespeichert wird; nehmen Sie persönliche Seiten aus.
   5. Testen und den Ursprung einschränken: Sobald die Website über das CDN einwandfrei läuft, schränken Sie den direkten Zugriff auf den Ursprungsserver ein.

   Prüfen Sie vor der DNS-Umstellung, ob alle vorhandenen Einträge (insbesondere die für E-Mail verwendeten MX- und TXT-Einträge) am neuen Ort vollständig vorhanden sind. E-Mail-Verkehr läuft nicht über das CDN; die E-Mail-Einträge müssen weiterhin direkt auf Ihren Mailserver zeigen.

   : Vergrößern

4. 4

   Die echte Besucher-IP richtig auslesen

   Ist das CDN in Betrieb, verbindet sich nicht mehr der Besucher mit Ihrem Server, sondern die Server des CDN. Ohne weitere Einstellung erscheint in den Zugriffsprotokollen, bei der Ratenbegrenzung und bei allen IP-basierten Prüfungen der Anwendung die Adresse des CDN und nicht die des Besuchers. Das CDN gibt die echte Adresse des Besuchers in einem HTTP-Header weiter; verbreitet ist der Header X-Forwarded-For, manche Anbieter fügen zusätzlich eigene Header hinzu.

   Diesem Header darf nur dann vertraut werden, wenn die Anfrage tatsächlich vom CDN kam; andernfalls kann jeder den Header von Hand setzen und vorgeben, von einer anderen Adresse zu kommen. Die Einstellung in Nginx wird weiter unten in einem eigenen Abschnitt beschrieben.

   : Vergrößern

5. 5

   Sie bestimmen, was in den Cache kommt

   Ob und wie lange das CDN eine Antwort speichert, bestimmt weitgehend der Header Cache-Control, den Ihr Server sendet. Die Regel ist einfach: Inhalte, die für alle gleich sind, dürfen in den Cache; Inhalte, die sich von Person zu Person unterscheiden, dürfen es nicht. Eine versehentlich gecachte Seite „Mein Konto“ kann dazu führen, dass die Daten eines Benutzers einem anderen Besucher angezeigt werden.

   : Vergrößern

Die echte Besucher-IP in Nginx

In Nginx dienen dazu die Direktiven set_real_ip_from und real_ip_header. Die erste gibt an, den Verbindungen welcher Adressen vertraut wird, die zweite, aus welchem Header die echte Adresse gelesen wird:

# Innerhalb des http-Blocks
# Aktuelle, von Ihrem CDN-Anbieter veröffentlichte IP-Bereiche (hier nur Beispiele)
set_real_ip_from 198.51.100.0/24;
set_real_ip_from 203.0.113.0/24;

# Header, aus dem die echte Besucheradresse gelesen wird (laut Anbieter)
real_ip_header X-Forwarded-For;
real_ip_recursive on;

• Tragen Sie in den set_real_ip_from-Zeilen ausschließlich die von Ihrem CDN-Anbieter veröffentlichten IP-Bereiche ein. Ein weiter Bereich oder gar alle Adressen an dieser Stelle bedeuten, dass jeder den Header fälschen kann.
• Die Anbieter aktualisieren ihre IP-Bereiche von Zeit zu Zeit; prüfen Sie die Liste in regelmäßigen Abständen. Bei Anfragen aus einem fehlenden Bereich erscheint weiterhin die Adresse des CDN.
• Verwenden Sie für real_ip_header den Header, den die Dokumentation Ihres Anbieters empfiehlt.
• Mit real_ip_recursive on; werden, wenn der Header mehrere Adressen enthält, die vertrauenswürdigen übersprungen und die letzte nicht vertrauenswürdige Adresse übernommen.

Diese Direktiven gehören zum Nginx-Modul realip. Das Modul ist in einem Standard-Build von Nginx aus dem Quellcode nicht enthalten; in den fertigen Paketen der Distributionen ist es meist vorhanden. Wird die Direktive nicht erkannt, meldet nginx -t dies.

Nach dieser Einstellung verwenden die Zugriffsprotokolle, Sicherheitseinstellungen wie die Ratenbegrenzung und die Client-Adresse, die die Anwendung sieht, die echte Adresse des Besuchers.

Cache, Cache-Control und persönliche Inhalte

Geben Sie unveränderlichen statischen Dateien eine lange Cache-Dauer:

# Versionierte statische Dateien: dürfen lange im Cache bleiben
location ~* \.(css|js|webp|png|jpg|svg|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

Bei Seiten, die sich von Person zu Person unterscheiden (Mein Konto, Warenkorb, Bestellungen, Verwaltungsbereich, alles, was ein angemeldeter Benutzer sieht), untersagen Sie dagegen das Speichern der Antwort in gemeinsamen Caches. Tun Sie das an der richtigen Stelle, nämlich in der Anwendung, die die Seite erzeugt:

<?php
// Seite für einen angemeldeten Benutzer: nicht in gemeinsamen Caches speichern.
// Muss vor jeder Ausgabe gesendet werden.
header('Cache-Control: private, no-store');

• private: Die Antwort darf nur im Browser des Besuchers selbst gespeichert werden, nicht in gemeinsamen Caches wie einem CDN.
• no-store: Die Antwort wird nirgends gespeichert.
• public, max-age=…: Die Antwort darf für die angegebene Zahl von Sekunden überall gespeichert werden.

Ob HTML-Seiten standardmäßig in den Cache kommen, hängt vom Anbieter ab. Bevor Sie mit einer Seitenregel „alles cachen“ festlegen, vergewissern Sie sich, dass unter diesen Adressen keine persönlichen Inhalte liegen. Zu den Cache-Einstellungen auf der Serverseite siehe die Anleitung Caching und Komprimierung.

Cache leeren und versionierte Dateinamen

Wenn Sie eine Datei auf dem Server aktualisieren, wird die alte Kopie auf den Edge-Servern weiter ausgeliefert, bis sie abläuft. Es gibt zwei Lösungen:

• Cache leeren (Purge): Über die Verwaltungsoberfläche oder die API des Anbieters lassen Sie bestimmte Adressen oder den gesamten Cache löschen. Das funktioniert, muss aber bei jeder Veröffentlichung bedacht werden; außerdem lässt sich die Kopie im Browser des Besuchers damit nicht löschen.
• Versionierte Dateinamen: Ändert sich die Datei, ändert sich auch ihr Name oder ihre Adresse: statt style.css etwa style.4f2a1c.css oder style.css?v=12. Da die neue Adresse in keinem Cache liegt, holen sowohl das CDN als auch der Browser die neue Datei sofort. Mit diesem Verfahren können statische Dateien unbesorgt eine sehr lange Cache-Dauer erhalten.

Verwenden Sie für den Regelbetrieb versionierte Namen; heben Sie das Leeren für dringende Korrekturen und HTML-Seiten auf. Ob die Abfragezeichenfolge (?v=12) in den Cache-Schlüssel eingeht, hängt von der Einstellung des Anbieters ab; wenn Sie unsicher sind, wählen Sie das Verfahren, das den Dateinamen ändert.

Direkten Zugriff auf den Ursprungsserver einschränken

Wer die IP-Adresse des Ursprungsservers kennt, kann das CDN umgehen und sich direkt mit dem Server verbinden; die Filter- und Schutzschicht des CDN bleibt dann wirkungslos. Maßnahmen:

• Einschränkung in der Firewall: Öffnen Sie die Web-Ports (80 und 443) nur für die IP-Bereiche des CDN. Das ist das robusteste Verfahren, weil die Anfrage den Webserver gar nicht erst erreicht.
• Einschränkung im Webserver: Haben Sie keinen Zugriff auf die Firewall, können Sie dieselbe Prüfung in Nginx vornehmen (Beispiel unten).
• Authentifizierte Verbindung: Manche Anbieter bieten eine Option, mit der der Ursprungsserver nur Verbindungen annimmt, die das Client-Zertifikat des CDN vorweisen.
• Adresse nicht preisgeben: Entfernen Sie alte DNS-Einträge, die direkt auf den Ursprungsserver zeigen (zum Beispiel ungenutzte Subdomains). War die Adresse zuvor öffentlich, lassen Sie sich nach Möglichkeit von Ihrem Hosting-Anbieter eine neue IP-Adresse geben.

# Innerhalb des http-Blocks: Liegt die verbindende Adresse in einem CDN-Bereich?
geo $realip_remote_addr $von_cdn {
    default          0;
    198.51.100.0/24  1;
    203.0.113.0/24   1;
}

server {
    listen 443 ssl;
    server_name beispiel.de www.beispiel.de;

    # Die Zertifikatspfade sind Beispiele
    ssl_certificate     /etc/ssl/beispiel.de/fullchain.pem;
    ssl_certificate_key /etc/ssl/beispiel.de/privkey.pem;

    # Direkte Verbindungen, die nicht vom CDN kommen, abweisen
    if ($von_cdn = 0) {
        return 403;
    }

    root /var/www/beispiel.de;
}

Dieses Detail ist wichtig: Wird set_real_ip_from verwendet, ersetzt Nginx die Client-Adresse durch die Adresse des Besuchers; die Direktiven allow und deny prüfen deshalb nicht mehr die Adresse des CDN, sondern die des Besuchers. Im Beispiel wird die Adresse, die die Verbindung tatsächlich aufgebaut hat, aus der Variablen $realip_remote_addr gelesen. Allgemeine Empfehlungen zur Serverhärtung finden Sie in der Anleitung Server- und Hosting-Sicherheit.

Verbindung zwischen CDN und Ursprung verschlüsseln

Das Schloss-Symbol im Browser des Besuchers zeigt nur die Verbindung zwischen Besucher und CDN. Die Verbindung zwischen dem CDN und Ihrem Ursprungsserver ist eine eigene Verbindung, und auch sie muss verschlüsselt sein. Bei vielen Anbietern ist das eine Frage des SSL-Modus:

• Vermeiden: den Modus, in dem das CDN den Ursprung über unverschlüsseltes HTTP anspricht. Der Besucher sieht „sicher“, doch die Daten gehen auf der zweiten Hälfte des Weges im Klartext über die Leitung.
• Wählen: den Modus, in dem das CDN den Ursprung über HTTPS anspricht und das Zertifikat des Ursprungsservers prüft. Dafür muss auf dem Ursprungsserver ein gültiges Zertifikat vorhanden sein; manche Anbieter stellen auch ein Ursprungszertifikat aus, dem nur ihr eigenes Netz vertraut.

Zur Einrichtung des Zertifikats auf dem Ursprungsserver siehe die Anleitung HTTPS in Nginx. Bedenken Sie außerdem: Da das CDN die HTTPS-Verbindung auf seinen eigenen Servern terminiert, kann es den Inhalt Ihres Datenverkehrs einsehen; berücksichtigen Sie dies und den Ort, an dem personenbezogene Daten verarbeitet werden, bei der Wahl des Anbieters.

Häufige Fragen

Verwandte Anleitungen

• Was ist ein Reverse Proxy?Aufgaben eines Reverse Proxys, typische Architekturen, echte Besucher-IP und Header, Verhältnis zum CDN und ein kurzes Nginx-Beispiel.
• DDoS- und Bot-AngriffeAnzeichen, CDN und WAF, Ratenbegrenzung, Caching und die Zusammenarbeit mit dem Hosting-Anbieter.
• Caching und Komprimierung in NginxSo richten Sie Caching und Komprimierung in Nginx mit Headern für statische Dateien, gzip und proxy_cache richtig ein.
• Was ist Lastverteilung (Load Balancing)?Wie Anfragen auf mehrere Server verteilt werden, die upstream-Einstellungen in Nginx, Zustandsprüfung und das Sitzungsproblem.