Domain hosten ohne eigene IP: Cloudflare Tunnel einrichten

Es gibt einen Moment, den jeder kennt, der zu Hause etwas selbst hosten will: Man hat den Server aufgesetzt, die Anwendung läuft, im Heimnetz ist alles erreichbar — und dann soll die Sache von außen erreichbar sein. Spätestens hier steht man vor der Portfreigabe, und bei vielen Anschlüssen ist genau da Schluss. Kein öffentliches IPv4, keine Portfreigabe, kein Zugriff.

Ein Cloudflare Tunnel löst das Problem an der Wurzel, indem er die Richtung umdreht: Nicht die Besucher verbinden sich zum Server, sondern der Server verbindet sich nach außen. Damit braucht man keine öffentliche IP, keine Portfreigabe und keinen offenen Port an der Firewall. In dieser Anleitung richten wir das Schritt für Schritt ein — mit allen Stolpersteinen, über die ich selbst gefallen bin.

Das Wichtigste in Kürze

• Kein Port muss offen sein. Der Server baut eine ausgehende Verbindung zu Cloudflare auf, über die der Verkehr zurückläuft.
• Funktioniert hinter DS-Lite und CGNAT, also überall dort, wo eine Portfreigabe gar nicht möglich ist.
• Die Domain muss bei Cloudflare liegen — nicht nur der DNS-Eintrag, sondern die ganze Zone.
• Kostenlos im Cloudflare-Free-Tarif, inklusive TLS-Zertifikat und DDoS-Schutz.
• Die Origin-IP bleibt verborgen. Niemand sieht, wo dein Server steht.
• Ein Tunnel reicht für mehrere Domains und Dienste — auch aus verschiedenen Zonen.
• Grenzen: 100 MB pro Upload im Free-Tarif, nur HTTP/HTTPS ohne Zusatzaufwand, und die Erreichbarkeit hängt an Cloudflare.

Wann sich ein Tunnel lohnt

Der Klassiker ist der DS-Lite-Anschluss. Viele Kabel- und Glasfaseranschlüsse in Deutschland vergeben keine eigene IPv4-Adresse mehr, sondern teilen eine Adresse unter vielen Kunden auf. Man bekommt IPv6 und eine mitbenutzte IPv4. Eine Portfreigabe für IPv4 ist damit technisch unmöglich, und IPv6 allein hilft nicht, solange Besucher noch über IPv4 kommen.

Dasselbe gilt für CGNAT bei Mobilfunk- und manchen Glasfaseranbietern. Und selbst mit fester IP gibt es gute Gründe: Wer keinen Port im Router öffnen will, wer seine Heimadresse nicht im DNS stehen haben möchte, oder wer — wie ich kürzlich — feststellt, dass die Anbindung des Servers unzuverlässig geworden ist und einen Weg sucht, der die kaputte Strecke umgeht.

Nicht geeignet ist der Tunnel, wenn du andere Protokolle als HTTP brauchst. Ein Mailserver, ein LDAP-Verzeichnis oder ein Spieleserver laufen darüber nicht ohne Weiteres. Dafür gibt es Zero Trust mit installiertem Client auf der Gegenseite, was den Ansatz aber deutlich verkompliziert.

Wie der Tunnel funktioniert

Auf dem Server läuft ein kleines Programm namens cloudflared. Es baut mehrere dauerhafte, ausgehende Verbindungen zu Cloudflare-Rechenzentren auf. Ruft jemand deine Domain auf, landet die Anfrage bei Cloudflare, wird durch eine dieser bestehenden Verbindungen zu deinem Server geschoben, und die Antwort nimmt denselben Weg zurück.

Für die Firewall ist das eine ganz normale ausgehende Verbindung, so wie ein Browser oder ein Update-Prozess sie auch aufbaut. Genau deshalb funktioniert das Verfahren hinter jedem NAT, ohne Konfiguration am Router.

Voraussetzungen

1. Eine eigene Domain, deren Zone bei Cloudflare liegt. Ein kostenloses Konto genügt. Der Domainname selbst kann bei jedem Registrar registriert sein, aber die Nameserver müssen auf Cloudflare zeigen.
2. Ein Server oder Rechner im Heimnetz mit Linux, auf dem der Dienst läuft, den du veröffentlichen willst. Ein Raspberry Pi als Homeserver reicht völlig.
3. Eine funktionierende ausgehende Internetverbindung. Mehr nicht — kein Port, keine feste IP.
4. Root-Rechte auf dem Server.

Schritt 1: Domain zu Cloudflare umziehen

Falls die Domain noch nicht bei Cloudflare liegt: Im Cloudflare-Dashboard die Domain hinzufügen, Cloudflare liest die bestehenden DNS-Einträge ein, und danach trägt man beim Registrar die beiden genannten Cloudflare-Nameserver ein. Bis die Umstellung greift, können ein paar Stunden vergehen.

Wichtig ist der Unterschied zwischen DNS bei Cloudflare und Domain bei Cloudflare registriert. Für den Tunnel muss nur die Zone dort verwaltet werden. Wo du die Domain gekauft hast, spielt keine Rolle.

Schritt 2: cloudflared installieren

Auf Debian und Ubuntu ist der direkteste Weg das offizielle Paket:

curl -fsSL https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o /tmp/cloudflared.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --version

Für einen Raspberry Pi nimmst du statt amd64 die Variante arm64 (bei 64-Bit-System) oder arm (32 Bit).

Warum nicht über das Paketrepository? Cloudflare bietet eines an, und es funktioniert. Der direkte Weg über das .deb hat aber einen praktischen Vorteil: Er kommt ohne apt update aus. Auf einem meiner Server ist genau daran die Installation gescheitert, weil ein völlig unbeteiligtes, kaputtes Fremdrepository den gesamten Update-Lauf abgebrochen hat. Das Paket direkt zu installieren umgeht solche Nebenkriegsschauplätze.

Schritt 3: Bei Cloudflare anmelden

sudo cloudflared tunnel login

Der Befehl gibt eine Adresse aus und wartet dann. Diese Adresse öffnest du im Browser, meldest dich an und wählst die Domain aus, für die der Tunnel arbeiten soll. Danach schreibt cloudflared ein Zertifikat nach /root/.cloudflared/cert.pem und beendet sich.

Stolperstein Nummer eins: Der Prozess muss während deines Klicks weiterlaufen. Wenn du ihn vorher beendest — etwa weil du in einer anderen Sitzung aufräumst — läuft die Bestätigung im Browser ins Leere, und das Zertifikat wird nie geschrieben. Das ist mir passiert, und die Fehlermeldung danach („Cannot determine default origin certificate path“) führt in die Irre, weil sie nach einem Konfigurationsfehler aussieht.

Stolperstein Nummer zwei, und der ist wichtig: Dieses Zertifikat gilt nur für die eine Zone, die du im Dashboard ausgewählt hast. Dazu gleich mehr bei Schritt 6.

Schritt 4: Tunnel anlegen

sudo cloudflared tunnel create homeserver

Der Name ist frei wählbar. Ich empfehle, ihn nach dem Server zu benennen und nicht nach der Domain — denn ein Tunnel kann später beliebig viele Domains bedienen, und ein Tunnel namens „meineseite“ wirkt schnell unpassend, wenn dort fünf weitere Projekte mitlaufen.

Die Ausgabe nennt eine Tunnel-ID und den Pfad zu einer Zugangsdatei. Beides brauchen wir gleich.

Schritt 5: Konfiguration schreiben

Lege /etc/cloudflared/config.yml an. Hier ein Beispiel für einen Webserver, der auf demselben Rechner auf Port 443 lauscht:

tunnel: DEINE-TUNNEL-ID
credentials-file: /etc/cloudflared/DEINE-TUNNEL-ID.json

originRequest:
  connectTimeout: 30s

ingress:
  - hostname: www.meine-domain.de
    service: https://127.0.0.1:443
    originRequest:
      originServerName: www.meine-domain.de

  - hostname: meine-domain.de
    service: https://127.0.0.1:443
    originRequest:
      originServerName: meine-domain.de

  - service: http_status:404

Die Zugangsdatei kopierst du aus /root/.cloudflared/ nach /etc/cloudflared/, damit der Systemdienst später darauf zugreifen kann.

Drei Dinge zur Erklärung:

Die letzte Regel ohne hostname ist Pflicht. Sie fängt alles ab, was auf keine vorherige Regel passt. Fehlt sie, startet der Tunnel nicht.

originServerName sorgt dafür, dass beim Verbindungsaufbau zum eigenen Webserver der richtige Hostname mitgeschickt wird. Ohne diese Angabe bekommt ein Webserver mit mehreren virtuellen Hosts die Anfrage nicht zugeordnet und antwortet mit der falschen Seite oder einem Zertifikatsfehler.

Zeigt der Tunnel auf einen unverschlüsselten Dienst, etwa eine Anwendung auf Port 3000, schreibst du einfach service: http://127.0.0.1:3000 und lässt originServerName weg. Das ist der häufigere Fall bei selbstgehosteten Anwendungen.

Danach prüfen:

sudo cloudflared tunnel ingress validate

Schritt 6: DNS-Einträge anlegen

Jetzt muss die Domain auf den Tunnel zeigen. Das geht per Befehl:

sudo cloudflared tunnel route dns homeserver www.meine-domain.de

Der Befehl legt einen CNAME-Eintrag an, der auf <tunnel-id>.cfargotunnel.com verweist.

Existiert bereits ein A-Eintrag für diesen Namen, schlägt der Befehl fehl — mit Fehlercode 1003 und dem Hinweis, dass ein Eintrag mit diesem Namen schon existiert. Dann löschst du den alten A-Eintrag im Dashboard und wiederholst den Befehl. Das ist der normale Fall, wenn du eine bereits laufende Seite umstellst.

Und hier kommt der Stolperstein, der mich zweimal erwischt hat: Das Anmeldezertifikat aus Schritt 3 gilt nur für eine Zone. Rufst du route dns für einen Hostnamen einer anderen Domain auf, meldet cloudflared keinen Fehler — es legt den Eintrag klaglos als Subdomain in der autorisierten Zone an. Aus meine-zweite-domain.de wird dann meine-zweite-domain.de.meine-erste-domain.de.

Die Gegenmaßnahme ist einfach: Nach dem ersten Eintrag die Ausgabe lesen. Steht dort der reine Hostname, passt alles. Hängt etwas hinten dran, sofort aufhören und für die andere Zone ein weiteres Mal cloudflared tunnel login ausführen. Pro Zone ein Login — der Tunnel selbst bleibt derselbe.

Schritt 7: Als Dienst einrichten

sudo cloudflared service install
sudo systemctl enable --now cloudflared
systemctl status cloudflared

Danach prüfst du, ob der Tunnel steht:

sudo cloudflared tunnel info homeserver

Die Ausgabe zeigt die aktiven Verbindungen zu den Cloudflare-Rechenzentren, meist vier Stück zu zwei verschiedenen Standorten. Sind sie da, ist die Seite erreichbar.

Mehrere Dienste über einen Tunnel

Ein Tunnel kann beliebig viele Hostnamen bedienen, und sie dürfen aus verschiedenen Domains stammen. Man ergänzt einfach weitere Einträge unter ingress:

ingress:
  - hostname: wolke.meine-domain.de
    service: http://127.0.0.1:8080

  - hostname: fotos.meine-domain.de
    service: http://192.168.1.50:2283

  - hostname: status.andere-domain.de
    service: http://127.0.0.1:3001

  - service: http_status:404

Wie das zweite Beispiel zeigt, muss der Dienst nicht auf demselben Rechner laufen. Der Tunnel-Rechner kann auf jede Adresse in deinem Heimnetz weiterleiten. Damit reicht ein Raspberry Pi als Zugangspunkt für sämtliche Dienste im Haus.

Nach jeder Änderung an der Konfiguration:

sudo systemctl restart cloudflared

Und für jeden neuen Hostnamen einmal den passenden DNS-Eintrag anlegen, wie in Schritt 6.

Was mit den Zertifikaten passiert

Zwischen Besucher und Cloudflare ist die Verbindung immer verschlüsselt, darum kümmert sich Cloudflare. Interessant ist die zweite Hälfte, zwischen Cloudflare und deinem Server. Dafür gibt es zwei brauchbare Wege.

Weg eins: Let’s Encrypt weiterlaufen lassen. Wenn auf deinem Server bereits Zertifikate liegen, funktionieren sie weiter — auch die automatische Erneuerung. Das hat mich selbst überrascht, denn die übliche Prüfung läuft über Port 80, der ja nicht mehr offen ist. Sie funktioniert trotzdem, weil die Anfrage von Let’s Encrypt über Cloudflare durch den Tunnel ans Origin gereicht wird. Ein Testlauf bestätigt das:

sudo certbot renew --dry-run

Weg zwei: ein Origin-Zertifikat von Cloudflare. Im Dashboard unter SSL/TLS lässt sich ein Zertifikat erzeugen, das fünfzehn Jahre gültig ist. Es taugt nur für die Verbindung zwischen Cloudflare und deinem Server — ein Browser würde es nicht akzeptieren — aber genau darum geht es hier. Damit entfällt jede Erneuerung. In der Tunnel-Konfiguration braucht dieser Fall einen Zusatz, weil das Zertifikat nicht von einer öffentlichen Stelle signiert ist:

    originRequest:
      originServerName: meine-domain.de
      noTLSVerify: true

Das klingt unsicher, ist es hier aber nicht: Die Verbindung geht über 127.0.0.1, verlässt den Rechner also gar nicht.

Stolpersteine aus der Praxis

Der Reverse Proxy kennt die alten Adressen. Läuft dein Webserver in einem Container und startest du die dahinterliegenden Anwendungen neu, bekommen die neue interne IP-Adressen. Der Proxy merkt das nicht und liefert plötzlich 502. Ein Neuladen der Proxy-Konfiguration löst es sofort. Das kostet einen sonst unnötigen Schreckmoment, weil die Fehlersuche zuerst beim Tunnel landet, wo alles in Ordnung ist.

Der eigene DNS-Zwischenspeicher lügt. Nach dem Umstellen von A-Eintrag auf CNAME schlagen die ersten Aufrufe scheinbar zufällig fehl. Das ist meist der Resolver des eigenen Rechners, der noch die alte Adresse hält. Vor jeder Fehlersuche also erst:

resolvectl flush-caches

Der Tunnel braucht keine Portfreigabe — aber ausgehenden Verkehr. Wenn eine restriktive Firewall ausgehende Verbindungen einschränkt, muss cloudflared nach außen dürfen. Standardmäßig nutzt es QUIC über UDP-Port 7844, weicht bei Bedarf aber auf HTTPS aus.

Die Anzeige im Dashboard bleibt leer. Tunnel, die per Konfigurationsdatei verwaltet werden, lassen sich im Dashboard unter „Networks“ nur ansehen, nicht bearbeiten. Das ist so gewollt: Entweder man pflegt die config.yml auf dem Server, oder man verwaltet alles im Dashboard. Beides gleichzeitig geht nicht.

Grenzen und Nachteile

Damit die Sache ehrlich bleibt, die Kehrseite:

• 100 MB pro Anfrage im Free-Tarif. Für normale Webseiten irrelevant, für den Upload großer Dateien in eine selbstgehostete Cloud ein echtes Hindernis.
• Nur HTTP und HTTPS ohne Zusatzaufwand. SSH, Mail, LDAP oder Datenbanken laufen nicht ohne installierten Client auf der Gegenseite.
• Abhängigkeit von einem Anbieter. Ist Cloudflare gestört, ist deine Seite offline — auch wenn dein Server tadellos läuft.
• Der Verkehr läuft entschlüsselt durch Cloudflare. Das gilt für jede Nutzung als Proxy, nicht nur für Tunnel, sollte einem aber bewusst sein.
• Die Domain muss dorthin umziehen. Wer seinen DNS bewusst woanders betreibt, muss das aufgeben.

Alternativen

Tailscale ist die bessere Wahl, wenn nur du zugreifen sollst und nicht die Öffentlichkeit. Es baut ein privates Netz zwischen deinen Geräten auf und funktioniert ebenfalls hinter jedem NAT. Für eine öffentliche Website taugt es nicht, für den Fernzugriff auf die eigene Verwaltungsoberfläche dagegen hervorragend.

Ein kleiner VPS als Gegenstelle mit WireGuard und einem Reverse Proxy ist der Weg für alle, die keine Abhängigkeit von Cloudflare wollen. Kostet ein paar Euro im Monat, bringt eine echte eigene IP mit und kennt keine Protokollgrenzen — dafür musst du Updates, Zertifikate und Angriffsschutz selbst betreiben.

IPv6 allein ist die sauberste Lösung, aber erst dann praktikabel, wenn alle Besucher IPv6 haben. Das ist 2026 noch nicht der Fall.

Eine feste IPv4 vom Anbieter gibt es bei vielen Providern gegen Aufpreis. Wenn dein Anschluss das anbietet und du ohnehin Portfreigaben brauchst, ist es oft der unkomplizierteste Weg.

Fazit

Ein Cloudflare Tunnel ist in einer Viertelstunde eingerichtet und löst ein Problem, an dem sonst jeder Selbsthoster hinter DS-Lite scheitert. Für Projekte, die öffentlich erreichbar sein sollen und mit HTTP auskommen, ist er die unkomplizierteste Lösung — inklusive Zertifikat, Schutz vor Überlastung und verborgener Server-Adresse.

Man sollte sich der Abhängigkeit bewusst sein und das Upload-Limit im Kopf behalten. Wer das akzeptiert, bekommt für null Euro eine Lösung, die auch dann noch trägt, wenn der eigene Anschluss oder das Netz des Providers Probleme macht. Genau in dieser Situation habe ich das Verfahren zuletzt eingesetzt, und es hat innerhalb einer halben Stunde mehrere Seiten wieder erreichbar gemacht, die vorher tot waren.

Wenn du gerade erst anfängst: Ein eigener Homeserver und ein geordnetes Homelab sind die Grundlage, auf der so etwas Spaß macht. Und wenn du die Dienste in Containern betreibst, hilft dir die Docker-Anleitung beim Einstieg.

Häufige Fragen

Ist ein Cloudflare Tunnel wirklich kostenlos?

Ja. Die Funktion ist im kostenlosen Tarif enthalten, samt Zertifikat und Grundschutz. Kosten entstehen erst bei Zusatzfunktionen wie erweiterten Zero-Trust-Regeln oder höheren Upload-Grenzen.

Funktioniert das auch hinter DS-Lite oder CGNAT?

Ja, das ist der Hauptanwendungsfall. Weil der Server die Verbindung selbst nach außen aufbaut, spielt es keine Rolle, ob du eine eigene öffentliche Adresse hast.

Sieht jemand meine Heim-IP-Adresse?

Nein. Im DNS steht nur ein Verweis auf den Tunnel, und die Anfragen erreichen dich über Cloudflare. Die Adresse deines Anschlusses taucht nicht auf.

Brauche ich noch einen dynamischen DNS-Dienst?

Nein. Da keine Adresse im DNS gepflegt werden muss, wird DynDNS überflüssig. Ändert sich deine IP, baut cloudflared die Verbindung einfach neu auf.

Kann ich SSH über den Tunnel nutzen?

Nur mit Zusatzaufwand. Cloudflare bietet das über Zero Trust an, dann braucht aber jedes zugreifende Gerät einen installierten Client. Für reinen Fernzugriff auf die eigene Maschine ist Tailscale meist der bequemere Weg.

Was passiert, wenn der Server neu startet?

Nichts Besonderes, sofern du den Dienst mit systemctl enable aktiviert hast. cloudflared startet mit und baut die Verbindungen selbstständig wieder auf.

Kann ich mehrere Domains über einen Tunnel betreiben?

Ja, und das ist ausdrücklich vorgesehen. Die Regeln in der Konfigurationsdatei brauchen keine Freigabe pro Domain. Nur das Anlegen der DNS-Einträge ist an die jeweilige Zone gebunden — dafür meldest du dich einmal pro Domain an.