Von Cloudflare Tunnel ohne offene Ports einrichten
Richten Sie einen benannten Cloudflare Tunnel mit Credentials-Datei, Ingress-Regeln und systemd ein. Schließen Sie danach 80 und 443 und binden Sie die App an localhost.
Was Cloudflare Tunnel macht und was „keine offenen Ports“ tatsächlich bedeutet
Cloudflare Tunnel installiert einen kleinen Daemon namens cloudflared auf Ihrem VPS. Dieser Daemon baut eine ausgehende Verbindung zu Cloudflare auf und hält sie offen. Anfragen an Ihren Hostnamen erreichen das Edge-Netzwerk von Cloudflare und werden über diese bestehende Verbindung zurückgeleitet. Es muss daher keine Verbindung in Richtung Ihres Servers aufgebaut werden.
Der Schritt, den die meisten Anleitungen nicht abdecken: Die Installation des Tunnels schließt keine Ports. Wenn 80 und 443 in Ihrer Firewall weiterhin offen sind und Ihre Anwendung weiterhin auf 0.0.0.0 lauscht, haben Sie einen zweiten Zugangsweg hinzugefügt, statt den ersten zu ersetzen. Ihre Origin-IP-Adresse ist weiterhin erreichbar. Wer sie findet, kann Cloudflare direkt umgehen. Das Schließen dieser Ports ist ein manueller Schritt. Erst dadurch sind die zuvor beschriebenen Maßnahmen vollständig wirksam.
cloudflared benötigt ausgehenden Zugriff auf region1.v2.argotunnel.com und region2.v2.argotunnel.com über Port 7844. Für das QUIC-Protokoll verwendet es UDP und fällt für HTTP/2 auf TCP zurück. Wenn Ihr Netzwerk den ausgehenden Datenverkehr filtert, erlauben Sie beide Protokolle oder erzwingen Sie den TCP-Pfad mit --protocol http2.
Bevor Sie beginnen
- Eine Domain in einem Cloudflare-Konto, für deren Zone die Nameserver von Cloudflare zuständig sind.
cloudflared tunnel route dnsschreibt Einträge in diese Zone. Die Zone muss daher bereits vorhanden sein. - Ausgehender Zugriff des VPS auf Port 7844 über UDP und TCP.
- Eine Anwendung, die bereits lokal lauscht, auch wenn es für den ersten Test nur
python3 -m http.server 8080ist. sudoauf dem System. Öffnen Sie eine zweite SSH-Sitzung, bevor Sie die Firewall ändern.
cloudflared unter Ubuntu oder Debian installieren
Cloudflare stellt zu jedem cloudflared-Release ein .deb-Paket bereit. Die Installation besteht daher aus einem Download und einem dpkg-Aufruf.
curl -fsSL -o /tmp/cloudflared.deb \
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --versionFühren Sie zuerst dpkg --print-architecture aus, wenn Sie nicht sicher sind, auf welcher Architektur das System läuft. Auf 64-Bit-ARM endet der Dateiname mit arm64 statt mit amd64. Ansonsten ändert sich nichts. cloudflared --version, das eine Versionszeichenfolge ausgibt, ist die einzige Bestätigung, die Sie benötigen, bevor Sie fortfahren.
Ein auf diese Weise installiertes Paket wird nicht über den Update-Pfad von apt aktualisiert. apt-get upgrade wird es daher niemals aktualisieren. Die Aktualisierung liegt in Ihrer Verantwortung. sudo cloudflared update ruft das neueste Release ab und ersetzt die Binärdatei direkt. Sobald der Dienst vorhanden ist, führen Sie anschließend sudo systemctl restart cloudflared aus, damit der laufende Prozess die neue Binärdatei verwendet. Nehmen Sie diesen Schritt in denselben Zeitplan wie die übrigen Updates auf, da ein Tunneldienst internetseitig erreichbare Software ist, auch wenn er keinen Port öffnet.
Anmelden und einen benannten Tunnel erstellen
cloudflared tunnel loginAuf einem Headless-VPS wird kein Browser geöffnet. Kopieren Sie daher die ausgegebene URL in den Browser auf Ihrem Laptop und wählen Sie die Zone aus. Nach Abschluss ist ~/.cloudflared/cert.pem vorhanden.
cert.pem ist das Berechtigungsobjekt Ihres Accounts. Damit dürfen Sie Tunnel erstellen, DNS-Einträge in diese Zone schreiben und Tunnel löschen. Der laufende Tunnel verwendet es nicht. Behandeln Sie es wie ein Passwort, denn eine Kopie dieser einen Datei reicht aus, damit jemand neue Hostnamen in Ihrer Domain veröffentlichen kann.
cloudflared tunnel create homelabBei erfolgreicher Ausführung werden die beiden folgenden Zeilen ausgegeben. Die darin enthaltene UUID tragen Sie in die Konfigurationsdatei ein.
Tunnel credentials written to /home/you/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel homelab with id 6ff42ae2-765d-4adf-8112-31c55c1551efDiese JSON-Datei ist die Identität des Tunnels. Sie ist das einzige Berechtigungsobjekt, das der laufende Dienst benötigt. Jeder, der über diese Datei verfügt, kann sich als Ihr Tunnel registrieren und Ihren Datenverkehr empfangen. Sie kann nicht unabhängig davon ersetzt werden: Wenn Sie sie widerrufen, bedeutet das cloudflared tunnel delete homelab und das Erstellen eines neuen Tunnels.
Die Anmeldedatendatei an einem geeigneten Ort speichern
Der Dienst läuft als root. Speichern Sie die Datei daher in einem Verzeichnis im Besitz von root, statt sie in einem Home-Verzeichnis abzulegen, auf das ein Backup-Job oder ein gemeinsam genutzter Login zugreifen könnte.
sudo install -d -m 700 -o root -g root /etc/cloudflared
sudo install -m 600 -o root -g root \
~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json \
/etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
rm ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
sudo ls -l /etc/cloudflared
cloudflared tunnel listls -l sollte -rw------- root root für die JSON-Datei anzeigen. cloudflared tunnel list liest cert.pem, sodass der Dienst weiterhin funktioniert. Die Ausgabe sollte den Tunnelnamen, seine UUID und die Anzahl der Verbindungen enthalten, die er derzeit hält.
Konfigurationsdatei config.yml mit echten Ingress-Regeln schreiben
Schreiben Sie die Konfiguration nach /etc/cloudflared/config.yml und nicht in Ihr Home-Verzeichnis. Der Grund ist folgender: cloudflared service install kopiert jede gefundene Konfiguration nach /etc/cloudflared/config.yml und trägt anschließend --config /etc/cloudflared/config.yml fest in die systemd-Unit ein. Wenn Sie die Datei in ~/.cloudflared/config.yml erstellen, ist diese Kopie nur eine einmalige Momentaufnahme. Jede spätere Änderung an der Kopie im Home-Verzeichnis bleibt wirkungslos. Der Dienst verwendet weiterhin die alten Regeln, ohne eine Warnung auszugeben. Wenn Sie die Datei direkt am Ziel erstellen, tritt dieses Problem nicht auf.
tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
loglevel: info
ingress:
- hostname: app.example.com
service: http://127.0.0.1:8080
- hostname: files.example.com
service: http://127.0.0.1:8081
- hostname: grafana.example.com
path: ^/api/
service: http://127.0.0.1:3000
- service: http_status:404Die Regeln werden von oben nach unten gelesen. Die erste passende Regel wird verwendet. Eine Regel ohne hostname passt zu jedem Hostnamen. Deshalb muss die Catch-all-Regel an letzter Stelle stehen. Fehlt sie, wird die Konfiguration mit The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter) abgelehnt. http_status:404 ist ein integrierter Dienst, der 404 zurückgibt und nichts weiter tut. Diese Regel ist erforderlich: Ohne sie fällt eine Anfrage für einen Hostnamen, den Sie nie veröffentlichen wollten, an die jeweils letzte echte Regel durch.
Verwenden Sie 127.0.0.1 in der service:-URL statt localhost. Unter Ubuntu wird localhost zuerst in ::1 aufgelöst. Eine Anwendung, die nur an das IPv4-Loopback gebunden ist, weist diese Verbindung zurück. Die Logzeile lautet dial tcp [::1]:8080: connect: connection refused, und der Besucher erhält einen 502-Fehler.
Hier ist einfaches http:// korrekt, weil die Verbindung den Rechner nicht verlässt. Verwenden Sie https:// nur, wenn die lokale Anwendung auf TLS (Transport Layer Security) besteht. Wenn ihr Zertifikat nicht mit dem von Ihnen angesprochenen Namen übereinstimmt, ist x509: certificate is valid for example.com, not localhost zu erwarten. Beheben Sie das mit originServerName unter originRequest oder akzeptieren Sie das Risiko mit noTLSVerify: true.
Prüfen Sie die Regeln, bevor Sie etwas starten:
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress rule https://app.example.com/loginingress validate meldet, ob die Konfiguration gültig ist, oder nennt die Regel, die den Fehler verursacht. ingress rule nimmt eine URL entgegen und gibt die erste darauf passende Regel aus. Damit lässt sich am schnellsten feststellen, dass ein path-Regex nicht auf das passt, was Sie angenommen haben.
DNS auf den Tunnel verweisen
cloudflared tunnel route dns homelab app.example.com
cloudflared tunnel route dns homelab files.example.com
cloudflared tunnel route dns homelab grafana.example.comJeder Aufruf schreibt einen proxied CNAME-Record, der auf 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com verweist. Dieses Ziel wird nur innerhalb des Cloudflare-Netzwerks aufgelöst. Daher liefert die öffentliche DNS-Antwort für Ihren Hostnamen eine Cloudflare-Adresse, und die IP-Adresse Ihres VPS erscheint darin nicht. Ein Wildcard-hostname in config.yml benötigt weiterhin einen passenden DNS-Record für jeden tatsächlich verwendeten Namen.
Wenn ein Record bereits vorhanden ist, schlägt der Befehl wie folgt fehl:
Failed to add route: code: 1003, reason: Failed to create record app.example.com with err An A, AAAA, or CNAME record with that host already exists.Bei dem vorhandenen Record handelt es sich fast immer um den alten A-Record, der auf die öffentliche IP-Adresse Ihres VPS verweist. Genau diesen Record sollten Sie entfernen. Löschen Sie ihn im Cloudflare-Dashboard und führen Sie den Befehl anschließend erneut aus. Wenn der Record bestehen bleibt, veröffentlicht DNS weiterhin Ihre Origin-IP-Adresse. Der Tunnel verbirgt dann nichts.
Installieren Sie es als Dienst, damit es einen Reboot übersteht
Starten Sie es zunächst einmal im Vordergrund. Ein Fehler lässt sich im eigenen Terminal deutlich leichter lesen als im Journal.
sudo cloudflared --config /etc/cloudflared/config.yml tunnel run homelabBei einem erfolgreichen Start werden mehrere Registered tunnel connection-Zeilen protokolliert, eine pro Edge-Standort. Jede Zeile enthält ein eigenes connIndex. Rufen Sie einen Ihrer Hostnamen im Browser auf und prüfen Sie, ob die Ingress-Regeln die Anfrage wie erwartet weiterleiten. Beenden Sie den Prozess anschließend mit Ctrl-C.
sudo cloudflared --config /etc/cloudflared/config.yml service install
systemctl status cloudflaredDadurch werden /etc/systemd/system/cloudflared.service sowie cloudflared-update.service und cloudflared-update.timer geschrieben. Anschließend werden systemctl enable cloudflared.service und systemctl start cloudflared.service für Sie ausgeführt. enable ist hier der entscheidende Teil, weil dadurch der Tunnel nach einem Reboot wieder gestartet wird. Der ExecStart der Unit lautet cloudflared --no-autoupdate --config /etc/cloudflared/config.yml tunnel run. Deshalb ist dieser Konfigurationspfad fest vorgegeben.
Bei diesem Schritt können drei Fehler mit eindeutigen Meldungen auftreten. possible conflicting configuration in /home/you/.cloudflared/config.yml and /etc/cloudflared/config.yml bedeutet, dass beide Dateien vorhanden sind und cloudflared keine Auswahl trifft. Löschen Sie die Datei, die Sie nicht verwenden möchten. configuration file ... must contain entries for the tunnel to run and its associated credentials (tunnel: TUNNEL-UUID, credentials-file: CREDENTIALS-FILE) bedeutet, dass Ihre Konfiguration die verkürzte url:-Syntax für Quick-Tunnel verwendet und nicht die Schlüssel für einen benannten Tunnel. Diese verkürzte Syntax kann nicht als Dienst ausgeführt werden. cloudflared service is already installed bedeutet, dass noch eine ältere Unit vorhanden ist. Führen Sie daher zuerst sudo cloudflared service uninstall aus.
Es gibt keinen Reload. Führen Sie nach Änderungen an /etc/cloudflared/config.yml den Befehl sudo systemctl restart cloudflared aus. Prüfen Sie anschließend die Aussage zum Reboot, statt sie vorauszusetzen:
sudo reboot
# once it is back
systemctl is-enabled cloudflared
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager
curl -sI https://app.example.comDass is-enabled enabled ausgibt und is-active active ausgibt, ist der entscheidende Zweck dieses Abschnitts. Sobald die Routen vorhanden sind und der Dienst läuft, hat cert.pem auf dem Server keine weitere Aufgabe: rm ~/.cloudflared/cert.pem. Wenn Sie später einen Hostnamen hinzufügen, müssen Sie lediglich erneut cloudflared tunnel login ausführen.
Port 80 und 443 schließen, sonst ist der Tunnel nur ein zusätzlicher Zugang
Dafür sind zwei Änderungen erforderlich. Beide müssen umgesetzt werden. Wenn Sie nur eine davon vornehmen, bleibt der Origin erreichbar.
Binden Sie die Anwendung zunächst an die Loopback-Adresse. In nginx bedeutet das listen 127.0.0.1:8080; anstelle von listen 80;. Die gleiche Änderung wird in dieser Erläuterung zur nginx-Reverse-Proxy-Konfiguration beschrieben. In Docker Compose bedeutet das ports: - "127.0.0.1:8080:80". Die einfache Form "8080:80" veröffentlicht den Port auf jeder Schnittstelle. Docker erstellt eigene NAT-Regeln (Network Address Translation), die Pakete passieren, bevor ufw sie sieht. Eine ufw-Deny-Regel stoppt den Zugriff daher nicht. Dieser Fall wird in dieser Erklärung, warum von Docker veröffentlichte Ports ufw ignorieren beschrieben.
sudo ss -lntpJeder verschobene Dienst sollte jetzt in der Spalte Local Address 127.0.0.1:8080 anzeigen. Eine Zeile mit 0.0.0.0:8080 oder *:8080 lauscht weiterhin auf allen Schnittstellen.
Schließen Sie anschließend die Ports.
sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'
sudo ufw statusLöschen Sie die Allow-Regeln für 80 und 443, statt zusätzliche Deny-Regeln darüberzulegen. ufw verwendet die erste passende Regel. Eine veraltete Allow-Regel weiter oben in der Liste hat daher Vorrang. Lassen Sie Ihre SSH-Regel bestehen. Der Leitfaden zu den ufw-Firewall-Grundlagen behandelt die übrigen Regeln. Die meisten VPS-Anbieter betreiben außerdem eine separate Netzwerk-Firewall in ihrem Control Panel. Diese ist nicht ufw. Schließen Sie Port 80 und 443 daher auch dort.
Prüfen Sie das Ergebnis jetzt von einem anderen System aus. curl http://127.0.0.1:8080 auf dem Server selbst sagt nichts über die Erreichbarkeit aus dem Internet aus.
# run these from a different machine
nc -vz 203.0.113.10 443
curl -sI https://app.example.comEin abgelehntes oder abgelaufenes nc gegen die öffentliche IP-Adresse sowie ein 200 über den Hostnamen sind das erwartete Ergebnis. Weitere Möglichkeiten zur Prüfung, ob ein Port tatsächlich offen ist werden dort beschrieben.
Der Tunnel stellt den Transport bereit, nicht die Authentifizierung. Alles, was Sie darüber veröffentlichen, ist öffentlich erreichbar, sofern Sie keinen Login vorschalten. Dafür können Sie entweder Cloudflare Access am Randnetz oder einen vorgeschalteten OAuth2-Proxy auf dem Server verwenden. Für SSH benötigen Sie ebenfalls eine eigene Lösung, da der Tunnel SSH nicht abdeckt. Lassen Sie Port 22 offen, beschränken Sie ihn aber auf Ihre eigenen Quelladressen.
Was Ihnen Cloudflare Tunnel bietet und welche Kosten entstehen
Die Vorteile sind konkret. Ihre Origin-IP wird nicht mehr veröffentlicht, kein eingehender Port ist erreichbar, und die Einrichtung funktioniert auch auf einem Rechner ohne öffentliche IP-Adresse. Das öffentliche Zertifikat verwaltet Cloudflare, sodass auf Ihrem System kein ACME-Client (Automatic Certificate Management Environment) ausgeführt werden muss. Volumetrische Angriffe werden am Edge abgefangen und belasten nicht Ihre verfügbare Bandbreite.
Die Kosten sind ebenso konkret. Cloudflare beendet TLS an seinem Edge: Die Anfrage des Besuchers wird dort entschlüsselt und anschließend in den Tunnel erneut verschlüsselt. Dadurch kann Cloudflare den Datenverkehr lesen. Das ermöglicht die Firewall-, Caching- und Access-Regeln. Solange Sie den Proxy von Cloudflare verwenden, lässt sich dies durch keine Einstellung deaktivieren. Wenn ein Dritter mit Zugriff auf den Klartext für Sie nicht akzeptabel ist, sollten Sie hier aufhören und eine andere Lösung wählen.
Cloudflare wird außerdem zu einer zwingenden Abhängigkeit für die Erreichbarkeit. Wenn cloudflared nicht verbunden ist, sehen Besucher die Cloudflare-Fehlerseite 1033 statt Ihrer Anwendung. Sie haben damit bewusst die direkte Route entfernt, auf die Besucher andernfalls hätten ausweichen können.
Über einen gewöhnlichen Browser erreichen nur HTTP, HTTPS und WebSocket einen öffentlichen Hostnamen. Für jedes andere TCP-Protokoll, etwa SSH, RDP (Remote Desktop Protocol) oder einen Game-Server, ist zusätzlich Software auf der Client-Seite erforderlich: cloudflared access tcp zur Weiterleitung eines lokalen Ports oder der WARP-Client. Für diese Protokolle gibt es keinen Weg ohne Client-Software.
Request-Bodies sind am Edge begrenzt. Ein Upload, der das Limit überschreitet, wird mit HTTP 413 abgewiesen, bevor er Ihre Anwendung erreicht. Im August 2026 beträgt diese Grenze in den Free- und Pro-Tarifen 100 MB und in den kostenpflichtigen Tarifen mehr. Prüfen Sie daher vor einer Planung anhand eines festen Werts die aktuelle Limit-Seite von Cloudflare. Die Self-Service-Nutzungsbedingungen von Cloudflare schränken außerdem die Verwendung des Proxys ein, wenn dieser hauptsächlich zum Ausliefern von Videos oder anderen großen Nicht-HTML-Dateien eingesetzt wird. Lesen Sie die Bedingungen, bevor Sie eine Medienbibliothek auf einen kostenlosen Tunnel verweisen.
Cloudflare Tunnel, ein Reverse-SSH-Tunnel oder Tailscale Funnel
Alle drei Verbindungen werden ausschließlich ausgehend aufgebaut. Daher funktionieren sie auch auf einem System ohne eingehenden Port und ohne öffentliche IP-Adresse. Sie unterscheiden sich darin, wer Zugriff auf den Klartext hat und unter welchem Hostnamen der Dienst öffentlich erreichbar ist.
Für einen Reverse-SSH-Tunnel benötigen Sie ein zweites System mit öffentlicher IP-Adresse. Dieses System wird zum Einstiegspunkt: Zertifikat, Reverse Proxy und Firewall darauf betreiben Sie selbst. Niemand anderes entschlüsselt die Daten. Der Aufbau umfasst mehr Komponenten. Außerdem benötigen Sie autossh oder eine systemd-Unit mit Restart=always, damit der Tunnel einen kurzen Netzwerkausfall übersteht. Die Anleitung zum Reverse-SSH-Tunnel für CGNAT beschreibt diesen Aufbau.
Tailscale Funnel ist der direkteste Vergleich. Die Verbindung wird ebenfalls ausschließlich ausgehend aufgebaut, und TLS wird auf Ihrem eigenen System beendet. Die Relays von Tailscale sehen daher keinen Klartext. Einschränkungen gibt es bei Namen und Ports: Funnel stellt Dienste nur unter Namen in der ts.net-Domain Ihres Tailnets bereit und ausschließlich auf den Ports 443, 8443 und 10000. Der Unterschied zwischen Tailscale Serve und Funnel behandelt beide Varianten.
Entscheiden Sie sich nach der Einschränkung, die für Sie tatsächlich maßgeblich ist. Wählen Sie Cloudflare Tunnel, wenn der Dienst unter Ihrer eigenen Domain erreichbar sein muss und Sie akzeptieren, dass Cloudflare den Datenverkehr lesen kann. Wählen Sie Tailscale Funnel, wenn ein ts.net-Hostname ausreicht und Sie den Klartext nicht an einen Proxy übergeben möchten. Wählen Sie einen Reverse-SSH-Tunnel, wenn Sie bereits ein öffentlich erreichbares System besitzen und überhaupt keinen Drittanbieter in der Verbindung wünschen.
FAQ
Benötige ich mit Cloudflare Tunnel weiterhin einen offenen Port 443?
Nein. cloudflared baut auf Port 7844 eine ausgehende Verbindung zu Cloudflare auf. Jede Anfrage wird über diese Verbindung zurückgeleitet, sodass kein eingehender Port verwendet wird. Die Installation des Tunnels schließt jedoch keine Ports für Sie. Löschen Sie in ufw die Allow-Regeln für 80 und 443. Schließen Sie diese Ports außerdem in der separaten Netzwerk-Firewall Ihres Providers. Binden Sie die Anwendung an 127.0.0.1. Löschen Sie anschließend jeden verbliebenen A-Record, der weiterhin die IP-Adresse Ihres VPS veröffentlicht. Prüfen Sie dies auf dem Server mit sudo ss -lntp und von einem anderen Rechner aus mit nc -vz <your-ip> 443.
Warum zeigt mein Hostname den Cloudflare-Fehler 1033?
Fehler 1033 bedeutet, dass Cloudflare den DNS-Record für diesen Hostnamen verwaltet, aber keinen verbundenen und funktionsfähigen cloudflared findet, der die Anfrage entgegennehmen kann. Entweder läuft der Prozess nicht, oder er läuft, kann Cloudflare aber nicht erreichen. Prüfen Sie systemctl status cloudflared und journalctl -u cloudflared -n 50. Stellen Sie anschließend sicher, dass ausgehender Port 7844 für UDP und TCP erlaubt ist. Eine Firewall, die UDP und QUIC blockiert, ohne den TCP-Fallback zu erlauben, verursacht genau diesen Fehler. cloudflared tunnel info homelab zeigt die Verbindungen, die Cloudflare aktuell sieht. Eine leere Liste bedeutet, dass die Ursache auf Ihrer Seite liegt.
Warum erhalte ich über den Tunnel 502 Bad Gateway?
Ein 502 bedeutet, dass cloudflared erreicht wurde, den lokalen Dienst aber nicht erreichen konnte. Die Ursache liegt daher zwischen diesen beiden Komponenten und nicht bei Cloudflare. Lesen Sie das Log. dial tcp [::1]:8080: connect: connection refused bedeutet, dass an der angegebenen Adresse nichts lauscht. Der [::1] in dieser Meldung bedeutet meist, dass Sie localhost in der service:-URL eingetragen haben, während die Anwendung nur an IPv4 gebunden ist. Verwenden Sie stattdessen http://127.0.0.1:8080. HTTP/1.x transport connection broken: malformed HTTP response bezeichnet den umgekehrten Konflikt: Sie haben https:// angegeben, während der Origin-Dienst unverschlüsseltes HTTP spricht.
Kann ich SSH, RDP oder einen Gameserver über Cloudflare Tunnel betreiben?
Nicht mit einem einfachen Client. Ein öffentlicher Hostname über einen Tunnel überträgt HTTP, HTTPS und WebSocket, also Protokolle, die ein Browser verwendet. Für jedes andere TCP-Protokoll wird ebenfalls Software auf dem Client benötigt. Dazu können Sie entweder mit cloudflared access tcp einen lokalen Port weiterleiten oder den WARP-Client verwenden. Wenn Sie SSH von jedem Rechner aus ohne zusätzliche Installation nutzen möchten, ist der Tunnel das falsche Werkzeug. Lassen Sie Port 22 offen und beschränken Sie ihn anhand der Quelladresse.
Sieht Cloudflare meinen Datenverkehr über den Tunnel?
Ja. Cloudflare beendet TLS an seinem Edge, entschlüsselt die Anfrage dort und verschlüsselt sie für die Übertragung durch den Tunnel zu Ihrem Server erneut. Diese Entschlüsselung ermöglicht Cloudflares Firewall-, Caching- und Access-Richtlinien. Sie bedeutet außerdem, dass Ihre Klartextdaten auf den Systemen von Cloudflare vorhanden sind. Solange Sie den Proxy von Cloudflare verwenden, lässt sich dies durch keine Konfiguration vermeiden. Wenn das nicht akzeptabel ist, verwenden Sie Tailscale Funnel oder betreiben Sie einen eigenen Reverse Proxy auf einem öffentlich erreichbaren Server.