Cloudflare einrichten: DNS, SSL, CDN und grundlegende Sicherheitsregeln

Kurzfassung

Domain zum kostenlosen Cloudflare-Plan hinzufügen, Nameserver beim Registrar umstellen, SSL/TLS-Modus auf Full (Strict) setzen, webbasierte DNS-Einträge über den Proxy leiten (orangefarbene Wolke), Mail-Einträge auf DNS-only belassen (graue Wolke), HTTPS-Weiterleitung aktivieren und grundlegende WAF-Regeln einrichten. Der gesamte Vorgang dauert etwa 30 Minuten, wobei die Nameserver-Propagierung bis zu 24 Stunden dauern kann.

Voraussetzungen

• Eine registrierte Domain (z.B. dsncon.com)
• Zugang zum Kontrollpanel des Domain-Registrars (um Nameserver zu ändern)
• Ein Webserver mit gültigem SSL-Zertifikat (Let's Encrypt oder ein anderes CA-signiertes Zertifikat)
• Ein Cloudflare-Konto — kostenlos registrieren
• Die öffentliche IP-Adresse des Servers
• Circa 30 Minuten Zeit

Schritt 1: Domain bei Cloudflare hinzufügen

1. Im Cloudflare Dashboard anmelden.
2. Oben auf "Add a site" klicken.
3. Den Domainnamen eingeben (z.B. dsncon.com) und "Add site" klicken.
4. Den Free-Plan auswählen und auf "Continue" klicken.
5. Cloudflare scannt die bestehenden DNS-Einträge. Diese sorgfältig prüfen — sicherstellen, dass alle Einträge vorhanden sind. Cloudflare importiert sie in der Regel korrekt, aber eine Überprüfung ist unerlässlich.
6. Auf "Continue" klicken, um zum Nameserver-Wechsel zu gelangen.

Wichtig: Die DNS-Überprüfung nicht überspringen. Fehlende Einträge bedeuten nicht funktionierende Dienste nach dem Nameserver-Wechsel.

Schritt 2: Nameserver beim Registrar ändern

Cloudflare stellt zwei Nameserver bereit, zum Beispiel:

ada.ns.cloudflare.com
bert.ns.cloudflare.com

Diese müssen beim Domain-Registrar die bisherigen Nameserver ersetzen. Die genauen Schritte hängen vom jeweiligen Registrar ab:

Allgemeiner Ablauf

1. Beim Registrar einloggen (z.B. Namecheap, GoDaddy, IONOS, Hetzner, united-domains).
2. Zu den DNS-Einstellungen bzw. der Nameserver-Verwaltung der Domain navigieren.
3. Von den Standard-Nameservern auf benutzerdefinierte Nameserver umstellen.
4. Die beiden Cloudflare-Nameserver exakt wie angezeigt eintragen.
5. Änderungen speichern.
6. Im Cloudflare Dashboard auf "Done, check nameservers" klicken.

Propagierungszeit: Nameserver-Änderungen sind typischerweise innerhalb von 1–4 Stunden wirksam, können aber bis zu 24 Stunden dauern. Cloudflare sendet eine E-Mail, sobald die Seite aktiv ist.

Die Propagierung lässt sich so prüfen:

dig dsncon.com NS +short
# Erwartete Ausgabe:
# ada.ns.cloudflare.com.
# bert.ns.cloudflare.com.

Schritt 3: DNS-Einträge — Proxied vs. DNS-Only

Jeder DNS-Eintrag in Cloudflare hat einen Proxy-Schalter — die orangefarbene Wolke (Proxied) oder die graue Wolke (DNS-only). Diese Entscheidung ist grundlegend für die Funktionsweise der Cloudflare-Integration.

Proxied (Orangefarbene Wolke) — Für Web-Traffic

Bei aktiviertem Proxy läuft der Traffic über das Cloudflare-Netzwerk. Man erhält CDN-Caching, DDoS-Schutz, WAF und SSL-Terminierung. Besucher sehen die IP-Adresse von Cloudflare, nicht die des eigenen Servers.

Typ   Name       Inhalt           Proxy-Status
A     dsncon.com 203.0.113.50     Proxied (orange)
A     www        203.0.113.50     Proxied (orange)
A     app        203.0.113.50     Proxied (orange)
AAAA  dsncon.com 2001:db8::1      Proxied (orange)

DNS-Only (Graue Wolke) — Für Nicht-HTTP-Dienste

Der Traffic geht direkt zum Server. Kein Cloudflare-Schutz, kein Caching. Erforderlich für Mailserver, FTP, SSH und alle Nicht-HTTP-Protokolle.

Typ   Name       Inhalt                    Proxy-Status
MX    dsncon.com mail.dsncon.com (Pri 10)  DNS-only (immer)
A     mail       203.0.113.50              DNS-only (grau)
TXT   dsncon.com v=spf1 include:...        DNS-only (immer)
CNAME ssh        server.example.com        DNS-only (grau)
SRV   _sip       ...                       DNS-only (immer)

Faustregeln

• Orangefarbene Wolke: Alle A/AAAA/CNAME-Einträge, die eine Website oder API über HTTP/HTTPS bereitstellen.
• Graue Wolke: Mail (MX + zugehörige A-Einträge), SSH, FTP, Gameserver, VPN — alles, was nicht HTTP ist.
• MX-Einträge niemals proxyen. Cloudflare leitet keinen E-Mail-Traffic weiter. Proxied MX-Einträge führen dazu, dass die E-Mail-Zustellung vollständig ausfällt.

Schritt 4: SSL/TLS-Konfiguration

Unter SSL/TLS → Overview im Cloudflare Dashboard gibt es vier Modi:

Off (Nicht sicher)

Keine Verschlüsselung. Niemals verwenden.

Flexible

Verschlüsselt den Traffic zwischen Besucher und Cloudflare, aber Cloudflare verbindet sich per unverschlüsseltem HTTP mit dem Server. Das ist gefährlich. Die Daten reisen unverschlüsselt zwischen Cloudflare und dem eigenen Server. Außerdem verursacht dieser Modus Weiterleitungsschleifen, wenn der Server HTTPS erzwingt.

Full

Verschlüsselt den Traffic durchgehend, aber Cloudflare prüft das SSL-Zertifikat des Servers nicht. Akzeptiert auch selbstsignierte Zertifikate. Besser als Flexible, aber immer noch anfällig für Man-in-the-Middle-Angriffe auf der Origin-Verbindung.

Full (Strict) — Die einzig richtige Wahl

Verschlüsselt den Traffic durchgehend und validiert das Serverzertifikat gegen eine vertrauenswürdige Zertifizierungsstelle. Dies ist der einzige Modus, der tatsächliche Sicherheit bietet.

Jetzt einstellen:

1. Zu SSL/TLS → Overview navigieren.
2. Full (Strict) auswählen.
3. Sicherstellen, dass der Origin-Server ein gültiges SSL-Zertifikat hat (Let's Encrypt ist kostenlos und funktioniert einwandfrei).

Falls kein CA-signiertes Zertifikat auf dem Server installiert werden kann, ein Cloudflare Origin CA-Zertifikat verwenden:

1. Zu SSL/TLS → Origin Server navigieren.
2. Auf "Create Certificate" klicken.
3. RSA oder ECDSA wählen, Hostnamen hinzufügen (dsncon.com, *.dsncon.com).
4. Zertifikat und privaten Schlüssel herunterladen.
5. Auf dem Webserver installieren.

Dieses Zertifikat wird ausschließlich von Cloudflare als vertrauenswürdig eingestuft — das ist ausreichend, solange der Traffic immer über den Proxy läuft.

Weitere SSL-Einstellungen

• Always Use HTTPS: Unter SSL/TLS → Edge Certificates aktivieren. Leitet alle HTTP-Anfragen auf HTTPS um.
• Minimum TLS Version: Auf TLS 1.2 setzen. Es gibt keinen Grund, TLS 1.0 oder 1.1 im Jahr 2026 noch zu unterstützen.
• HSTS: Mit max-age=31536000 aktivieren, Subdomains einschließen. Erst aktivieren, wenn HTTPS nachweislich korrekt funktioniert.
• Automatic HTTPS Rewrites: Aktivieren, um Mixed-Content-Probleme zu beheben, indem HTTP-URLs im HTML automatisch zu HTTPS umgeschrieben werden.

Schritt 5: Häufige SSL-Fehler beheben

ERR_TOO_MANY_REDIRECTS (Weiterleitungsschleife)

Der häufigste Fehler nach der Cloudflare-Einrichtung. Er tritt auf, wenn:

• Der SSL-Modus auf Flexible steht, aber der Server HTTPS erzwingt.
• Cloudflare sendet HTTP an den Server → Server leitet auf HTTPS um → Cloudflare sendet erneut HTTP → Endlosschleife.

Lösung: SSL-Modus auf Full (Strict) setzen und sicherstellen, dass der Server ein gültiges Zertifikat hat.

Error 525: SSL Handshake Failed

Cloudflare kann keine SSL-Verbindung zum Origin-Server aufbauen.

• Das SSL-Zertifikat des Servers ist abgelaufen oder falsch konfiguriert.
• Der Server unterstützt die von Cloudflare verwendeten Cipher Suites nicht.
• Der Server hört nicht auf Port 443.

Lösung: Zertifikat prüfen mit openssl s_client -connect server-ip:443 -servername dsncon.com.

Error 526: Invalid SSL Certificate

Der Modus Full (Strict) ist aktiv, aber das Serverzertifikat ist ungültig (abgelaufen, selbstsigniert oder falscher Hostname).

Lösung: Ein gültiges Zertifikat installieren (Let's Encrypt oder Cloudflare Origin CA).

Mixed-Content-Warnungen

Die Seite wird über HTTPS geladen, referenziert aber HTTP-Ressourcen (Bilder, Skripte, Stylesheets).

Lösung: Automatic HTTPS Rewrites unter SSL/TLS → Edge Certificates aktivieren. Langfristig die URLs im Quellcode korrigieren.

Schritt 6: Caching und Performance

Browser Cache TTL

Unter Caching → Configuration den Browser Cache TTL auf "Respect Existing Headers" setzen, falls der Server korrekte Cache-Control-Header sendet. Andernfalls einen sinnvollen Standardwert wie 4 Stunden einstellen.

Cache Rules

Cloudflare cached standardmäßig statische Ressourcen (Bilder, CSS, JS). Für mehr Kontrolle unter Rules → Cache Rules eigene Regeln anlegen:

Regel: Statische Inhalte cachen
Wenn: URI-Pfad beginnt mit "/static/" ODER URI-Pfad beginnt mit "/assets/"
Dann:
  Cache-Berechtigung: Für Cache geeignet
  Edge TTL: 1 Monat
  Browser TTL: 1 Woche

Regel: Cache für Admin umgehen
Wenn: URI-Pfad beginnt mit "/admin" ODER URI-Pfad beginnt mit "/api/"
Dann:
  Cache-Berechtigung: Cache umgehen

Cache Everything (für statische Seiten)

Bei einer vollständig statischen Website oder bestimmten statischen Seiten kann auch die gesamte HTML-Antwort gecacht werden:

Regel: HTML für Landingpages cachen
Wenn: URI-Pfad ist gleich "/" ODER URI-Pfad ist gleich "/pricing"
Dann:
  Cache-Berechtigung: Für Cache geeignet
  Edge TTL: 2 Stunden
  Browser TTL: 5 Minuten

Warnung: Niemals Seiten cachen, die benutzerspezifische Inhalte, Login-Sessions oder CSRF-Tokens enthalten.

Cache leeren

Nach einem Deployment den Cache leeren: Caching → Configuration → Purge Everything. Für gezielte Löschungen "Custom Purge" verwenden und spezifische URLs eingeben.

Schritt 7: Grundlegende Sicherheitsregeln

WAF (Web Application Firewall)

Unter Security → WAF navigieren. Im kostenlosen Plan stehen grundlegende Managed Rules zur Verfügung. Diese aktivieren.

Eigene Regeln unter Security → WAF → Custom Rules erstellen:

Regel: Bekannte Angriffspfade blockieren
Wenn: URI-Pfad enthält "/wp-login.php" ODER URI-Pfad enthält "/xmlrpc.php"
  UND kein WordPress im Einsatz ist
Dann: Blockieren

Regel: Verdächtige Anfragen herausfordern
Wenn: URI-Pfad beginnt mit "/admin"
  UND Quellland der IP ist NICHT [eigenes Land]
Dann: Managed Challenge

Rate Limiting

Unter Security → WAF → Rate Limiting Rules:

Regel: Login-Endpunkt schützen
Wenn: URI-Pfad ist gleich "/login" UND Anfragemethode ist gleich "POST"
Rate: 5 Anfragen pro 10 Sekunden pro IP
Dann: Für 60 Sekunden blockieren

Regel: API Rate Limit
Wenn: URI-Pfad beginnt mit "/api/"
Rate: 100 Anfragen pro Minute pro IP
Dann: Für 120 Sekunden blockieren

Bot-Management

Unter Security → Bots den Bot Fight Mode aktivieren (im kostenlosen Plan verfügbar). Dieser stellt Anfragen von bekannten Bot-Netzwerken vor eine Herausforderung. Achtung: Dies kann gelegentlich auch legitime Bots blockieren — die Analytics im Auge behalten.

DDoS-Schutz

Standardmäßig auf allen Plänen aktiviert. Unter Security → DDoS die Empfindlichkeitsstufen überprüfen. Die Standardwerte funktionieren für die meisten Seiten gut. Nur bei False Positives anpassen.

Schritt 8: Page Rules

Cloudflare bietet 3 kostenlose Page Rules. Diese sollten wohlüberlegt eingesetzt werden. Unter Rules → Page Rules zu finden.

HTTPS erzwingen

URL: http://dsncon.com/*
Einstellung: Always Use HTTPS

Hinweis: Dies wird mittlerweile besser über SSL/TLS → Edge Certificates → Always Use HTTPS gelöst, was keine Page Rule verbraucht.

www auf Apex-Domain umleiten (oder umgekehrt)

URL: www.dsncon.com/*
Einstellung: Forwarding URL (301 - Permanente Weiterleitung)
Ziel: https://dsncon.com/$1

Alternativ Rules → Redirect Rules verwenden (der neuere Ansatz, der keine Page Rules verbraucht):

Wenn: Hostname ist gleich "www.dsncon.com"
Dann: Dynamische Weiterleitung
Ausdruck: concat("https://dsncon.com", http.request.uri.path)
Statuscode: 301

Cache Everything für statische Bereiche

URL: dsncon.com/docs/*
Einstellungen:
  Cache Level: Cache Everything
  Edge Cache TTL: 1 Monat

Schritt 9: Geschwindigkeitsoptimierungen

Unter Speed → Optimization navigieren.

Brotli-Komprimierung

Unter Speed → Optimization → Content Optimization aktivieren. Brotli bietet ca. 15–20 % bessere Komprimierung als gzip. Auf den meisten Plänen standardmäßig aktiviert — sicherstellen, dass es eingeschaltet ist.

Auto Minify

Minimiert JavaScript, CSS und HTML direkt an der Edge. Alle drei Optionen unter Speed → Optimization → Content Optimization aktivieren. Entfernt Whitespace und Kommentare aus dem Code.

Hinweis: Cloudflare hat Auto Minify seit 2024 als veraltet markiert und empfiehlt stattdessen Minifizierung zum Build-Zeitpunkt. Falls die Option noch im Dashboard sichtbar ist, wird sie möglicherweise bald entfernt. Stattdessen Tools wie esbuild, terser oder die integrierte Minifizierung des verwendeten Frameworks nutzen.

Rocket Loader

Verzögert das Laden aller JavaScript-Dateien bis nach dem Rendering. Zu finden unter Speed → Optimization → Content Optimization. Kann die wahrgenommene Ladezeit deutlich verbessern, kann aber JavaScript-lastige Anwendungen beeinträchtigen. Gründlich testen. Bei Frameworks wie React, Vue oder Angular muss diese Option wahrscheinlich deaktiviert bleiben.

Early Hints

Unter Speed → Optimization → Content Optimization aktivieren. Cloudflare sendet 103 Early Hints-Antworten, um kritische Ressourcen vorab zu laden, bevor die vollständige Antwort eintrifft. Kostenlos und ohne Risiko — aktivieren.

HTTP/2 und HTTP/3

Beide sind bei Cloudflare standardmäßig aktiviert. HTTP/3 (QUIC) kann unter Speed → Optimization → Protocol Optimization umgeschaltet werden. Beide aktiviert lassen.

Fehlerbehebung

Problem	Ursache	Lösung
Weiterleitungsschleife (ERR_TOO_MANY_REDIRECTS)	SSL auf Flexible, aber Server erzwingt HTTPS	SSL auf Full (Strict) setzen
Cloudflare Error 522	Cloudflare kann den Origin-Server nicht erreichen	Firewall-Regeln prüfen — Cloudflare IP-Bereiche erlauben
Error 525 / 526	SSL-Zertifikatsproblem auf dem Origin	Gültiges Zertifikat installieren, Ablaufdatum prüfen
E-Mail funktioniert nicht mehr	MX- oder Mail-A-Eintrag ist proxied	Mail-bezogene Einträge auf DNS-only (graue Wolke) setzen
Veralteter Inhalt nach Deployment	Cloudflare liefert gecachte Version aus	Cache über Dashboard oder API leeren
Echte Besucher-IP nicht in Logs sichtbar	Server sieht Cloudflare-IP statt Besucher-IP	CF-Connecting-IP-Header verwenden oder IPs via mod_cloudflare / ngx_http_realip_module wiederherstellen
WebSocket-Verbindungen schlagen fehl	WebSockets nicht aktiviert oder Proxy falsch konfiguriert	WebSockets unter Network-Einstellungen aktivieren
Rocket Loader macht Seite kaputt	JavaScript-Ausführungsreihenfolge geändert	Rocket Loader deaktivieren oder data-cfasync="false" an kritischen Scripts ergänzen

Wichtige Diagnose-Befehle

# Nameserver prüfen
dig dsncon.com NS +short

# Cloudflare aktiv? (nach cf-ray Header suchen)
curl -sI https://dsncon.com | grep -i cf-ray

# SSL-Zertifikatskette prüfen
openssl s_client -connect dsncon.com:443 -servername dsncon.com 2>/dev/null | openssl x509 -noout -issuer -dates

# Origin direkt prüfen (Cloudflare umgehen)
curl -sI --resolve dsncon.com:443:SERVER_IP https://dsncon.com

# Cloudflare IP-Bereiche abrufen
curl https://www.cloudflare.com/ips-v4

Prävention & Best Practices

• Immer Full (Strict) SSL verwenden. Es gibt keinen legitimen Grund, Flexible in einer Produktionsumgebung einzusetzen.
• MX-Einträge niemals proxyen. E-Mail fällt ansonsten stillschweigend aus.
• Cloudflare-IPs in der Firewall freigeben. Der Server sollte HTTP/HTTPS-Traffic ausschließlich von den Cloudflare IP-Bereichen akzeptieren. Das verhindert, dass Angreifer Cloudflare umgehen, indem sie direkt auf den Origin-Server zugreifen.
• Den CF-Connecting-IP-Header nutzen, um die echten Besucher-IPs zu loggen statt der Cloudflare-Proxy-IPs.
• Monitoring einrichten. Die Cloudflare-Analytics nutzen und Benachrichtigungen bei Anstiegen der Fehlerrate (5xx-Errors) einrichten.
• Cache nach Deployments leeren. Dies in der CI/CD-Pipeline über die Cloudflare API automatisieren:

  curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
    -H "Authorization: Bearer API_TOKEN" \
    -H "Content-Type: application/json" \
    --data '{"purge_everything":true}'

• Origin-Zertifikat gültig halten. Eine Kalender-Erinnerung für die Erneuerung setzen oder Let's Encrypt mit automatischer Verlängerung verwenden.
• Änderungen im Development Mode testen. Unter Caching → Configuration den Development Mode aktivieren, um den Cache während des Testens vorübergehend zu umgehen. Er deaktiviert sich nach 3 Stunden automatisch.
• Redirect Rules statt Page Rules verwenden. Page Rules sind eine ältere Funktion mit begrenzten Slots. Redirect Rules, Cache Rules und Configuration Rules bieten deutlich mehr Flexibilität.
• Sicherheitsereignisse regelmäßig prüfen. Unter Security → Events wöchentlich Angriffsmuster und False Positives identifizieren.