Where Your Starlink Data Actually Goes

Ask where Starlink data goes and most answers stop at 'the satellite'. But the satellite is a relay. Your traffic has to reach the ordinary internet eventually, and how it gets there shapes your latency, your routing, and even what IP address you appear to have.

The path, hop by hop

A request from your laptop takes a fairly short route, but each hop matters.

• Your device to the Starlink router over Wi-Fi or Ethernet
• Router to the dish, over the single cable
• Dish to whichever satellite currently offers the best geometry — a link that hands over every few minutes
• Satellite to a gateway ground station, either directly or after one or more laser hops
• Gateway to a SpaceX point of presence, over terrestrial fibre
• Point of presence to the wider internet, via peering and transit like any other network

What a gateway looks like

A Starlink gateway is a fenced site holding a cluster of antennas, each inside a white radome that protects it from weather while remaining transparent to radio. A typical site has several — often eight or nine — so it can hold links to multiple satellites at once and hand over between them without interruption.

Gateways talk to satellites on Ka-band, with newer sites and satellites adding E-band, which offers far more bandwidth. They are placed where fibre backhaul exists, which is why they cluster near terrestrial network infrastructure rather than being spread evenly across the map.

This creates the geographic asymmetry underlying much of Starlink's routing: satellites are distributed evenly by orbital mechanics, gateways are distributed by where fibre already is.

Why gateway capacity is often the real bottleneck

It is tempting to think of the user link — dish to satellite — as the constraint. Frequently it is not.

Every user under a satellite shares that satellite's gateway link down to the ground. If a hundred subscribers in a region are all pulling data, all of it converges through the same satellite-to-gateway connection. That link is high capacity, but it is finite and shared in a way the individual user links are not.

This is why adding gateways improves service in a region even without launching a single satellite, and why E-band gateway links on newer hardware matter so much. It also explains why SpaceX's ground-station build-out proceeds continuously and quietly alongside the launches that get all the attention.

More satellites help. More gateways sometimes help more. The bottleneck is usually the shared path to the ground, not the path to your roof.

Points of presence

A gateway is not connected to the internet in any meaningful sense — it is connected to SpaceX's own network, which carries traffic over fibre to a point of presence, or PoP.

A PoP is where SpaceX meets the rest of the internet: a facility in a major interconnection hub where it peers with other networks and buys transit. There are relatively few of them compared with the number of gateways, and your traffic is routed to the nearest appropriate one.

This is why a Starlink user's traffic often appears to originate from a city some distance away. Your packets genuinely did enter the public internet there. It is also why services that guess your location from your IP address frequently guess wrong for Starlink users — a persistent annoyance with streaming catalogues and regional content.

CGNAT and what it breaks

Most Starlink connections sit behind carrier-grade NAT, meaning many subscribers share a single public IPv4 address. This is normal for large mobile networks and increasingly common everywhere, but it has consequences.

Inbound connections do not work by default. You cannot port-forward to a device on your network from the public internet, which affects self-hosted servers, some remote-access setups, certain game hosting, and a handful of peer-to-peer applications that expect an inbound path.

IPv6 is available and does not have this restriction, since there are enough addresses to give every device its own. For services that support IPv6 the problem largely disappears. For legacy IPv4-only services the usual workarounds apply: a relay service, a VPN with a routable endpoint, or a tunnel.

How crosslinks change the picture

Laser inter-satellite links let a satellite send traffic sideways to a neighbour rather than straight down, which means a user with no gateway in range can still be served — the constellation relays the data until it reaches a satellite that can see one.

This is what makes mid-ocean and polar service possible. It also adds latency, because each hop costs distance and processing, so the network prefers a direct gateway path whenever one exists.

The practical result is a two-tier experience. Users near good gateway coverage get the shortest possible path. Users in genuinely remote places get service at all, at the cost of some extra milliseconds — which is an excellent trade when the alternative is nothing.

What you can observe

Gateway locations are not published in a convenient list, but the effects are measurable. A traceroute from a Starlink connection shows where your traffic enters the terrestrial network, and the first terrestrial hop's location tells you roughly which PoP serves you.

The orbital half is fully observable here. The coverage view shows which satellites are above your horizon and at what elevation — and elevation drives the slant range that sets your latency floor. Combine that with where your traffic surfaces on the ground and you have a reasonable picture of the whole path.