Interne Anwendungen sind über ihre IP-Adresse erreichbar, aber ihre Namen werden auf dem WARP-Gerät nicht aufgelöst. DNS-Abfragen laufen über UDP in einen Timeout oder werden über TCP zurückgesetzt. Ein entsprechender Bericht nennt cloudflared 2026.9.3 und einen zuvor funktionierenden älteren Stand. Das grenzt einen Vergleich ein, beweist aber keinen allgemeinen Defekt aller aktuellen Installationen. Q1
Warum SSH zum Server kein DNS-Nachweis ist
Ein erfolgreicher Zugriff auf einen anderen Port bestätigt nicht den DNS-Dienst und seine Richtlinien. Private Namensauflösung umfasst Resolver-Route, passende Namensregel und Transport. Cloudflare dokumentiert diese Voraussetzungen einschließlich QUIC für UDP-Verkehr. Q2 Prüfe daher einen vollständigen DNS-Ablauf statt nur den grünen Tunnelstatus.
Abfragewege miteinander vergleichen
- Einen internen Testnamen festlegen. Verwende einen bekannten, nicht vertraulichen Namen mit vorhersehbarer Antwort. Notiere Resolver-IP und Abfragetyp. Ein zufällig nicht existierender Name würde ein Konfigurationsproblem mit einer normalen negativen Antwort vermischen.
- Am Connector beginnen. Frage den Resolver vom Netz beziehungsweise Container aus ab, in dem cloudflared tatsächlich läuft. Gelingt das schon dort nicht, untersuche zuerst DNS-Dienst, lokale Route und Zugriffsregeln.
- WARP-Client direkt vergleichen. Frage vom betroffenen Gerät denselben Resolver gezielt ab. Wiederhole den Vergleich mit TCP, beispielsweise über die entsprechende Option des DNS-Werkzeugs. UDP-Timeout und TCP-Reset sind unterschiedliche Beobachtungen, die getrennt protokolliert werden sollten.
- Normale Namensauflösung prüfen. Vergleiche den direkten Resolver-Aufruf mit einer gewöhnlichen Abfrage ohne explizite Serveradresse. Funktioniert nur der direkte Weg, liegt der nächste Blick auf Resolver-Policy beziehungsweise Local Domain Fallback und deren Geltungsbereich.
- Policy und Transport zuordnen. Prüfe die Route zur Resolver-IP, Split-Tunnel-Ausnahmen, angewendete Netzwerkregeln und das tatsächlich verbundene Tunnelprotokoll. Die Auswahl
http2ist für eine reine HTTP-Anwendung ein anderer Versuch als für benötigten UDP-DNS-Verkehr. Q2
Nach einem Update reproduzierbar vergleichen
Halte Connector-Version, WARP-Version, Betriebssystem und Startparameter fest. Ein begrenzter Vergleich mit einer genehmigten Testinstanz kann eine Versionshypothese prüfen. Ändere dabei weder Resolver noch Policy gleichzeitig; sonst bleibt unklar, was den Unterschied verursacht hat.
Für Unterstützung helfen die vier Vergleichsergebnisse, präzise Zeiten und passende Policy-Logs. Schwärze interne Namen bei Bedarf konsistent. Nach der Korrektur sollten sowohl direkte DNS-Abfragen als auch der normale Aufruf der Anwendung funktionieren.
Häufige Fragen
Der Tunnel ist Healthy. Kann DNS trotzdem ausfallen?
Ja. Dieser Status bestätigt nicht automatisch jede private Route und Resolver-Regel.
Soll ich UDP einfach durch TCP ersetzen?
Ein TCP-Vergleich ist diagnostisch nützlich. Er ersetzt nicht ungeprüft die für deine DNS-Nutzung benötigten Transporte.
Befundnotiz vorbereiten
Fasse deine Beobachtungen für die Anfrage zusammen. Die Notiz entsteht in deinem Browser; sie wird hier weder gespeichert noch versendet. Du kannst sie anschließend ins Kontaktformular kopieren.
Unbekannt ist möglich. Bitte keine Passwörter, Kundendaten oder vollständigen vertraulichen Protokolle eintragen.
Unterstützung bei diesem Fehler
Wir können Resolver-Routing, WARP-Richtlinien und Connector-Verhalten anhand kontrollierter DNS-Abfragen prüfen.
