cloudflared unter Linux findet .local-Ursprung nicht

Der interne Dienst unter geraet.local öffnet sich auf deinem Rechner, über Cloudflare Tunnel erscheint aber ein Ursprungsfehler. Im Connector-Log steht no such host, eventuell mit einem öffentlichen DNS-Resolver. Genau diese Abweichung wurde für eine Linux-Installation gemeldet. Ein funktionierender Test auf macOS beweist nicht, dass der Linux-Dienst denselben Namensmechanismus benutzt. Q1

Lokaler Name ist nicht automatisch normales DNS

Multicast DNS löst Namen im lokalen Netz auf und ist ein anderer Weg als eine Anfrage an einen gewöhnlichen DNS-Server. Q2 Entscheidend ist daher nicht nur, ob der Name irgendwo funktioniert, sondern ob er im Ausführungskontext von cloudflared zuverlässig aufgelöst wird.

Den falschen Vergleich vermeiden

1. Ziel aus der aktiven Route lesen. Notiere Schema, Hostname und Port der Service-URL. Prüfe, ob der Fehler tatsächlich diesen Ursprungsnamen betrifft oder stattdessen die Cloudflare-Verbindung selbst.
2. Connector-Kontext bestimmen. Läuft cloudflared direkt auf Linux, in Docker oder in einem anderen abgeschotteten Dienst? Erfasse dessen Resolverkonfiguration. Eine erfolgreiche Abfrage auf dem Docker-Host ist noch keine Abfrage aus dem Container.
3. Name und Adresse getrennt prüfen. Ermittle über einen verlässlichen lokalen Verwaltungsweg die aktuelle Zieladresse. Vergleiche zunächst Auflösung und Erreichbarkeit. Eine erfolgreiche TCP-Verbindung zur Adresse bei gescheiterter Namensauflösung grenzt DNS ein, bestätigt aber noch nicht HTTP-Host und TLS-Identität.
4. Dauerhafte Namensquelle wählen. Für einen dauerhaft betriebenen Connector ist ein zuverlässig verfügbarer interner DNS-Name oft besser kontrollierbar als eine zufällig funktionierende Arbeitsplatzauflösung. Ein statischer Hosteintrag braucht dagegen einen ausdrücklich gepflegten Adressbestand.
5. Host und Zertifikat erhalten. Wenn du den Verbindungsnamen änderst, prüfe Virtual Host, erwarteten Zertifikatsnamen und gegebenenfalls die dokumentierten Origin-Parameter. Cloudflare trennt Service-Ziel und bestimmte Host-/TLS-Einstellungen. Q3 Deaktiviere die Zertifikatsprüfung nicht als Ersatz für diese Zuordnung.

Woran die Korrektur erkennbar ist

Der Name muss nach Neustart und aus dem tatsächlichen Connector-Kontext auflösbar bleiben. Danach soll dieselbe harmlose Anfrage direkt und über den Tunnel die erwartete Anwendung erreichen. Prüfe bei DHCP-Adressen auch, wie spätere Änderungen gepflegt werden.

Für Unterstützung helfen Service-URL ohne Zugangsdaten, Connector-Startart, Resolverangaben und Vergleichsergebnisse. Veröffentliche interne Namen oder private Adressen nicht vorschnell im öffentlichen DNS, nur damit ein öffentlicher Resolver sie kennt.

Häufige Fragen

Warum kann mein Laptop den Namen auflösen?

Er kann einen anderen lokalen Auflösungsweg nutzen als der Container oder Hintergrunddienst.

Kann ich einfach die IP-Adresse einsetzen?

Das eignet sich als begrenzter Vergleich. Für den dauerhaften Betrieb müssen zusätzlich Adresspflege, Host-Auswahl und TLS-Namensprüfung passen.

Fall beschreiben