Leaving a wired ISP: does Starlink give you a public IP address?

Without a public IPv4 address on your router, a port forward there isn't enough

If your router holds a public IPv4 address, a port forward on it sends connections from the internet to a machine at home. If it doesn't, a device upstream doing network address translation (NAT) holds that address, yours or your provider's, and a port forward on your router reaches the internet only if that NAT forwards the port too. Where the upstream NAT is a provider's carrier-grade NAT, RFC 6269 says "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." (section 5.2.1, checked October 2026). RFC 6888 adds that subscribers have "limited or no control" over a carrier-grade NAT (section 2, checked October 2026).

Page 1, the guide to self-hosting without a public IPv4 address, tested a home Starlink connection. Its trace of the route out fits CGNAT but doesn't prove it, since the second hop never answered. From a computer on the home network, outbound connections over IPv4 on port 25 timed out, and where they were dropped isn't shown. Page 1 also tried inbound ports from a virtual private server (VPS), a cloud server.

Starlink's own help page What IP address does Starlink provide? says "Starlink WiFi routers do not support port forwarding or firewall rules for IPv4 or IPv6." The same page says "Outbound ports TCP/25 (SMTP) and TCP/445 (SMB) are blocked for all customers per information security best practices." Both lines were checked in October 2026.

What depends on a public IPv4 address at home:

• a server other people connect to, such as a game server, a website or a remote desktop;
• an app that opens ports on the router by itself;
• a mail server that receives mail from other servers;
• anything pinned to an address that stays the same, such as an allowlist or a DNS record (below).

An app opens ports by asking the router on your premises, the CPE in RFC 6269's terms. Home routers open incoming ports "either manually, or with a protocol such as" UPnP IGD, the RFC says, and with a carrier-grade NAT in the path, "CPE and CGN will need to cooperate in order for port forwarding functionality to work" (section 5.2.1). One protocol for that, the 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" (RFC 6887, abstract, checked October 2026). RFC 6888's REQ-9 reads "A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol": a requirement on whoever builds one, which says nothing about what a given provider runs.

In October 2026, Tailscale's network check, tailscale netcheck, on a computer on the home network listed none of the port-mapping services it looks for (UPnP, NAT-PMP and PCP). Tailscale's CLI reference says "If any fields are blank, it means Tailscale wasn't able to measure that network property" (last validated July 2026, checked October 2026), so an empty field doesn't show that no such service exists.

Mail between servers travels on port 25. RFC 6409 says "Message relay is unaffected, and continues to use SMTP over port 25", while mail programs submit messages "normally over port 587" (abstract, checked October 2026). A mail server at home receives other servers' mail on port 25.

Check whether your router has a public IPv4 address now

What switching takes away depends on what your connection gives you today, and your own router shows it.

1. Turn off any virtual private network (VPN), proxy or exit node on the device you use for this. Then compare the WAN or internet address on your router's status page with the public IPv4 address a lookup service reports for your connection. If they match, the router holds a public IPv4 address, and a port forward on it can receive connections.
2. If they differ, a NAT between your router and the internet holds the public address, and the router's own WAN address says whose. Inside 100.64.0.0/10, the block RFC 6598 sets aside as shared address space for carrier-grade NAT, it is the provider's. Inside 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, the private blocks of RFC 1918, it is another NAT, a router of yours or the provider's. Either way, a port forward on your router reaches the internet only if that NAT forwards the port too, and "differ" alone doesn't say whether it does.

Both steps rest on the RFCs above (checked October 2026); this page didn't run the comparison on any connection.

Who has to reach the server decides the replacement

Without a public IPv4 address on your router, a server at home needs another way in. This page describes five from their providers' own pages and tests none of them.

Way in	Who can reach the server
Starlink's public IPv4 option	Who can reach the serverAnyone, on the ports your own router forwards
A VPS relay	Who can reach the serverAnyone, on the ports the VPS forwards
An outbound tunnel (Cloudflare Tunnel)	Who can reach the serverAnyone with a browser, for a web service; for other services, only visitors who run Cloudflare's client
A mesh VPN (Tailscale or Headscale)	Who can reach the serverOnly devices you add to it
Inbound IPv6, with your own router	Who can reach the serverNot stated on Starlink's help page, which points customers who need inbound traffic to a third-party router

What Starlink says its public IPv4 option changes

The help page What IP address does Starlink provide? names two IPv4 policies, "default" and "public". The "default" policy, it says, "does not allow inbound traffic". Where "IPv4 inbound traffic is needed", it points to "a Starlink service plan with the public IPv4 option" (checked October 2026).

Starlink's help page on setting a public IP says "The ability to update the IP policy to a Public IP is only available to the Local and Global Priority service plans." (checked October 2026). Those plans' prices, by date, are on the plans and prices page, whose public IP section cites the same two help pages.

Starlink's referral help page lists eight eligible plans, each a Residential or Roam plan, and no Priority plan (October 2026).

This page hasn't tested the public IPv4 option.

A VPS relay, for a server other people reach

A VPS relay is a VPS with its own public IP that passes visitors' connections down a tunnel to a server at home. This page hasn't tested one. The game server page tests one: a TCP relay on a free-tier cloud VM, for a Minecraft server at home on Starlink.

The connection starts at home: the home server keeps a tunnel open to the VPS, for example with WireGuard. WireGuard's Quick Start says a peer behind NAT "must keep the NAT/firewall mapping valid, by periodically sending keepalive packets", that "A sensible interval that works with a wide variety of firewalls is 25 seconds", and that this lets the peer "receive incoming connections long after network traffic has gone silent" (section "NAT and Firewall Traversal Persistence", checked October 2026). On the VPS, the ports you choose are forwarded down the tunnel, or a reverse proxy passes web requests along: Caddy's reverse_proxy directive "Proxies requests to one or more backends" (checked October 2026).

Visitors connect to the VPS's public IP, and your VPS provider carries the traffic. Whatever the VPS forwards is open to the internet, so forward only the port you mean to publish.

An outbound tunnel, for web services

An outbound tunnel connects a server at home to a provider's network from the inside, and visitors reach the server through that provider. None was tested for this page.

Cloudflare's page on Cloudflare Tunnel says it connects resources to Cloudflare "without a publicly routable IP address", that its connector, cloudflared, "creates outbound-only connections", and that it can connect "HTTP web servers, SSH servers, remote desktops, and other protocols" (page last updated August 2026, checked October 2026). Its page on protocols for published applications says a published application route instructs Cloudflare "to proxy requests for your public hostname to a service running privately behind cloudflared", and that "Non-HTTP services require installing cloudflared on the client for end users to connect": for TCP and SSH, end users run cloudflared access tcp or cloudflared access ssh (checked October 2026).

So a visitor to a web service needs only a browser. For SSH, a remote desktop or another non-HTTP service, every visitor needs Cloudflare's client. Cloudflare's network carries the traffic.

A mesh VPN, for your own devices

A mesh VPN links your own devices to each other, so only the devices you add can reach a server at home, not visitors. This page doesn't test one either.

Tailscale is one. Headscale calls itself "an open source, self-hosted implementation of the Tailscale control server", scoped to "a single Tailscale network (tailnet), suitable for a personal use" (checked October 2026); a tailnet is Tailscale's word for one such network. Tailscale's page on connection types says "All connections start as relayed through a DERP server", Tailscale's relay servers, and "In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this" (last validated June 2026, checked October 2026). When no direct path forms, Tailscale's relays carry the traffic. Its 2020 post How NAT traversal works says "you can't reconfigure the ISP's CGNAT", and "Aside from the port mapping protocols, everything from our current bag of tricks works fine in a CGNAT world" (August 2020, checked October 2026).

Tailscale's check on the home network, in October 2026, also found that the NAT in front of it kept the same mapping whatever the destination (MappingVariesByDestIP: false). Tailscale's CLI reference contrasts that with "a difficult NAT that varies the device's IP address depending on the destination". The check shows the NAT at the moment it ran, with no connection between two devices to watch, so it doesn't show whether a direct path would form.

What Starlink says about IPv6

Starlink's help page What IP address does Starlink provide? says "Starlink supports native IPv6 across all Starlink routers, kit versions, and service plans." It also says "Each Starlink is allocated one IPv4 address via DHCPv4 and a delegated /56 IPv6 prefix via DHCPv6-PD." On inbound traffic: "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." Its note on port forwarding, quoted above, names IPv6 as well as IPv4. And as a general statement, it says "As Starlink continues to expand and upgrades its global internet service, users may experience changes such as publicly routable addresses and non-CGNAT configurations." All of it was checked in October 2026.

These are Starlink's statements, and this page tests none of them. Whether a connection over IPv6 reaches a server at home isn't shown here.

What Starlink's help page says about a static IP

On Starlink's help page What IP address does Starlink provide?, the paragraph on the public IPv4 option says "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." (checked October 2026).

An address that changes breaks whatever is pinned to it: an allowlist, a DNS record, a remote client set to one address. With a replacement, visitors use something that doesn't change with the home's address. Through a VPS relay, that is the VPS's public IP; WireGuard's home page says "the server discovers the endpoint of its peers by examining from where correctly authenticated data originates" and "Thus, there is full IP roaming on both ends" (checked October 2026), which this page hasn't tested. Through Cloudflare Tunnel, it is the public hostname Cloudflare routes to your service.

Dynamic DNS keeps a name pointed at a changing address. Without a public IPv4 address on your router, the only public IPv4 address that name can point to is the upstream NAT's, which passes a connection on only if it forwards the port (RFC 6269, section 5.2.1, for a carrier-grade NAT).

What Starlink's Acceptable Use Policy says about servers

Starlink's Acceptable Use Policy, in its October 2026 version, doesn't mention running a server. It doesn't mention hosting or inbound connections either.

The policy lists 13 examples of violations. The last is "any conduct that SpaceX, in its discretion, reasonably determines to be a misuse of the Services or Starlink Kit", which leaves that call to SpaceX. Under "EXCESSIVE USE OF NETWORK RESOURCES", it says "SpaceX reserves the right to engage in reasonable network management to protect the overall network".

Keep the line you have, or switch with a plan

Your check decides which case is yours.

1. If step 1 showed no public IPv4 address on your router and step 2 points to your provider's NAT, a port forward on your router reaches the internet today only where that NAT forwards the port too (RFC 6269, section 5.2.1). Without such a forward from your provider, you have no inbound IPv4 port forwarding today, and switching doesn't take that away. If step 2 points to a router of your own upstream, check that router first.
2. If only your own devices need to reach your services, that is the mesh VPN case. Tailscale's documentation describes it, and this page hasn't tested it.
3. If other people need to reach a server at home, plan the replacement before you switch: a VPS relay or an outbound tunnel, from their documentation and not tested here, or a Priority plan's public IPv4 option, from Starlink's help pages, with the plans' prices on the plans and prices page.
4. If you run a mail server at home that sends mail straight to other servers, keep the line it runs on. Mail between servers uses port 25 (RFC 6409), and Starlink's help page says outbound TCP/25 is "blocked for all customers". In page 1's test, outbound connections over IPv4 on port 25 timed out from a computer on the home network, and where they were dropped isn't shown. Mail through a VPS relay isn't tested here.

If the replacement you're weighing is another satellite service, the satellite internet comparison sets what each provider publishes on latency, price and data beside Starlink's.

Not tested here yet

All five ways in: Starlink's public IPv4 option, a VPS relay, an outbound tunnel, a mesh VPN and inbound IPv6.

Whether a relay keeps running when the home connection's address changes. WireGuard's home page says it follows a peer whose address changes; nothing here tests it.

Mail sent through a relay.

Where outbound connections on port 25 are dropped, which page 1 leaves open.