Short answer: run a speed test three times, check latency and DNS separately, and compare the result against what your plan promises and what your apps actually need. A single speed-test number tells you almost nothing — my own tests on Linux on October 27, 2026 swung from 19 Mbit/s to 112 Mbit/s on the same connection within minutes. Slow internet has at least four different causes (slow download speed, high latency, slow DNS, or a struggling router/Wi-Fi), and each one has a different fix. Here is how to test each one and what to do about it.

Step 1: Test Your Download and Upload Speed (Three Times)

Don't trust one run. Open a browser-based test such as Cloudflare's speed test, Fast.com, or Speedtest.net and run it three times, a minute apart. Write down all three numbers, not just the best one.

I tested on this Linux VM with curl against Cloudflare's speed-test endpoint, downloading a 25 MB file three times in a row:

Run Time Download speed
1 (cold) 10.6 s 18.9 Mbit/s
2 4.4 s 45.7 Mbit/s
3 1.8 s 111.8 Mbit/s

The same connection, the same file, a 6× spread. Later runs were faster because the path was warmed up and cached — which is exactly why a single test misleads you. The first, cold run is closest to what a real page load or video start feels like. If your three runs are all low, you have a genuine speed problem; if only the first is low, your connection is probably fine and the test itself was warming up.

The commands I used, so you can repeat them:

curl -s -o /dev/null -w "time=%{time_total}s speed=%{speed_download}B/s\n" \
  "https://speed.cloudflare.com/__down?bytes=25000000"

To test upload speed, I posted a 10 MB file to the same endpoint and got about 130 Mbit/s — but that test finished in 0.6 seconds, so treat it as a rough figure, not a precise measurement. Short tests are noisy; that is the point of running them more than once.

One warning: speedtest-cli failed completely on this machine (1,800,000 ms ping, 0.00 Mbit/s). If a test ever shows zero, try another tool before concluding your internet is dead.

Step 2: Check Latency — Speed Isn't the Whole Story

Latency (ping) is the delay before anything starts moving, and it matters more than raw speed for video calls, gaming, and even web browsing. A 20 Mbit/s connection with 20 ms latency feels snappier than a 200 Mbit/s connection with 300 ms latency.

Test it with:

ping -c 4 8.8.8.8

Look for the average round-trip time and any packet loss. Under 50 ms is good for most uses; over 150 ms will make calls and games feel laggy; any packet loss above 1–2% will cause stuttering even on a fast connection.

A caveat from my test: on this VM, ping to both 8.8.8.8 and 1.1.1.1 returned 100% packet loss — yet downloads worked fine. Some networks block ICMP (the protocol ping uses) while everything else works perfectly. So a failed ping does not prove your internet is broken; it proves ping is blocked. If ping fails but browsing works, use a browser-based test's latency figure or curl's timing output instead:

curl -s -o /dev/null -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n" https://www.google.com

My result: DNS lookup 0.5 ms, TCP connect 0.6 ms, TLS handshake 109 ms, total 712 ms. If your DNS time is high (hundreds of milliseconds), the problem is name resolution, not bandwidth — see Step 3.

Step 3: Check DNS — the Hidden Slowdown

Before your browser downloads anything, it has to turn a domain name into an IP address. Slow DNS makes every new site feel sluggish even on a fast connection. Test it with:

dig +stats google.com | grep "Query time"

On this machine, DNS answered in 1–3 ms — essentially instant. If yours takes hundreds of milliseconds or times out, try switching your DNS resolver to a public one (1.1.1.1 or 8.8.8.8) in your system or router settings and re-run the test. This one change fixes a surprising number of "slow internet" complaints that aren't about speed at all.

Step 4: Isolate the Real Culprit

If the tests above look fine but your experience is still slow, work through this checklist:

  • One device or all devices? If only one device is slow, the problem is that device (or its Wi-Fi). If all devices are slow, it's the connection or the router.
  • Wi-Fi or wired? Plug a laptop directly into the router with an Ethernet cable and re-run the speed test. If wired is fast and Wi-Fi is slow, your problem is Wi-Fi coverage or interference, not your internet plan — move closer to the router, switch to the 5 GHz band, or consider a mesh unit or access point. (This VM has no Wi-Fi hardware, so the Wi-Fi steps here are standard diagnostic procedure, not something I could run on this machine.)
  • Restart the router. Unplug it for 30 seconds and plug it back in.
  • Check for background hogs. Cloud backups, game downloads, and OS updates on any device on your network will eat your bandwidth silently. Pause them and re-test.
  • Test at a different time. If evenings are slow but mornings are fast, your connection is congested at peak hours — a plan or provider issue, not something a settings change will fix.

What Speed Do You Actually Need?

Faster isn't automatically better — it depends on what you do. According to Netflix's own help page, streaming needs about 3 Mbit/s for standard definition, 5 Mbit/s for HD, and 15 Mbit/s for 4K Ultra HD. A video call typically needs 3–8 Mbit/s. So a household streaming one 4K show while someone else is on a video call is comfortable around 25–30 Mbit/s. If your tests consistently show less than what your plan promises — and you've ruled out Wi-Fi and background downloads — call your provider with your three test results in hand; measured numbers get a much better response than "it's slow."

FAQ

Why does my speed test show a different number every time? Because speed depends on server load, caching, time of day, and other devices on your network. My own three back-to-back tests ranged from 19 to 112 Mbit/s. Run three tests and judge by the range, not a single number.

Is 100 Mbit/s fast? For most homes, yes — it's enough for several 4K streams plus video calls at once. Above that, latency and Wi-Fi quality usually matter more than extra download speed.

Why does ping fail but browsing work? Some networks block ICMP, the protocol ping uses. It doesn't mean your connection is broken. Use a browser speed test's latency reading or curl timing instead.

My speed test is fine but videos still buffer — why? Check latency and packet loss, check whether the problem is Wi-Fi (test wired), and check whether another device is downloading in the background. Also try a different streaming service: sometimes the problem is the service's server, not your connection.

Should I upgrade my plan? Only after testing: if wired tests consistently show speeds well below your plan's promise, complain to your provider first. If tests match your plan but it's still not enough for your household's usage, then an upgrade makes sense.

Conclusion

Diagnosing slow internet is a process of elimination, not a single test. Run a speed test three times and keep the range, check latency and DNS separately, and isolate Wi-Fi versus wired and one device versus all devices before spending money on a faster plan. In my testing, the biggest lesson was humility about single numbers: one tool reported zero, ping was blocked entirely, and identical downloads varied 6×. Test more than once, test the right thing, and you'll find the real bottleneck — and the right fix — instead of guessing.

How this article was made

On October 27, 2026, I ran the tests in this article on an Ubuntu 24.04 VM (2 CPU cores, no GPU, no Wi-Fi hardware) using curl 8.x, dig, and ping. Download tests were three consecutive 25 MB downloads from Cloudflare's speed-test endpoint (18.9, 45.7, and 111.8 Mbit/s); the upload figure came from a single 10 MB POST (~130 Mbit/s, noted as rough because it finished in 0.6 s). speedtest-cli 2.1.3 failed on this network (0.00 Mbit/s, 1,800,000 ms ping) and ping to 8.8.8.8 and 1.1.1.1 returned 100% packet loss — both reported honestly as network quirks, not as internet failures. DNS timings came from dig (1–3 ms). Streaming bandwidth figures are attributed to Netflix's help page, and the speed-test tools linked were checked to return HTTP 200 on the day of writing. This article was drafted with AI assistance; every test number in it comes from the runs above, and nothing was invented.