cloudflared: sofortiger i/o timeout nach connectTimeout-Änderung

Nach einer Änderung an originRequest.connectTimeout ist eine Anwendung nicht mehr erreichbar. Das Log meldet i/o timeout, teilweise bereits bei der Namensauflösung, obwohl kaum Zeit vergangen ist. Ein Bericht zu einem remote verwalteten Tunnel beschreibt diese Abhängigkeit. Eine vermutete Einheitenverwechslung ist dort eine Erklärungshypothese, keine universell bestätigte Ursache. Q1

Timeout-Arten nicht vermischen

Cloudflare unterscheidet das Zeitlimit zum Aufbau einer TCP-Verbindung von dem für den TLS-Handshake. Q2 Ein Konfigurationswert für den einen Schritt verlängert nicht automatisch den anderen. Zudem können Dashboard, API, Terraform und lokale YAML-Datei unterschiedliche Darstellungsvorgaben haben.

Aus Konfiguration und Zeit eine prüfbare Aussage machen

1. Änderung genau festhalten. Sichere den vorherigen und neuen Wert samt Quelle: Dashboard, API-Antwort oder verwendeter Provider. Entferne Tokens. Ein Screenshot des Eingabefelds ersetzt nicht den tatsächlich gespeicherten Wert.
2. Aktiven Stand prüfen. Kontrolliere, ob die betroffene Route die geänderte Remote-Konfiguration verwendet und der Connector sie übernommen hat. Globale Einstellungen und routenspezifische Überschreibungen gehören getrennt in den Vergleich.
3. Reale Dauer messen. Wiederhole eine harmlose Anfrage mit Zeitpunkt und beobachteter Dauer. Unterscheide sofortigen Abbruch, ungefähr erwartetes Timeout und erst späteren Anwendungsfehler. Das Wort timeout allein beschreibt diese Unterschiede nicht.
4. Einheit anhand der konkreten Schnittstelle klären. Prüfe die Dokumentation der verwendeten API-/Provider-Version. Übertrage keinen Zahlenwert ungeprüft aus einem GitHub-Kommentar. Sekunden, Dauerzeichenfolgen und interne Repräsentationen sind nicht automatisch austauschbar.
5. Eine Variable zurücknehmen. Falls betrieblich möglich, vergleiche eine Testinstanz mit dem zuvor funktionierenden Stand oder ohne diese einzelne Überschreibung. Ändere nicht gleichzeitig DNS-Server, Ursprung und TLS-Einstellungen. Funktioniert nur dieser Vergleich, ist der Konfigurationspfad enger eingegrenzt.

Was anschließend korrigiert wird

Ist die Darstellung falsch, korrigiere die erzeugende Konfiguration einschließlich ihrer automatischen Wiederanwendung. Ist der gespeicherte Wert korrekt, aber die Laufzeit abweichend, braucht der Hersteller einen minimalen reproduzierbaren Vergleich. Ein dauerhaft extrem hoher Timeout verdeckt diese Frage und kann andere Abläufe verzögern.

Zur Übergabe gehören Connector- und Provider-Version, bereinigter Konfigurationsausschnitt, gemessene Zeiten und dieselbe Anfrage im funktionierenden Vergleich. Nach der Korrektur müssen auch künftige Konfigurationsläufe den richtigen Wert erhalten.

Häufige Fragen

Ist bei lookup i/o timeout immer der DNS-Server schuld?

Nein. Ein vorzeitig abgelaufenes Gesamtbudget kann ebenfalls an diesem Schritt sichtbar werden; prüfe den zeitlichen Zusammenhang.

Soll ich einfach Nanosekunden eintragen?

Nein. Verwende ausschließlich das Format der tatsächlich eingesetzten Schnittstelle und Version.

Fall beschreiben