Weg vom Festnetz: Gibt dir Starlink eine öffentliche IP-Adresse?

Ohne öffentliche IPv4-Adresse am Router reicht eine Portfreigabe dort nicht

Hat dein Router eine öffentliche IPv4-Adresse, leitet eine Portfreigabe darauf Verbindungen aus dem Internet an einen Rechner zu Hause weiter. Hat er keine, hält ein vorgelagertes Gerät mit Netzwerkadressübersetzung (NAT) diese Adresse, deines oder das deines Anbieters, und eine Portfreigabe auf deinem Router ist aus dem Internet nur erreichbar, wenn auch dieses NAT den Port weiterleitet. Ist das vorgelagerte NAT das Carrier-Grade NAT eines Anbieters, sagt RFC 6269: „If a CGN is present, the port must also be opened in the CGN. CGN makes subscribers dependent on their service provider for this functionality.“ Mit einem CGN muss der Port also auch dort geöffnet werden, und dafür sind Kunden von ihrem Anbieter abhängig (Abschnitt 5.2.1, abgerufen im Oktober 2026). RFC 6888 ergänzt, dass Kunden über ein Carrier-Grade NAT „limited or no control“ haben, also wenig oder keine Kontrolle (Abschnitt 2, abgerufen im Oktober 2026).

Seite 1, die Anleitung zum Selbsthosten ohne öffentliche IPv4-Adresse, hat einen Starlink-Anschluss zu Hause getestet. Der Trace der Route nach außen dort passt zu CGNAT, beweist es aber nicht, weil der zweite Hop nie geantwortet hat. Von einem Computer im Heimnetz liefen ausgehende Verbindungen über IPv4 auf Port 25 in einen Timeout, und wo sie verworfen wurden, ist nicht zu sehen. Seite 1 hat auch eingehende Ports von einem Virtual Private Server (VPS) aus geprüft, einem Cloud-Server.

Starlinks eigene Hilfeseite What IP address does Starlink provide? sagt: „Starlink WiFi routers do not support port forwarding or firewall rules for IPv4 or IPv6.“ Starlinks WLAN-Router unterstützen also weder Portfreigaben noch Firewall-Regeln, weder für IPv4 noch für IPv6. Dieselbe Seite sagt: „Outbound ports TCP/25 (SMTP) and TCP/445 (SMB) are blocked for all customers per information security best practices.“ Die ausgehenden Ports TCP/25 (SMTP) und TCP/445 (SMB) sind also nach bewährten Praktiken der Informationssicherheit für alle Kunden gesperrt. Beide Sätze wurden im Oktober 2026 abgerufen.

Was zu Hause von einer öffentlichen IPv4-Adresse abhängt:

• ein Server, mit dem sich andere verbinden, etwa ein Gameserver, eine Website oder ein Remote-Desktop;
• eine App, die selbst Ports auf dem Router öffnet;
• ein Mailserver, der Mail von anderen Servern empfängt;
• alles, was an eine gleichbleibende Adresse gebunden ist, etwa eine Allowlist oder ein DNS-Eintrag (unten).

Eine App öffnet Ports, indem sie den Router bei dir zu Hause fragt, in den Worten von RFC 6269 das CPE. Heimrouter öffnen eingehende Ports „either manually, or with a protocol such as“ UPnP IGD, also entweder von Hand oder mit einem Protokoll wie UPnP IGD, sagt der RFC, und mit einem Carrier-Grade NAT auf dem Weg gilt: „CPE and CGN will need to cooperate in order for port forwarding functionality to work“. CPE und CGN müssen also zusammenarbeiten, damit Portfreigaben funktionieren (Abschnitt 5.2.1). Ein Protokoll dafür, das Port Control Protocol (PCP), „allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall“, lässt also einen IPv6- oder IPv4-Host steuern, wie ein NAT oder eine einfache Firewall eingehende Pakete übersetzt und weiterleitet (RFC 6887, Zusammenfassung, abgerufen im Oktober 2026). REQ-9 in RFC 6888 lautet: „A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol“. Ein CGN muss also ein Protokoll bieten, mit dem Kunden ihre NAT-Zuordnungen ausdrücklich steuern, und das sollte PCP sein: eine Anforderung an jeden, der ein CGN baut, die nichts darüber sagt, was ein bestimmter Anbieter betreibt.

Im Oktober 2026 zeigte Tailscales Netzwerkprüfung, tailscale netcheck, auf einem Computer im Heimnetz keinen der Port-Mapping-Dienste an, nach denen sie sucht (UPnP, NAT-PMP und PCP). Tailscales CLI-Referenz sagt: „If any fields are blank, it means Tailscale wasn't able to measure that network property“, ein leeres Feld heißt also, dass Tailscale diese Eigenschaft des Netzes nicht messen konnte (zuletzt validiert im Juli 2026, abgerufen im Oktober 2026). Ein leeres Feld zeigt deshalb nicht, dass es keinen solchen Dienst gibt.

Mail zwischen Servern läuft über Port 25. RFC 6409 sagt: „Message relay is unaffected, and continues to use SMTP over port 25“, die Weiterleitung zwischen Servern nutzt also weiter SMTP über Port 25, während Mailprogramme Nachrichten „normally over port 587“ einliefern, normalerweise über Port 587 (Zusammenfassung, abgerufen im Oktober 2026). Ein Mailserver zu Hause empfängt die Mail anderer Server auf Port 25.

Prüfe, ob dein Router jetzt eine öffentliche IPv4-Adresse hat

Was dir ein Wechsel nimmt, hängt davon ab, was dein Anschluss dir heute gibt, und das zeigt dein eigener Router.

1. Schalte auf dem Gerät, das du dafür nutzt, jedes Virtual Private Network (VPN), jeden Proxy und jede Exit-Node ab. Vergleiche dann die WAN- oder Internetadresse auf der Statusseite deines Routers mit der öffentlichen IPv4-Adresse, die ein Abfragedienst für deinen Anschluss meldet. Stimmen sie überein, hat der Router eine öffentliche IPv4-Adresse, und eine Portfreigabe auf ihm kann Verbindungen annehmen.
2. Unterscheiden sie sich, hält ein NAT zwischen deinem Router und dem Internet die öffentliche Adresse, und die eigene WAN-Adresse des Routers verrät, wessen NAT das ist. Liegt sie in 100.64.0.0/10, dem Block, den RFC 6598 als gemeinsamen Adressraum für Carrier-Grade NAT reserviert, ist es das des Anbieters. Liegt sie in 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16, den privaten Blöcken aus RFC 1918, ist es ein anderes NAT, ein Router von dir oder vom Anbieter. So oder so ist eine Portfreigabe auf deinem Router aus dem Internet nur erreichbar, wenn auch dieses NAT den Port weiterleitet, und dass sich die Adressen unterscheiden, sagt allein nicht, ob es das tut.

Beide Schritte stützen sich auf die RFCs oben (abgerufen im Oktober 2026); diese Seite hat den Vergleich an keinem Anschluss durchgeführt.

Wer den Server erreichen muss, entscheidet über den Ersatz

Ohne öffentliche IPv4-Adresse an deinem Router braucht ein Server zu Hause einen anderen Weg hinein. Diese Seite beschreibt fünf nach den eigenen Seiten ihrer Anbieter und testet keinen davon.

Weg hinein	Wer den Server erreichen kann
Starlinks Option einer öffentlichen IPv4-Adresse	Wer den Server erreichen kannJeder, auf den Ports, die dein eigener Router weiterleitet
Ein VPS-Relay	Wer den Server erreichen kannJeder, auf den Ports, die der VPS weiterleitet
Ein ausgehender Tunnel (Cloudflare Tunnel)	Wer den Server erreichen kannJeder mit einem Browser, bei einem Webdienst; bei anderen Diensten nur Besucher, die Cloudflares Client nutzen
Ein Mesh-VPN (Tailscale oder Headscale)	Wer den Server erreichen kannNur Geräte, die du hinzufügst
Eingehendes IPv6, mit deinem eigenen Router	Wer den Server erreichen kannAuf Starlinks Hilfeseite nicht angegeben; sie verweist Kunden, die eingehenden Datenverkehr brauchen, auf einen Router eines Drittanbieters

Was Starlinks Option einer öffentlichen IPv4-Adresse laut Starlink ändert

Die Hilfeseite What IP address does Starlink provide? nennt zwei IPv4-Richtlinien, „default“ und „public“, also Standard und öffentlich. Die Richtlinie „default“ „does not allow inbound traffic“, lässt laut der Seite also keinen eingehenden Datenverkehr zu. Wo „IPv4 inbound traffic is needed“, eingehender IPv4-Verkehr also nötig ist, verweist sie auf „a Starlink service plan with the public IPv4 option“, einen Starlink-Tarif mit der Option einer öffentlichen IPv4-Adresse (abgerufen im Oktober 2026).

Starlinks Hilfeseite zum Einstellen einer öffentlichen IP sagt: „The ability to update the IP policy to a Public IP is only available to the Local and Global Priority service plans.“ Die Richtlinie auf eine öffentliche IP umzustellen, ist also nur bei den Tarifen Local und Global Priority möglich (abgerufen im Oktober 2026).

Starlinks Hilfeseite zum Empfehlungsprogramm nennt acht berechtigte Tarife, jeder davon ein Residential- oder Roam-Tarif, und keinen Priority-Tarif (Oktober 2026).

Diese Seite hat die Option einer öffentlichen IPv4-Adresse nicht getestet.

Ein VPS-Relay, für einen Server, den andere erreichen

Ein VPS-Relay ist ein VPS mit eigener öffentlicher IP, der die Verbindungen von Besuchern durch einen Tunnel an einen Server zu Hause weiterreicht. Diese Seite hat keins getestet. Die Gameserver-Seite testet eins: ein TCP-Relay auf einer kostenlosen Cloud-VM, für einen Minecraft-Server zu Hause an Starlink.

Die Verbindung beginnt zu Hause: Der Server zu Hause hält einen Tunnel zum VPS offen, zum Beispiel mit WireGuard. WireGuards Quick Start sagt, ein Peer hinter NAT „must keep the NAT/firewall mapping valid, by periodically sending keepalive packets“, muss die Zuordnung im NAT oder in der Firewall also gültig halten, indem er regelmäßig Keepalive-Pakete sendet, dass „A sensible interval that works with a wide variety of firewalls is 25 seconds“, ein sinnvolles Intervall für sehr viele Firewalls also 25 Sekunden sind, und dass der Peer so „receive incoming connections long after network traffic has gone silent“, eingehende Verbindungen also auch lange nach dem letzten Datenverkehr empfangen kann (Abschnitt „NAT and Firewall Traversal Persistence“, abgerufen im Oktober 2026). Auf dem VPS werden die Ports, die du wählst, durch den Tunnel weitergeleitet, oder ein Reverse Proxy reicht Webanfragen weiter: Caddys Direktive reverse_proxy „Proxies requests to one or more backends“, leitet Anfragen also an ein oder mehrere Backends weiter (abgerufen im Oktober 2026).

Besucher verbinden sich mit der öffentlichen IP des VPS, und dein VPS-Anbieter transportiert den Datenverkehr. Was der VPS weiterleitet, ist zum Internet hin offen, also leite nur den Port weiter, den du veröffentlichen willst.

Ein ausgehender Tunnel, für Webdienste

Ein ausgehender Tunnel verbindet einen Server zu Hause von innen mit dem Netz eines Anbieters, und Besucher erreichen den Server über diesen Anbieter. Für diese Seite wurde keiner getestet.

Cloudflares Seite zu Cloudflare Tunnel sagt, dass er Ressourcen „without a publicly routable IP address“ mit Cloudflare verbindet, also ohne öffentlich routbare IP-Adresse, dass sein Connector, cloudflared, „creates outbound-only connections“, nur ausgehende Verbindungen aufbaut, und dass er „HTTP web servers, SSH servers, remote desktops, and other protocols“ verbinden kann, HTTP-Webserver, SSH-Server, Remote-Desktops und andere Protokolle (Seite zuletzt aktualisiert im August 2026, abgerufen im Oktober 2026). Cloudflares Seite zu Protokollen für veröffentlichte Anwendungen sagt, eine veröffentlichte Route weise Cloudflare an, „to proxy requests for your public hostname to a service running privately behind cloudflared“, also Anfragen an deinen öffentlichen Hostnamen an einen Dienst weiterzuleiten, der privat hinter cloudflared läuft, und „Non-HTTP services require installing cloudflared on the client for end users to connect“: Für Dienste, die nicht HTTP sind, müssen Endnutzer cloudflared auf ihrem Gerät installieren; für TCP und SSH führen Endnutzer cloudflared access tcp oder cloudflared access ssh aus (abgerufen im Oktober 2026).

Ein Besucher eines Webdienstes braucht also nur einen Browser. Für SSH, einen Remote-Desktop oder einen anderen Dienst ohne HTTP braucht jeder Besucher Cloudflares Client. Cloudflares Netz transportiert den Datenverkehr.

Ein Mesh-VPN, für deine eigenen Geräte

Ein Mesh-VPN verbindet deine eigenen Geräte miteinander, sodass nur die Geräte, die du hinzufügst, einen Server zu Hause erreichen, keine Besucher. Auch das testet diese Seite nicht.

Tailscale ist eins. Headscale nennt sich „an open source, self-hosted implementation of the Tailscale control server“, eine quelloffene, selbst gehostete Umsetzung von Tailscales Steuerserver, ausgelegt auf „a single Tailscale network (tailnet), suitable for a personal use“, ein einziges Tailscale-Netz für die persönliche Nutzung (abgerufen im Oktober 2026); Tailnet ist Tailscales Wort für ein solches Netz. Tailscales Seite zu Verbindungsarten sagt „All connections start as relayed through a DERP server“, jede Verbindung beginnt also über einen DERP-Server weitergeleitet, Tailscales Relay-Server, und „In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this“: In den meisten Umgebungen baut Tailscale direkte Verbindungen auf, aber manche Netzkonfigurationen (Hard NAT) können das verhindern (zuletzt validiert im Juni 2026, abgerufen im Oktober 2026). Entsteht kein direkter Weg, transportieren Tailscales Relays den Datenverkehr. Tailscales Beitrag How NAT traversal works von 2020 sagt „you can't reconfigure the ISP's CGNAT“, das CGNAT des Anbieters lässt sich also nicht umkonfigurieren, und „Aside from the port mapping protocols, everything from our current bag of tricks works fine in a CGNAT world“: Außer den Port-Mapping-Protokollen funktionieren alle bisherigen Kniffe auch mit CGNAT (August 2020, abgerufen im Oktober 2026).

Tailscales Prüfung im Heimnetz fand im Oktober 2026 auch, dass das NAT davor unabhängig vom Ziel dieselbe Zuordnung behielt (MappingVariesByDestIP: false). Tailscales CLI-Referenz stellt dem „a difficult NAT that varies the device's IP address depending on the destination“ gegenüber, ein schwieriges NAT, das die IP-Adresse des Geräts je nach Ziel ändert. Die Prüfung zeigt das NAT im Moment ihres Laufs, ohne eine Verbindung zwischen zwei Geräten zu beobachten, und zeigt also nicht, ob ein direkter Weg entstehen würde.

Was Starlink zu IPv6 sagt

Starlinks Hilfeseite What IP address does Starlink provide? sagt: „Starlink supports native IPv6 across all Starlink routers, kit versions, and service plans.“ Starlink unterstützt also natives IPv6 auf allen Routern, Kit-Versionen und Tarifen. Die Seite sagt auch: „Each Starlink is allocated one IPv4 address via DHCPv4 and a delegated /56 IPv6 prefix via DHCPv6-PD.“ Jedes Starlink bekommt also eine IPv4-Adresse per DHCPv4 und ein delegiertes /56-IPv6-Präfix per DHCPv6-PD. Zu eingehendem Datenverkehr: „Customers needing inbound traffic should consider using a third-party router, and if IPv4 inbound traffic is needed, a Starlink service plan with the public IPv4 option.“ Wer eingehenden Datenverkehr braucht, sollte also einen Router eines Drittanbieters in Betracht ziehen und, wenn eingehendes IPv4 nötig ist, einen Starlink-Tarif mit der Option einer öffentlichen IPv4-Adresse. Der Hinweis der Seite zu Portfreigaben, oben zitiert, nennt IPv6 ebenso wie IPv4. Und als allgemeine Aussage sagt sie: „As Starlink continues to expand and upgrades its global internet service, users may experience changes such as publicly routable addresses and non-CGNAT configurations.“ Während Starlink seinen Dienst ausbaut und verbessert, können Nutzer also Änderungen erleben, etwa öffentlich routbare Adressen und Konfigurationen ohne CGNAT. Alles abgerufen im Oktober 2026.

Das sind Starlinks Aussagen, und diese Seite testet keine davon. Ob eine Verbindung über IPv6 einen Server zu Hause erreicht, zeigt diese Seite nicht.

Was Starlinks Hilfeseite zu einer festen IP sagt

Auf Starlinks Hilfeseite What IP address does Starlink provide? sagt der Absatz zur Option einer öffentlichen IPv4-Adresse: „Although truly static IPs are not available, a reservation system retains the public IPv4 address and IPv6 prefix even when the system is off or rebooted. However, relocating the Starlink or software updates may change these addresses.“ Wirklich feste IPs gibt es also nicht, aber ein Reservierungssystem behält die öffentliche IPv4-Adresse und das IPv6-Präfix, auch wenn das System aus ist oder neu startet; ein Umzug des Starlink oder Software-Updates können diese Adressen aber ändern (abgerufen im Oktober 2026).

Eine Adresse, die sich ändert, bricht alles, was an sie gebunden ist: eine Allowlist, einen DNS-Eintrag, einen entfernten Client, der auf eine Adresse eingestellt ist. Mit einem Ersatz nutzen Besucher etwas, das sich mit der Adresse zu Hause nicht ändert. Über ein VPS-Relay ist das die öffentliche IP des VPS; WireGuards Startseite sagt „the server discovers the endpoint of its peers by examining from where correctly authenticated data originates“, der Server erkennt den Endpunkt seiner Peers also daran, woher korrekt authentifizierte Daten kommen, und „Thus, there is full IP roaming on both ends“, es gibt also volles IP-Roaming auf beiden Seiten (abgerufen im Oktober 2026), was diese Seite nicht getestet hat. Über Cloudflare Tunnel ist es der öffentliche Hostname, den Cloudflare zu deinem Dienst leitet.

Dynamisches DNS hält einen Namen auf eine wechselnde Adresse gerichtet. Ohne öffentliche IPv4-Adresse an deinem Router ist die einzige öffentliche IPv4-Adresse, auf die dieser Name zeigen kann, die des vorgelagerten NAT, das eine Verbindung nur dann weiterreicht, wenn es den Port weiterleitet (RFC 6269, Abschnitt 5.2.1, für ein Carrier-Grade NAT).

Was Starlinks US-Acceptable Use Policy zu Servern sagt

Starlinks US-Acceptable Use Policy erwähnt in ihrer Version vom Oktober 2026 den Betrieb eines Servers nicht. Hosting oder eingehende Verbindungen erwähnt sie ebenfalls nicht.

Die Policy nennt 13 Beispiele für Verstöße. Das letzte ist „any conduct that SpaceX, in its discretion, reasonably determines to be a misuse of the Services or Starlink Kit“, jedes Verhalten, das SpaceX nach eigenem Ermessen begründet als Missbrauch der Dienste oder des Kits einstuft, und überlässt diese Entscheidung damit SpaceX. Unter „EXCESSIVE USE OF NETWORK RESOURCES“, übermäßiger Nutzung von Netzressourcen, sagt sie: „SpaceX reserves the right to engage in reasonable network management to protect the overall network“. SpaceX behält sich also ein angemessenes Netzmanagement zum Schutz des gesamten Netzes vor.

Behalte deinen Anschluss, oder wechsle mit einem Plan

Deine Prüfung entscheidet, welcher Fall deiner ist.

1. Zeigte Schritt 1 keine öffentliche IPv4-Adresse an deinem Router und deutet Schritt 2 auf das NAT deines Anbieters, ist eine Portfreigabe auf deinem Router schon heute nur dort aus dem Internet erreichbar, wo auch dieses NAT den Port weiterleitet (RFC 6269, Abschnitt 5.2.1). Ohne eine solche Weiterleitung durch deinen Anbieter hast du heute keine eingehende IPv4-Portfreigabe, und ein Wechsel nimmt dir die nicht. Deutet Schritt 2 auf einen eigenen vorgelagerten Router, prüfe zuerst diesen.
2. Müssen nur deine eigenen Geräte deine Dienste erreichen, ist das der Fall für ein Mesh-VPN. Tailscales Dokumentation beschreibt ihn, und diese Seite hat ihn nicht getestet.
3. Müssen andere einen Server zu Hause erreichen, plane den Ersatz, bevor du wechselst: ein VPS-Relay oder einen ausgehenden Tunnel, nach ihrer Dokumentation und hier nicht getestet, oder die Option einer öffentlichen IPv4-Adresse eines Priority-Tarifs, nach Starlinks Hilfeseiten.
4. Betreibst du zu Hause einen Mailserver, der Mail direkt an andere Server schickt, behalte den Anschluss, an dem er läuft. Mail zwischen Servern nutzt Port 25 (RFC 6409), und Starlinks Hilfeseite sagt, ausgehendes TCP/25 sei „blocked for all customers“, für alle Kunden gesperrt. Im Test von Seite 1 liefen ausgehende Verbindungen über IPv4 auf Port 25 von einem Computer im Heimnetz in einen Timeout, und wo sie verworfen wurden, ist nicht zu sehen. Mail über ein VPS-Relay ist hier nicht getestet.

Hier noch nicht getestet

Alle fünf Wege hinein: Starlinks Option einer öffentlichen IPv4-Adresse, ein VPS-Relay, ein ausgehender Tunnel, ein Mesh-VPN und eingehendes IPv6.

Ob ein Relay weiterläuft, wenn sich die Adresse des Anschlusses zu Hause ändert. WireGuards Startseite sagt, dass es einem Peer folgt, dessen Adresse sich ändert; nichts hier testet das.

Mail, die über ein Relay verschickt wird.

Wo ausgehende Verbindungen auf Port 25 verworfen werden, was Seite 1 offenlässt.