Cloudflare Tunnel: ERR_TOO_MANY_REDIRECTS

Der Browser meldet ERR_TOO_MANY_REDIRECTS. Andere Tunnelrouten funktionieren, der Connector ist erreichbar, und im LAN öffnet sich die Anwendung. Ein Bericht zu cloudflared 2026.8.0 beschreibt wiederholte Weiterleitungen auf dieselbe URL. Ein Versionsvergleich war dort auffällig, die genaue Ursache jedoch nicht abschließend belegt. Q1

Der LAN-Test kann eine andere Anfrage sein

Eine interne HTTP-Adresse, ein öffentlicher HTTPS-Hostname und ein Host-Header erzeugen möglicherweise unterschiedliche Entscheidungen in der Anwendung. Deshalb entlastet ein erfolgreicher LAN-Aufruf den Ursprung nicht automatisch. Auch ein gesunder Tunnelstatus bestätigt nur einen Teil des Wegs. Q2

Die Schleife Schritt für Schritt aufzeichnen

1. Erste Weiterleitung erfassen. Nutze die Browser-Netzwerkanzeige oder ein HTTP-Werkzeug mit begrenzter Weiterleitungsverfolgung. Notiere Status, angefragte URL und Location, ohne Cookies oder Zugangstokens weiterzugeben. Wiederholt sich exakt derselbe Wert, ist das ein anderer Befund als ein Wechsel zwischen zwei Hosts.
2. Erzeuger über Logs finden. Vergleiche Zeitpunkt und Pfad in Tunnel-, Proxy- und Anwendungslogs. Ein Herkunftsheader allein kann irreführen; eine übereinstimmende protokollierte Antwort ist aussagekräftiger.
3. Service-URL prüfen. Kontrolliere, ob der Tunnel einen HTTP-Port anspricht, der seinerseits immer auf HTTPS umleitet. Verwende das tatsächlich vorgesehene Ursprungsschema mit passender Zertifikatsprüfung. Eine willkürliche TLS-Absenkung löst keine widersprüchliche Weiterleitungslogik.
4. Host- und Proxyinformationen vergleichen. Prüfe öffentliche Basis-URL und die von der Anwendung erwarteten Proxy-Header. Vertraue solchen Headern nur von den vorgesehenen Proxys. Ein vom beliebigen Client gelieferter Header darf keine pauschale Vertrauensgrundlage werden.
5. Version als getrennte Variable testen. Falls das Problem nach einem Update begann, vergleiche eine begrenzte Testinstanz unter gleichen Routingbedingungen. Ändere dabei nicht parallel den TLS-Modus und die Anwendungskonfiguration.

Erfolg nicht nur am ersten Status messen

Nach einer gezielten Korrektur soll die normale Anmeldung erreichbar sein und eine harmlose Folgeseite funktionieren. Prüfe auch den kanonischen Hostnamen und den Ablauf nach einer neuen Sitzung. Bei abweichendem Ursprungsnamen können die dokumentierten Host-/TLS-Parameter relevant sein. Q3

Für Unterstützung helfen eine bereinigte kurze Redirect-Kette, Service-URL, Connector-Version, letzte Änderung und passende Logzeilen. Leere Cookies nur, wenn ein konkreter Sitzungsvergleich dafür spricht; ein serverseitiger Selbstredirect wird dadurch nicht repariert.

Häufige Fragen

Muss ich HTTPS ausschalten?

Nein. Ermittle zuerst, welche Station widersprüchliche Schema- oder Hostinformationen verarbeitet.

Beweist ein funktionierender LAN-Aufruf einen Cloudflare-Fehler?

Nicht ohne vergleichbare Host-, Schema- und Proxybedingungen. Beide Anfragen können unterschiedliche Logik auslösen.

Fall beschreiben