cloudflared: QUIC CRYPTO_ERROR 0x178 ohne Fallback

cloudflared wiederholt einen QUIC-Verbindungsversuch und meldet CRYPTO_ERROR 0x178 sowie tls: no application protocol. Trotz --protocol auto entsteht keine nutzbare Verbindung. Ein Originalbericht beschreibt dies für eine konkrete macOS-Installation. Daraus folgt weder, dass jeder QUIC-Fehler dieselbe Ursache hat, noch dass der automatische Fallback in allen Versionen versagt. Q1

Zwei Verbindungsschritte unterscheiden

Eine UDP-Erreichbarkeitsprüfung und ein abgeschlossener QUIC-Handshake sind verschiedene Nachweise. Cloudflare dokumentiert auto, quic und http2 als Transportoptionen zwischen Connector und Cloudflare. Q2 Diese Einstellung ist nicht identisch mit HTTP/2 zwischen Connector und deinem Ursprung.

Aussagekräftig testen

1. Erste Fehlermeldung sichern. Notiere cloudflared-Version, Betriebssystem, Startparameter und Zeitpunkt. Suche nach tatsächlicher Verbindungsregistrierung, nicht nur nach wiederholten Retry-Zeilen. Entferne Tunnel-Token aus dem Protokoll.
2. Änderungen am Weg erfassen. Prüfe, ob kürzlich VPN, Unternehmensfirewall, Sicherheitssoftware oder Netzanschluss gewechselt wurden. Ein Vergleich über ein anderes genehmigtes Netz kann zeigen, ob der Fehler an einen bestimmten Weg gebunden ist.
3. Benötigte Funktionen bestimmen. Liste auf, welche Dienste dieser Tunnel transportiert. Für private UDP-Dienste gelten andere Anforderungen als für eine veröffentlichte HTTP-Anwendung. Cloudflare beschreibt QUIC als Voraussetzung für UDP-Transport. Q3
4. Begrenzten HTTP/2-Vergleich planen. Falls der Testumfang dies erlaubt, starte eine getrennte oder kontrolliert umgestellte Instanz mit der dokumentierten Transportoption. Ändere dabei nicht gleichzeitig Ursprung, Hostname und Zugangsschutz. Beobachte Registrierung und eine harmlose Anwendungsanfrage.
5. Ergebnis einordnen. Funktioniert HTTP/2 unter sonst gleichen Bedingungen, ist der QUIC-Pfad eingegrenzt. Das beweist noch nicht, welches Gerät oder welche Implementierung den Handshake ablehnt. Scheitern beide, prüfe gemeinsame Voraussetzungen wie Namensauflösung und ausgehende Erreichbarkeit.

Vom Vergleich zur dauerhaften Lösung

Ein funktionierender Testtransport kann je nach Funktionsbedarf eine begrenzte Betriebsoption sein. Prüfe vorher Auswirkungen auf weitere Tunnelrouten. Eine Versionsänderung gehört in denselben kontrollierten Vergleich; installiere nicht nur aufgrund einer fremden Meldung eine beliebige ältere Version dauerhaft.

Zur Übergabe eignen sich bereinigte Startlogs, die beiden Transportergebnisse, Netzvergleich und benötigte Diensttypen. Nach einer Änderung müssen Verbindung und tatsächliche Anwendung geprüft werden. Ein laufender Prozess allein bedeutet noch keinen erreichbaren Dienst.

Häufige Fragen

Warum hilft ein erfolgreicher UDP-Test nicht als Entwarnung?

Er bestätigt nicht, dass anschließend die erforderliche Protokollaushandlung gelingt.

Kann ich http2 immer erzwingen?

Nicht ohne Prüfung der transportierten Dienste. Insbesondere benötigter UDP-Verkehr verändert die Entscheidung.

Fall beschreiben