Du willst ein Dashboard, ein internes Tool oder einen Mediaserver von deiner Synology aus dem Internet erreichbar machen - aber ohne im Router Ports zu öffnen und ohne deine öffentliche IP preiszugeben? Genau das löst ein Cloudflare Tunnel. Statt eingehende Verbindungen anzunehmen, baut ein kleiner Connector-Container (cloudflared) eine ausgehende Verbindung zu Cloudflare auf. Cloudflare nimmt den Traffic für deine Domain entgegen und schickt ihn durch diesen Tunnel an den internen Dienst. Diese Anleitung zeigt dir Schritt für Schritt, wie du den Tunnel als Docker-Projekt im Container Manager unter DSM 7.2 aufsetzt, einen Public Hostname auf einen internen Dienst mappst und ihn optional mit Cloudflare Access (Zero Trust) absicherst.

Was ist ein Cloudflare Tunnel - und warum ohne Portfreigabe?

Ein Cloudflare Tunnel ist eine dauerhafte, ausgehende Verbindung zwischen deinem Netzwerk und dem Cloudflare-Netzwerk. Der Connector cloudflared läuft als Container auf deiner Synology und meldet sich aktiv bei Cloudflare an. Es ist kein eingehender Port nötig: Dein Router muss nichts weiterleiten, und deine echte WAN-IP bleibt verborgen. Anfragen an https://dienst.deine-domain.de landen bei Cloudflare, werden durch den Tunnel an die NAS gereicht und dort an den internen Dienst (z. B. http://192.168.1.10:8096) zugestellt.

Der große Vorteil gegenüber klassischer Portfreigabe plus DynDNS: Dein NAS ist nie direkt aus dem Internet scanbar, TLS-Terminierung übernimmt Cloudflare, und du kannst per Cloudflare Access eine Login-Schranke (E-Mail-Code, 2FA, Google-/GitHub-Login) davorsetzen - bevor ein Angreifer überhaupt deinen Dienst sieht. Das macht das Setup ideal für interne Dashboards, Admin-Tools, Uptime-Statusseiten oder kleine Web-UIs.

Ein ehrlicher Hinweis vorweg: Cloudflare betreibt einen Reverse-Proxy mit Limits. Große Video-Streams oder umfangreiche Uploads über den orangenen Cloudflare-Proxy bewegen sich in einer Grauzone der Nutzungsbedingungen (Section 2.8). Für Tools, Dashboards und gelegentlichen Zugriff ist der Tunnel perfekt - für dauerhaftes Streaming großer Mediatheken (z. B. Jellyfin mit 4K) ist ein VPN wie WireGuard oder Tailscale die saubere Alternative.

Voraussetzungen

Synology-NAS mit DSM 7.2 oder neuer und installiertem Container Manager (Plus-Serie bzw. ein Modell, das Docker unterstützt).
Eine eigene Domain, die bei Cloudflare verwaltet wird (die Nameserver der Domain zeigen auf Cloudflare, DNS aktiv).
Ein kostenloses Cloudflare-Zero-Trust-Konto (kostenfreier Plan reicht).
Ein interner Dienst, den du veröffentlichen willst (z. B. ein Container mit Web-UI auf einem bekannten Host-Port).
Zugriff auf die File Station und einen DSM-Benutzer mit Administrator-Rechten.
Kein offener Port im Router - das ist ja der Sinn der Übung.

Schritt 1: Datenordner auf der Synology anlegen

Lege in der File Station unter dem freigegebenen Ordner docker einen Unterordner für den Connector an. Das hält das Setup sauber, auch wenn der remote-managed Tunnel selbst keine großen Daten auf der NAS speichert.

Öffne die File Station.
Falls noch nicht vorhanden, lege den freigegebenen Ordner docker an.
Erstelle darin den Ordner cloudflared, sodass der Pfad /volume1/docker/cloudflared existiert.

Schritt 2: Tunnel im Cloudflare Zero Trust Dashboard erstellen

Den eigentlichen Tunnel legst du im Cloudflare-Dashboard an. Dort bekommst du den Token, den der Container braucht.

Melde dich unter one.dash.cloudflare.com am Zero Trust Dashboard an.
Navigiere zu Networks → Tunnels und klicke auf Create a tunnel.
Wähle den Connector-Typ Cloudflared und vergib einen Namen, z. B. synology-nas.
Cloudflare zeigt dir nun Installationsbefehle für verschiedene Plattformen. Wähle den Reiter Docker. Der angezeigte Befehl enthält den langen Tunnel-Token - kopiere genau diesen Token-String (die Zeichenkette nach --token). Du brauchst ihn gleich im Compose-File.

Den Token behandelst du wie ein Passwort. Wer ihn hat, kann sich als dein Tunnel ausgeben.

Schritt 3: docker-compose.yml für den Container Manager erstellen

Im Container Manager heißt ein Compose-Stack Projekt. Du kannst das YAML entweder direkt im Assistenten einfügen oder als Datei docker-compose.yml in /volume1/docker/cloudflared ablegen. Verwende folgendes Compose-File und ersetze DEIN_TUNNEL_TOKEN durch den in Schritt 2 kopierten Token:

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      - TUNNEL_TOKEN=DEIN_TUNNEL_TOKEN

Erklärung der wichtigsten Punkte:

image: cloudflare/cloudflared:latest ist das offizielle Cloudflare-Image. Für den Produktivbetrieb solltest du später einen festen Versions-Tag pinnen, statt blind :latest mitzuziehen.
command: tunnel --no-autoupdate run startet den Connector im Run-Modus. --no-autoupdate verhindert, dass sich der Connector selbst aktualisiert - Updates machst du kontrolliert über das Image.
TUNNEL_TOKEN ist die einzige Pflicht-Variable. Mit ihr ist der Tunnel remote-managed: Die komplette Konfiguration (welcher Hostname auf welchen Dienst zeigt) liegt im Cloudflare-Dashboard, nicht auf der NAS. Das ist der einfachste und wartungsfreundlichste Weg.
Es gibt bewusst kein ports:-Mapping - der Container baut nur eine ausgehende Verbindung auf und braucht keinen veröffentlichten Port auf der NAS.

Schritt 4: Projekt im Container Manager starten

Öffne den Container Manager und wechsle links auf Projekt.
Klicke auf Erstellen.
Vergib als Projektnamen cloudflared.
Wähle als Pfad den Ordner /volume1/docker/cloudflared.
Wähle bei der Quelle Vorhandene docker-compose.yml verwenden, falls du die Datei abgelegt hast, oder YAML-Code erstellen und füge den Compose-Inhalt aus Schritt 3 ein.
Bestätige die folgenden Dialoge und starte das Projekt mit Fertig bzw. Erstellen. Der Container Manager lädt das Image und startet den Container.

Wechsle nach kurzer Zeit zurück ins Zero Trust Dashboard unter Networks → Tunnels. Dein Tunnel sollte jetzt den Status HEALTHY anzeigen. Damit steht die Verbindung - sie transportiert aber noch nichts, weil du noch keinen Hostname gemappt hast.

Schritt 5: Public Hostname auf einen internen Dienst mappen

Jetzt verbindest du eine Subdomain mit einem internen Dienst. Beispiel: Du willst Jellyfin (läuft als Container auf der NAS, Port 8096) unter jellyfin.deine-domain.de erreichbar machen.

Klicke im Dashboard auf deinen Tunnel und öffne den Reiter Public Hostname.
Wähle Add a public hostname.
Subdomain: jellyfin — Domain: wähle deine-domain.de aus der Liste. Den Pfad lässt du leer.
Service Type: HTTP — URL: 192.168.1.10:8096 (interne IP deiner NAS plus Port des Dienstes). Da der cloudflared-Container im selben Netz wie die NAS-Dienste läuft, erreicht er den Dienst über die LAN-IP.
Speichern mit Save hostname.

Cloudflare legt den passenden DNS-Eintrag (einen Proxy-CNAME) automatisch an. Wiederhole den Schritt für jeden weiteren Dienst, etwa uptime.deine-domain.de auf 192.168.1.10:3001 für Uptime Kuma. Ein einziger Tunnel kann beliebig viele Hostnames bedienen.

Kleiner Praxis-Tipp: Wenn dein interner Dienst selbst nur HTTP spricht und du Zertifikatswarnungen vermeiden willst, nutzt du als Service Type HTTP (nicht HTTPS) auf den internen Port. Spricht der Dienst HTTPS mit Self-Signed-Zertifikat, setzt du unter Additional application settings → TLS die Option No TLS Verify.

Schritt 6: Verifikation - erster Aufruf im Browser

Öffne https://jellyfin.deine-domain.de in einem Browser - am besten von einem Gerät außerhalb deines Heimnetzes (z. B. über Mobilfunk), um den Weg über Cloudflare wirklich zu testen.

Die Web-Oberfläche des internen Dienstes lädt - und das Schloss-Symbol zeigt ein gültiges Cloudflare-Zertifikat.
Im Zero Trust Dashboard steht der Tunnel weiterhin auf HEALTHY.
In den Container-Manager-Protokollen des cloudflared-Containers siehst du Verbindungseinträge wie Registered tunnel connection.

Falls die Seite nicht lädt, prüfe zuerst, ob der interne Dienst direkt im LAN unter der angegebenen IP und dem Port erreichbar ist.

Schritt 7 (optional): Cloudflare Access mit 2FA davorschalten

Ein öffentlicher Hostname ohne Login ist für jeden im Internet erreichbar. Für interne Tools willst du das in der Regel nicht. Mit Cloudflare Access setzt du eine Authentifizierung davor - der Dienst selbst sieht den Besucher erst nach erfolgreichem Login.

Navigiere im Zero Trust Dashboard zu Access → Applications und klicke Add an application.
Wähle Self-hosted.
Vergib einen Namen und trage als Application domain exakt deinen Public Hostname ein, z. B. jellyfin.deine-domain.de.
Lege eine Policy an, etwa mit der Regel Emails und deiner eigenen Adresse - nur diese E-Mail darf rein.
Als Login-Methode reicht im Free-Plan der One-time PIN (Cloudflare schickt einen Code per E-Mail). Optional bindest du Identity-Provider wie Google oder GitHub samt deren 2FA ein.
Speichern.

Beim nächsten Aufruf des Hostname landest du zuerst auf der Cloudflare-Access-Login-Seite. Erst nach dem Code-Login wird der Dienst durchgereicht. So liegt eine vollwertige Authentifizierungsschicht vor Anwendungen, die selbst vielleicht nur eine schwache oder gar keine Anmeldung haben.

Updates und Wartung

Den Connector aktualisierst du kontrolliert über das Image:

Im Container Manager das Projekt cloudflared öffnen.
Das Image neu ziehen (Aktion Image abrufen bzw. im Projekt Erstellen/Aktualisieren) und den Container neu starten.

Achte auf die Connector-Version im Dashboard: Veraltete Connectoren markiert Cloudflare mit einem Hinweis. Wenn du Auto-Updates über einen Watchtower-Container fahren willst, sei dir bewusst, dass :latest überraschende Änderungen bringen kann - für Produktivsysteme ist ein gepinnter Tag plus manuelles Update die sicherere Wahl.

Backup

Beim remote-managed Tunnel liegt die komplette Konfiguration im Cloudflare-Dashboard - lokal ist also wenig zu sichern. Trotzdem solltest du zwei Dinge ablegen:

Das Compose-File /volume1/docker/cloudflared/docker-compose.yml in dein Hyper-Backup-Set aufnehmen, damit du den Stack jederzeit reproduzieren kannst.
Den Tunnel-Token sicher in deinem Passwortmanager (z. B. Vaultwarden) hinterlegen - ohne ihn musst du den Tunnel neu erstellen.

Die DNS-Einträge und Access-Policies liegen ohnehin sicher in deinem Cloudflare-Konto.

Troubleshooting

Tunnel bleibt auf DOWN/DEGRADED: Prüfe, ob der Token im Compose korrekt eingetragen ist (keine Leerzeichen, vollständig kopiert) und ob die NAS ausgehend ins Internet darf.
502/Bad Gateway im Browser: Der interne Dienst ist unter der angegebenen IP/Port nicht erreichbar. Teste den Dienst direkt im LAN und prüfe Service Type (HTTP vs. HTTPS).
Zertifikatsfehler beim internen HTTPS-Dienst: Unter den Additional application settings die Option No TLS Verify aktivieren.
Streaming bricht ab oder ist langsam: Cloudflares Proxy-Limits greifen. Für große Mediatheken auf WireGuard/Tailscale statt Tunnel ausweichen.
Access-Login erscheint nicht: Prüfe, ob die Application domain im Access exakt dem Public Hostname entspricht (inklusive Subdomain).

Fazit

Mit dem cloudflared-Connector im Container Manager veröffentlichst du Synology-Dienste sicher im Internet, ohne einen einzigen Port im Router zu öffnen. Der remote-managed Tunnel ist in wenigen Minuten eingerichtet, deine WAN-IP bleibt verborgen, TLS kommt von Cloudflare, und mit Cloudflare Access legst du bei Bedarf eine vollwertige Login-Schranke mit 2FA davor. Für Dashboards, Admin-Tools und Statusseiten ist das die eleganteste Lösung. Nur bei dauerhaftem Streaming großer Videodaten solltest du wegen der Cloudflare-Nutzungsbedingungen auf ein VPN ausweichen.

Weitere Anleitungen in den Kategorien Synology / NAS und Docker.

Quellen: Cloudflare Tunnel Doku, cloudflare/cloudflared auf Docker Hub, cloudflared auf GitHub