Why the app you trust most is giving you the least honest answer
Testing your Starlink speed, the right way
Every Starlink forum, Subreddit, and Facebook group follows the same ritual. Someone posts a screenshot from the Starlink app showing 200 Mbps down and asks why their Netflix keeps buffering. Someone else fires back with their own screenshot — 340 Mbps, thank you very much. The numbers fly. The comparisons begin. And almost none of it means what anyone thinks it means.
Here’s the uncomfortable truth that the Starlink community doesn’t talk about enough: most of the speed tests people run — including the one baked right into the official Starlink app — are measuring something quite different from what you actually want to know. And if you care about real-world performance on the open internet, you need a better methodology.
The Starlink App Speed Test: Convenient, But Compromised
Let’s start with the elephant in the room. The Starlink app has a built-in speed test, and it’s the first place most new subscribers go to validate their investment. It’s right there, it’s slick, and it gives you big, satisfying numbers.
But here’s the problem: when you tap that button, your traffic almost certainly never leaves Starlink’s own infrastructure. The test endpoints are hosted within Starlink’s (i.e., SpaceX’s) network. You are, in effect, asking Starlink how fast Starlink is — and Starlink is telling you it’s very fast.
This is a bit like asking a restaurant to grade its own food. The incentives are misaligned, and the methodology is circular.
What the Starlink app test is actually measuring is the performance of your terminal, your local network, and the Starlink backhaul to their own servers. It tells you nothing meaningful about what happens when that traffic needs to leave SpaceX’s network and transit across the public internet — through peering agreements, interconnects, and congested backbone links — to reach an actual website, streaming service, cloud application, or video call endpoint that you care about.
The gap between those two measurements can be dramatic. You might see 250 Mbps in the Starlink app and then experience sluggish page loads, stuttering video calls, or poor gaming performance. People chalk this up to “Starlink being inconsistent” when in reality the test was never measuring the right thing to begin with.
The Public Speed Test Problem: Familiar Names, Sketchy Science
Okay, so you skip the app and go to one of the well-known public speed test websites instead. Surely Speedtest.net — owned by Ookla — is measuring your real internet speed, right?
Partially. But there are serious methodological issues here too, and the Starlink community tends to gloss right over them.
The closest server problem. Services like Speedtest.net default to whichever server is geographically or topographically nearest. That server may be hosted at an internet exchange point (IXP) that has a direct, highly optimized, low-congestion peering relationship with Starlink’s network. You’re not measuring the speed you get to Google, or to Amazon, or to the CDN edge node serving your favorite streaming platform. You’re measuring the speed to a server specifically optimized to be fast from your ISP.
CDN and hosting conflicts of interest. Some popular speed test services host their test servers on infrastructure that ISPs deliberately fast-lane or deprioritize strategically. The result is that speed tests can systematically flatter your ISP’s performance while failing to capture what you actually experience.
Server load variability. Public speed test servers are shared infrastructure. The server you’re hitting at 2 p.m. on a Tuesday may be saturated with other tests, introducing noise into your results that has nothing to do with your connection.
Single-threaded vs. multi-threaded confusion. Many of these sites don’t clearly communicate whether they’re running parallel streams (multi-threaded) or a single stream. On a high-latency connection like Starlink — where latency, while much improved, is still meaningfully higher than fiber — single-threaded TCP transfers will significantly understate available bandwidth due to TCP window size constraints and the speed-of-light limitations inherent to the satellite link. A tool that doesn’t account for this isn’t testing your throughput; it’s testing your latency penalty.
The net result is that Speedtest.net, Fast.com, and similar sites give you a number that’s better than the Starlink app’s internal test but still isn’t telling you the full story about your connection to the actual public internet.
What You Actually Need to Measure
Before we get to the solution, let’s be precise about what a meaningful speed test should accomplish.
A good speed test should:
Use servers distributed across the real public internet, not co-located inside your ISP’s network.
Use multiple parallel connections to saturate your link, because virtually all real-world usage involves multiple simultaneous streams.
Be operated by a neutral infrastructure provider with no financial incentive to make your ISP look good.
Measure latency and jitter, not just raw throughput, because on a satellite connection those numbers matter enormously for interactive applications.
Be transparent about its methodology so you can evaluate what it’s actually testing.
There is one tool that checks all of these boxes better than anything else available to consumers right now, and it’s completely free.
The Right Tool: speed.cloudflare.com
Cloudflare operates one of the largest distributed networks on the planet. Their infrastructure is present in hundreds of cities worldwide, and by necessity, it has peering and transit relationships with virtually every ISP — including Starlink. Cloudflare is not an ISP itself, and it has no financial incentive to make any particular ISP look artificially good or bad. Their speed test at speed.cloudflare.com reflects this neutrality.
Here’s what makes it meaningfully different:
Real public internet transit. When you test to Cloudflare’s servers, your traffic has to leave Starlink’s network and traverse whatever interconnects exist between SpaceX and Cloudflare. If that peering link is congested, you’ll see it. If Starlink is throttling certain traffic classes, you might see it. You are measuring reality, not a carefully curated best-case path.
Comprehensive metrics. The Cloudflare speed test doesn’t just give you a download and upload number. It gives you latency (both loaded and unloaded), jitter, and packet loss figures. For Starlink users, these numbers are often more revealing than raw throughput. You can have 200 Mbps of download bandwidth and still have terrible video call quality if your loaded latency is spiking or your jitter is high. Cloudflare shows you both dimensions.
Multi-stream testing. The tool uses multiple parallel connections to ensure it’s actually saturating your link, which means the throughput numbers reflect your real ceiling rather than what a single TCP stream can achieve against the physics of your satellite link.
No account required, no sketchy software, no upsells. Just go to the URL, run the test, and read the results. Cloudflare has no interest in selling you a VPN, promoting an ISP partner, or gamifying the experience to generate social shares.
Reading the Results: What to Look For
When you run a test on speed.cloudflare.com, here’s how to interpret what you see as a Starlink subscriber:
Download and Upload speeds are still useful numbers, but treat them as a range rather than a fixed truth. Run the test multiple times at different points during the day. Starlink performance varies with network congestion, satellite geometry, weather, and local terminal obstructions. A single test is a snapshot, not a portrait.
Unloaded latency tells you the baseline round-trip time when your connection is idle. Starlink Gen 2 (round dish) subscribers in good conditions should see somewhere in the 20–60 ms range. Substantially higher numbers during idle periods suggest either a congested Starlink point-of-presence (PoP) or a routing inefficiency.
Loaded latency is arguably the most important number for day-to-day experience. This measures latency while the connection is simultaneously being saturated with traffic — simulating what happens when someone in your household is downloading something while you’re on a video call, or when your smart home devices are all chatting at once. Loaded latency can easily be 5–10x higher than unloaded latency on a congested or poorly buffered link. High loaded latency is the invisible culprit behind many of the “Starlink feels slow even when the speed test is good” complaints you see in the forums.
Jitter measures variability in latency. A connection with 40 ms average latency but 2 ms of jitter is far better for real-time applications than one with 30 ms average and 25 ms of jitter. Starlink’s performance here has improved considerably with software updates and the Starlink Precision Time Protocol work, but it’s worth tracking.
A Practical Testing Protocol
If you want data that’s actually useful — for troubleshooting, for tracking changes after firmware updates, or for making an honest assessment of whether Starlink is meeting your needs — here’s a sensible approach:
Run speed.cloudflare.com at four representative times: early morning (low congestion baseline), midday, peak evening hours (typically 7–10 p.m. in your time zone), and late night. Log the results. Do this for a week before drawing any conclusions.
Test from a wired connection if at all possible. Connect a laptop directly to your Starlink router via ethernet. Wi-Fi introduces its own variables — interference, protocol overhead, device limitations — that can muddy the picture considerably. If you’re troubleshooting a specific device’s performance over Wi-Fi, that’s a different test with different goals.
Disable other internet activity on your network while testing. Background app updates, cloud backups, and streaming devices will affect your numbers.
Note conditions. Weather matters for Starlink. Wind, rain, and snow can affect signal quality. Note whether it’s clear or overcast when you record results.
Compare Cloudflare results to the Starlink app as a diagnostic tool. If your Cloudflare numbers are dramatically lower than the app’s internal test, that’s a signal worth investigating. It could indicate congestion at a Starlink-to-internet interconnect, a routing issue, or simply that the Starlink app is showing you flattering numbers that don’t survive contact with the real internet.
The Bigger Picture
None of this is a criticism of Starlink as a service. For rural and remote users, Starlink has been genuinely transformative — delivering broadband-class connectivity to places that had been stuck on 5 Mbps DSL or worse for decades. The technology is remarkable.
But the enthusiast community has developed some bad habits around speed testing that obscure more than they reveal. Bragging about Starlink app numbers is essentially bragging about how fast your ISP is when talking to itself. It’s not nothing, but it’s not what you think it is.
If you want to know how your Starlink connection performs on the actual internet — the internet where your work applications live, where your entertainment is streamed from, where your video calls travel — test it against the actual internet. Use speed.cloudflare.com. Look at latency and jitter, not just throughput. Test at different times. Keep records.
The truth might be more nuanced than a big number in the app suggests. But it’ll be the truth — and that’s worth a lot more than a flattering screenshot.
Have you compared your Starlink app results to Cloudflare’s speed test? The gap might surprise you.
