Cloudflare Tunnel ist „Healthy“, aber deine Anwendung bekommt keinen Traffic?

Dein Tunnel steht auf Grün. Trotzdem erreichen Besucher die Anwendung nicht, eine Schnittstelle liefert Fehler oder die Anfragen verschwinden aus dem Anwendungsprotokoll. Der erste sinnvolle Schritt ist ein Vergleich: Was passiert beim öffentlichen Aufruf, was sieht der jeweilige Connector und was erreicht den eigentlichen Dienst?

Cloudflare beschreibt den Tunnelstatus als Aussage über die Verbindung zwischen cloudflared und dem Cloudflare-Netz. Damit ist die Erreichbarkeit deiner Anwendung hinter dem Tunnel noch nicht geprüft. Diese Unterscheidung hilft, den Ausfall einzugrenzen, bevor du Konfigurationen änderst. Q2

Woran du diesen Fehlerfall erkennst

Diese Anleitung passt besonders, wenn mehrere der folgenden Beobachtungen zusammenkommen:

• Im Dashboard oder in deiner Überwachung sieht der Tunnel gesund aus.
• Ein bekannter öffentlicher Anwendungspfad liefert einen Fehler oder keine brauchbare Antwort.
• Deine Anwendung erhält die erwarteten Anfragen nicht oder nur ein Teil der Connectoren verarbeitet noch Verkehr.
• Im Connectorprotokoll wiederholen sich Verbindungsabbrüche, während die Zahl bestehender Verbindungen unauffällig wirkt.
• Der Dienst war vorher erreichbar; seit einem bestimmten Zeitpunkt widersprechen sich Überwachung und tatsächliche Nutzung.

Notiere zunächst, welcher Vorgang wirklich ausfällt. Kann ein Kunde ein Dokument nicht öffnen? Erreicht eine API-Abfrage ihr Ziel nicht? Oder zeigt lediglich eine Kontrollseite einen Fehler? Das bestimmt, welche Antwort später als erfolgreicher Funktionstest zählt. Ein korrekt beantworteter Kontrollaufruf beweist noch keine funktionierende Anmeldung oder Dateiverarbeitung.

Ein öffentlicher Produktionsbericht beschreibt genau eine solche Diskrepanz unter cloudflared 2026.8.2, Kubernetes und QUIC: Verbindungsanzeigen blieben unauffällig, während betroffene Connectoren fast keine Anfragen mehr bearbeiteten. Die Meldung beschreibt einen beobachteten Vorfall; der ursprüngliche Auslöser ließ sich vom Autor nicht gezielt wiederholen. Sie belegt deshalb keinen allgemeinen Fehler aller gesunden Tunnel. Q1

Welche Ursachen auseinandergehalten werden müssen

Ein Tunnel kann mit Cloudflare verbunden sein und trotzdem den lokalen Dienst nicht erreichen. Bei einem Tunnel-Fehler 502 mit dem Hinweis Unable to reach the origin service beschreibt Cloudflare diese Verbindung zum Ursprung als Prüfbereich. Dagegen verlangt ein 1033 eine andere Prüfung der Tunnelverfügbarkeit und Zuordnung. Der genaue Fehlertext ist deshalb hilfreicher als die alleinige Angabe „geht nicht“. Q3

Weitere Fragen betreffen das tatsächlich konfigurierte Ziel: Stimmen Protokoll, Port und Hostname? Erreicht der Connector diesen Dienst aus seiner eigenen Laufzeitumgebung? Bei HTTPS müssen außerdem Zertifikatsname und Vertrauenskette passen. Ein erfolgreicher Aufruf auf deinem Laptop beantwortet diese Fragen für einen anderen Host oder Container noch nicht. Q4

Sichere Ersthilfe: sieben Schritte zur Eingrenzung

1. Einen einzigen, ungefährlichen Kontrollaufruf festlegen. Wähle einen vorhandenen, lesenden Pfad ohne Bestellungen, Nachrichtenversand oder andere Änderungen. Halte erwarteten Status und ein erkennbares Merkmal der Antwort fest. Falls die Anwendung eine Anmeldung erfordert, verwende deinen normalen berechtigten Zugang; Zugangsschutz bleibt bestehen. Verwende keine Kundenaktion als wiederholt ausführbaren Test.

2. Den öffentlichen Fehler zeitlich erfassen. Notiere vollständigen Hostnamen, Pfad ohne vertrauliche Parameter, Uhrzeit mit Zeitzone, Antwortstatus und kurze Fehlermeldung. Dokumentiere auch, ob alle Nutzer oder nur ein bestimmter Zugang betroffen sind. Teile keine Cookies oder Authorization-Header. Ein Screenshot mit grünem Tunnelstatus allein reicht zur Zuordnung nicht.

3. Den Weg zur Anwendung aufschreiben. Halte in einer Zeile fest: öffentlicher Hostname, verwendeter Tunnel, Connector oder Pod und eingestellter Ursprungsdienst. Lies die bestehende Route aus deiner Verwaltung ab. Vergleiche die betroffene Route mit einer noch funktionierenden Route, sofern eine existiert. Übernimm deren Werte nicht ungeprüft: Zwei Anwendungen können bewusst unterschiedliche Protokolle oder Ports benutzen.

4. Den Ursprung aus dem richtigen Kontext prüfen. Ein Administrator sollte denselben lesenden Test aus der Umgebung des Connectors gegen das tatsächlich konfigurierte Ziel durchführen. Bei Containern kann ein anderes localhost gemeint sein als auf dem Host. Für HTTPS gehören der passende Servername und die normale Zertifikatsprüfung zum Test. Die offizielle HTTPS-Anleitung beschreibt die getrennte Prüfung von öffentlichem Aufruf und Ursprung. Q4

5. Ein gemeinsames Zeitfenster vergleichen. Lege öffentliche Testzeit, Connectorprotokoll und vorhandenes Anwendungsprotokoll nebeneinander. Frage: Hat der Connector zur Testzeit eine passende Meldung? Ist der Aufruf im Ursprung erkennbar? Gibt es eine Antwort des Ursprungs? Leere Protokolle sind nur dann aussagekräftig, wenn die betreffende Protokollierung tatsächlich aktiv ist und das richtige System betrachtet wird. Bezeichne einen nicht auffindbaren Eintrag zunächst als fehlenden Nachweis.

6. Einzelne Connectoren unterscheiden. Wenn bereits Metriken gesammelt werden, vergleiche Verbindungen, Anfragen und Fehler pro Connector über dasselbe Zeitfenster. Cloudflare dokumentiert unter anderem cloudflared_tunnel_ha_connections, cloudflared_tunnel_total_requests und cloudflared_tunnel_request_errors. Ein einzelner Zählerstand ersetzt diesen Vergleich nicht. Q2 Prüfe vor der Interpretation, ob der Prozess zwischen zwei Messungen neu gestartet wurde. Wenig Verkehr kann außerdem schlicht wenig Nachfrage bedeuten; erst der kontrollierte Aufruf erzeugt eine bekannte Erwartung.

7. Einen klaren Befund und den nächsten Verantwortlichen benennen. Formuliere beispielsweise: „Der öffentliche Test scheitert; derselbe Ursprung ist aus der Connectorumgebung erreichbar; im betrachteten Connector fehlen passende Anfragen.“ Oder: „Der Connector protokolliert einen Zertifikatsfehler zum Ursprung.“ Daraus lässt sich ein gezielter nächster Schritt ableiten. Wenn eine Wiederherstellungsmaßnahme notwendig wird, sollte sie mit Zuständigkeit, Rückweg und anschließender Prüfung vereinbart werden. Ein pauschaler Neustart aller Komponenten erschwert den Vergleich und kann noch funktionierende Zugänge unterbrechen.

Wann der Dienst wieder als funktionsfähig gelten kann

Lege die Abnahme vor einer Änderung fest. Der zuvor fehlgeschlagene öffentliche Aufruf muss die erwartete Antwort liefern. Ein verantwortlicher Nutzer prüft zusätzlich den betroffenen Arbeitsvorgang mit unkritischen Testdaten. Bei mehreren Connectoren werden die verfügbaren Beobachtungen getrennt ausgewertet. Wiederhole die Prüfung über ein zum Vorfall passendes Zeitfenster und dokumentiere Anfang und Ende.

Eine grüne Anzeige allein ist dafür zu wenig. Ebenso wenig beweist eine einmalige erfolgreiche Antwort, dass ein sporadischer Fehler verschwunden ist. Das Abnahmeprotokoll sollte festhalten, was tatsächlich geprüft wurde und welche Teile des Ablaufs noch offen sind.

Häufige Fragen

Bedeutet „Healthy“, dass die komplette Website erreichbar ist?

Der Status beschreibt die Tunnelverbindung. Die Anwendung dahinter ist ein eigener Prüfpunkt. Für deinen Betrieb ist deshalb zusätzlich ein Test nötig, der eine erwartete Antwort der tatsächlich benötigten Anwendung kontrolliert. Q2

Ist jeder Fehler bei grünem Tunnel derselbe Cloudflare-Bug?

Nein. Der dokumentierte Produktionsvorfall ist ein bestimmtes Fehlerbild. Ein falscher Ursprungsport, ein Zertifikatsproblem oder eine falsch zugeordnete Route müssen anhand deiner eigenen Beobachtungen abgegrenzt werden. Der Name eines ähnlichen Tickets ersetzt diese Diagnose nicht. Q1 Q3 Q4

Soll ich sofort alle Pods oder den Tunnel neu starten?

Sichere zuerst die beobachtbaren Fakten und kläre die Betriebsverantwortung. Ein Neustart kann laufende Verbindungen unterbrechen und den ursprünglichen Zustand verändern. Ob er als kontrollierte Wiederherstellung sinnvoll ist, hängt von deiner Redundanz, den betroffenen Nutzern und einem nachvollziehbaren Rückweg ab. Diese Anleitung legt keinen allgemeinen Neustart fest.

Kann ich zur Probe die Zertifikatsprüfung abschalten?

Die hier beschriebene Diagnose hält sie eingeschaltet. Wenn die Prüfung scheitert, ist das bereits ein brauchbarer Befund: Zielname, Zertifikat und Vertrauenskonfiguration müssen zusammen betrachtet werden. Die HTTPS-Dokumentation beschreibt diesen Zusammenhang. Q4

Gibt es für den gemeldeten Verbindungsfehler bereits einen bestätigten Fix?

Stand 4. November 2026 ist der verlinkte Änderungsvorschlag #1785 offen. Sein Autor beschreibt einen Test der Adressauswahl, ausdrücklich keine Nachbildung des ursprünglichen Produktionsausfalls. Daraus lässt sich keine ausgelieferte Reparatur ableiten. Q5

Welche Angaben helfen bei einer Anfrage am meisten?

Eine genaue Testzeit, Version, Installationsart, betroffene Route, öffentliche Fehlermeldung sowie passende kurze Protokollausschnitte. Ergänze, ob der Ursprung direkt erreichbar war und welcher Arbeitsvorgang ausfällt. Zugangsschlüssel, Tunnel-Token, Cookies und personenbezogene Nutzdaten gehören nicht in ein öffentliches Ticket.

Wo du Hilfe findest

Für die technische Einordnung dienen die Cloudflare-Dokumentation zu Fehlern und Beobachtbarkeit. Q2 Q3 Ein nachvollziehbarer Verdacht auf einen Fehler in cloudflared gehört mit Version und bereinigtem Ablauf in dessen öffentlichen GitHub-Tracker. Der bestehende Bericht hilft beim Abgleich des konkreten Musters. Q1 Fragen zur eigenen Anwendung oder Containerumgebung brauchen zusätzlich den zuständigen Betreiber; der Tunnelstatus kann deren Zustand nicht abschließend erklären.

Fall beschreiben

Du brauchst Unterstützung dabei, den unterbrochenen Zugang einzugrenzen und einen belastbaren Funktionstest festzulegen? Beschreibe KAN KAI, welche Anwendung betroffen ist, seit wann sie ausfällt und welches Ergebnis ein öffentlicher Kontrollaufruf liefert. Ergänze die vorhandenen Beobachtungen aus den sieben Schritten. So lässt sich klären, ob eine lokale Konfiguration, die Betriebsumgebung oder ein Vorgang beim Anbieter weiter untersucht werden muss und welche Unterstützung dafür passt.

Angaben für deine Anfrage: Arbeitsvorgang · Zeitpunkt und Zeitzone · Installationsart und Version · genauer Fehler · vorhandene Diagnoseergebnisse. Eine vollständige Konfiguration oder Zugangsdaten werden für diese erste Beschreibung nicht benötigt.