Cloudflare nimmt die Verbindung des Besuchers per HTTPS an, erreicht den Ursprung im Modus Flexible aber über HTTP. WordPress erkennt dort eine unsichere Anfrage und leitet auf HTTPS um. Cloudflare folgt erneut über HTTP – die Schleife beginnt von vorn.
Die dauerhafte Lösung ist ein verschlüsselter, verifizierter Weg bis zum Ursprung und eine eindeutige Zuständigkeit für Weiterleitungen. Dieser Artikel zeigt, wie Sie die Schleife sicher lösen, ohne Login oder Administration auszusperren.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Wie Flexible SSL die Schleife erzeugt
Im Modus Flexible verschlüsselt Cloudflare nur die Strecke zwischen Browser und Cloudflare. Zum Origin wird HTTP verwendet. Erzwingt WordPress oder der Webserver dort HTTPS, sieht die Anwendung bei jeder Anfrage wieder HTTP und sendet erneut einen Redirect.
Die Cloudflare-Modi Full und Full (strict) verwenden dagegen HTTPS zum Ursprung. Full (strict) prüft zusätzlich, ob das Origin-Zertifikat gültig ist und zum Hostnamen passt. Dieser Modus ist das sinnvolle Ziel für eine produktive Website.
Ein realistisches WordPress-Beispiel
Nach der Aktivierung von „Always Use HTTPS“ meldet der Browser zu viele Weiterleitungen. Eine Abfrage ohne automatisches Folgen zeigt abwechselnd dieselbe URL. Wird Cloudflare kurz umgangen, antwortet der Ursprung über HTTP mit einem Redirect auf HTTPS.
Das Team installiert ein gültiges Zertifikat am Ursprung, prüft den direkten HTTPS-Aufruf und wechselt Cloudflare auf Full (strict). Danach bleibt nur die kanonische Weiterleitung am Webserver aktiv; eine zusätzliche Plugin-Regel wird entfernt.
Warum die Architektur wichtig ist
Flexible SSL verschlüsselt nicht den gesamten Weg und sollte keine dauerhafte Lösung für eine WordPress-Website sein. Neben Schleifen kann ein uneinheitliches Schema falsche sichere Cookies, fehlerhafte Callback-URLs oder gemischte interne Links verursachen.
Die beschriebene Diagnose passt, wenn Cloudflare aktiv ist, der Fehler nach einer HTTPS- oder Redirect-Änderung begann und die Sprungkette zwischen denselben Adressen pendelt. Bei einem TLS-Fehler zum Ursprung muss zuerst das Origin-Zertifikat geprüft werden.
Der einfache Weg für Einsteiger
- Notieren Sie den aktuellen Cloudflare-Verschlüsselungsmodus und sichern Sie alle Redirect-Regeln.
- Installieren Sie ein gültiges Zertifikat am Origin-Server.
- Prüfen Sie den Origin direkt über HTTPS, bevor Sie den Cloudflare-Modus ändern.
- Wechseln Sie auf Full (strict).
- Lassen Sie nur eine Stelle für die kanonische HTTP-zu-HTTPS-Weiterleitung verantwortlich.
- Leeren Sie betroffene Caches und testen Sie in einem privaten Browserfenster.
Der technische Weg
Verfolgen Sie HTTP und HTTPS zunächst ohne automatisches Folgen und notieren Sie jeden Statuscode sowie Location-Header. Vergleichen Sie die öffentliche Cloudflare-Antwort mit einem autorisierten direkten Origin-Aufruf. Prüfen Sie außerdem, ob WordPress dem weitergegebenen Protokoll nur von bekannten Proxy-Adressen vertraut.
- Ordnen Sie Redirects Cloudflare, Webserver oder WordPress eindeutig zu.
- Kontrollieren Sie
homeundsiteurlsowie sichere Cookies. - Prüfen Sie Cloudflare Rules, Transform Rules und gecachte Redirects.
- Testen Sie Login, REST, Formulare, Webhooks und Cache-Leerung nach der Umstellung.
Risiken, häufige Fehler, Backup und Rollback
Ein ungeprüfter Wechsel des Cloudflare-Modus kann den Origin unerreichbar machen, wenn dort kein gültiges Zertifikat installiert ist. Ebenso riskant ist es, beliebigen X-Forwarded-Proto-Headern zu vertrauen oder mehrere Redirect-Regeln übereinanderzulegen.
- Halten Sie einen autorisierten direkten Origin-Zugang bereit.
- Sichern Sie Cloudflare- und Webserver-Regeln vor Änderungen.
- Ändern Sie Modus und Redirect-Verantwortung nacheinander.
- Stellen Sie bei Ausfall die letzte funktionierende Regel wieder her und beheben Sie zuerst den Origin-HTTPS-Weg.
Wie AIOWS unterstützt:
AIOWS SSL Manager
Der AIOWS SSL Manager unterstützt die WordPress-seitige Kontrolle nach der Behebung einer Cloudflare-Flexible-SSL-Schleife. Nach der Umstellung auf Full (strict) können Sie damit prüfen, ob WordPress die korrekten HTTPS-Adressen verwendet und das von Cloudflare weitergegebene Protokoll der ursprünglichen Anfrage konsistent auswertet.
Beginnen Sie trotzdem außerhalb von WordPress: Installieren und testen Sie das Origin-Zertifikat und stellen Sie sicher, dass Cloudflare den Ursprung über HTTPS erreicht. Erfassen Sie danach die aktuellen WordPress-Adressen und die aktive Weiterleitungsregel. Nehmen Sie nur die notwendige WordPress-seitige Anpassung vor und testen Sie Startseite, Login, Administration, REST, Formulare und Callbacks über Cloudflare. Ein privates Browserfenster verhindert, dass alte Cookies oder Redirects das Ergebnis verfälschen.
SSL Manager kann den Cloudflare-Verschlüsselungsmodus nicht ändern, kein Origin-Zertifikat am Server installieren und keine externen Rules verwalten. Diese Ebenen bleiben getrennt verantwortlich. Bewahren Sie daher die Cloudflare- und Serverkonfiguration für einen Rollback auf. Wenn eine Schleife nach einer WordPress-Änderung zurückkehrt, stellen Sie den vorherigen WordPress-Wert wieder her und verfolgen die Redirect-Kette erneut. Der zuverlässige Endzustand besteht aus Full (strict), einem gültigen Origin-Zertifikat, vertrauenswürdig weitergegebenem Protokoll und genau einer kanonischen Weiterleitung.
Passende AIOWS-Artikel
- HTTPS in WordPress erzwingen, ohne die Website zu beschädigen
- WordPress-HTTPS-Probleme hinter einem Reverse Proxy
- HTTP mit .htaccess auf HTTPS in WordPress umleiten
Fazit und empfohlener Weg
Ersetzen Sie Flexible SSL durch eine geprüfte HTTPS-Verbindung zum Ursprung. Verwenden Sie Full (strict), erkennen Sie Proxy-Header nur aus vertrauenswürdiger Quelle und lassen Sie genau eine Ebene für die kanonische Weiterleitung zuständig sein.
