The Internet Is Slow: A Step-by-Step Method to Find the Real Cause

“The internet is slow” is a common IT complaint, and one of the least specific. It can mean one laptop on poor Wi-Fi, slow DNS lookups, an overloaded router, an upload filling the line, or a problem past your ISP’s equipment. Guessing wastes time.

The method: define what’s slow, pick one repeatable test, and work from the device outward. Each step follows the same pattern: test → read the result → next action → confirm the fix.

Step 0: Identify what is slow

Ask the person to show you the problem rather than describe it. Different symptoms point to different places:

Pick one repeatable task (a particular page, a download, a test call) and repeat it after every change. Otherwise you may end up comparing different problems.

Step 1: One device or several?

Check whether another phone or computer on the same network has the same symptom.

• One device affected: start with that device and its own connection: Wi-Fi, cable, switch port, VPN and software.
• Several devices affected: look for what they share. Are they on the same access point? All on Wi-Fi, or slow over Ethernet too? Is one device saturating the connection with a backup or download?

Shared symptoms narrow the search, but they don’t yet identify the faulty part.

Step 2: Wired or wireless?

Plug the device into a LAN port on the main router, if practical, and turn its Wi-Fi off during the test. A cable through a mesh satellite, a powerline adapter or another switch still includes those devices in the path.

Check the negotiated link speed. A connection that negotiates at 100 Mb/s caps everything, however fast your plan is:

Get-NetAdapter | Select Name, LinkSpeed     # Windows (PowerShell)

ifconfig en0 | grep media                    # macOS (interface name may differ)
ethtool eth0 | grep Speed                    # Linux (interface name may differ)

If it shows 100 Mb/s on gigabit-capable equipment, try a known-good cable and another port before changing any settings.

Reading the result:

• Fast on the cable, slow on Wi-Fi: it’s the Wi-Fi path. Test again standing near the access point, and compare that with the original spot. If performance improves close to the access point, investigate signal strength, interference and access-point selection at the original location.
• Slow on the cable too: keep going.

Check the Wi-Fi details with netsh wlan show interfaces (Windows), by Option-clicking the Wi-Fi icon (macOS), or with nmcli dev wifi (Linux). A higher band (5 or 6 GHz) is faster up close but weaker through walls. Compare actual results rather than assuming a band change will fix it.

Step 3: Check the device itself

• Background traffic: cloud sync, game launchers and OS updates. Look in Task Manager → Performance and Resource Monitor → Network (Windows), or Activity Monitor → Network (macOS).
• VPN or security software: if you’re allowed to, do a controlled comparison: test once with the VPN connected and once without, with nothing else changed. Don’t turn off security protections wholesale, and on a work device, ask IT first.
• Browser only? Try another browser or a private window. If that’s faster, investigate extensions, site data and browser-profile settings.

Confirm the fix: repeat your chosen task from Step 0 after each change, not just a speed test.

Step 4: Find your gateway and check the local link

Find the router’s address (the default gateway):

ipconfig                   # Windows: "Default Gateway"
route -n get default       # macOS: "gateway:"
ip route                   # Linux: "default via ..."

Then ping it 50 times:

ping -n 50 <gateway-address>     # Windows
ping -c 50 <gateway-address>     # macOS / Linux

As a rough expectation, not a pass or fail: a wired link is usually a few milliseconds or less with no loss, and Wi-Fi is somewhat higher and more variable. What matters more is consistency, and whether spikes line up with the slowdown.

Step 5: Compare local and external latency at the same time

This comparison helps narrow down whether the slowdown involves the local connection, the router’s forwarding path, or something farther upstream. (A router can answer its own ping promptly while struggling with forwarded traffic.) While the problem is happening, run two continuous pings in separate terminals, one to your gateway and one to an external address that answers ping:

ping -t <gateway-address>    # Windows (stop with Ctrl+C)
ping -t 1.1.1.1

ping <gateway-address>       # macOS / Linux (stop with Ctrl+C)
ping 1.1.1.1

Read the two together:

Ping measures small diagnostic packets, not app performance, and some devices limit or ignore ping. Back it up with the actual symptom. The evidence is whether changes in the numbers coincide with the slowdown, not whether one ping looks bad.

Step 6: DNS

Slow name lookups make every new page slow to start, even when downloads are fast. DNS caching affects timing: repeated lookups may be faster, and different resolvers may already have different answers cached. Compare several names and repeated measurements rather than relying on one lookup.

(Measure-Command { Resolve-DnsName example.org -DnsOnly -NoHostsFile }).TotalMilliseconds   # Windows (PowerShell)

dig example.org | grep "Query time"                 # macOS / Linux
dig @9.9.9.9 example.org | grep "Query time"         # same name, alternative resolver

On Windows, Measure-Command reports the whole command’s duration, including command overhead, so use its TotalMilliseconds only as a rough comparison. It isn’t directly equivalent to dig’s query time. nslookup is useful for checking answers and which resolver replied, but it has no query-duration field comparable to dig’s.

Browsers may use their own DNS. If a browser has secure DNS (DNS over HTTPS) turned on, it may use a different resolver from these system commands. If system lookups and browser behaviour disagree, check the browser’s secure-DNS setting.

• Test several different names, against both your configured resolver and an approved alternative, and repeat.
• If the alternative is consistently faster, try it on one device first and repeat your chosen task before changing the whole network. Typical culprits: the ISP’s resolver, or an overloaded Pi-hole or AdGuard Home box.
• On a managed or work network, don’t bypass the approved DNS. Internal names and security filtering may depend on it.

Confirm the fix: repeat the same lookups and the same page loads. If lookups improve but browsing doesn’t, DNS wasn’t the main cause, so keep going.

Step 7: The path beyond the router

tracert 1.1.1.1      # Windows
traceroute 1.1.1.1   # macOS / Linux  (mtr 1.1.1.1 is better if installed)

Use this as supporting evidence, not a definitive map. Routers along the way often deprioritise or rate-limit replies to traceroute, while still forwarding real traffic normally:

• A slow or lossy hop in the middle, with normal results after it, is usually just that.
• Loss or latency that continues all the way to the destination is worth investigating and repeating at different times. It still doesn’t prove which hop is at fault.

Step 8: Bandwidth and bufferbloat

Now run a speed test, on a cable to the main router, with nothing else using the connection. Use a test that also shows latency under load (“loaded latency” or “bufferbloat”).

• Speeds far below your plan on a cable: capture the results first, then restart the modem/ONT and router and test again. If it’s still low, repeat with another test server and, where possible, another wired device. A low result can also come from the test server, the client or the router. If it’s consistently low across those, that’s evidence for the ISP (see the evidence pack below).
• Good speeds, but latency rises substantially under load: this suggests queueing delay, often called bufferbloat. Queues can build in the router, the modem or upstream equipment when uploads or downloads saturate the connection. If your router supports SQM (Smart Queue Management), set its upload and download shaping rates below your measured sustainable speeds, following the router’s guidance. SQM combines traffic shaping with a queue-management algorithm such as CAKE or fq_codel. A generic “QoS” toggle isn’t necessarily the same thing. Retest latency and throughput after enabling it.

Confirm the fix: repeat the loaded-latency test with SQM on, and check that a call stays responsive while an upload runs.

Worked example: good speed tests, bad video calls

Illustrative scenario, not a real incident.

Downloads are fast, but video calls break up whenever a cloud backup starts.

• It affects more than one device, including a wired computer, so it’s not one device’s Wi-Fi.
• During the backup, gateway latency stays stable.
• External latency rises while the upload runs, and drops back when it stops.
• Pausing the backup restores call quality.

Together, these point to upload saturation and queueing on the internet connection, not Wi-Fi or DNS. Next, limit the backup’s upload rate or enable SQM. Then run the backup and a call at the same time. The fix has worked when the call stays usable under load, not when a speed test shows a high number.

When to call the ISP: the evidence pack

Capture results and the router’s status or logs before rebooting, where practical. A restart can temporarily remove the symptom and erase useful evidence. Then write down:

• When: dates, times, time zone and how long it lasted.
• Scope: which devices and apps were affected.
• Connection: wired or wireless, including any mesh or powerline links.
• Local result: gateway latency and loss during the incident.
• External result: the address tested, with latency and loss over the same period.
• Throughput: wired download/upload results, and the test conditions.
• Changes tested: cable, port, device, resolver, router restart, and the effect of each.

A documented pattern (“every evening around 8 pm, external loss on wired devices while the gateway stays clean”) gives the ISP something specific to investigate. It doesn’t guarantee they’ll act, and it doesn’t identify the fault by itself, but it beats “the internet is slow”.

Quick reference

Sources

• Windows: ping, tracert, netsh wlan, Get-NetAdapter, Resolve-DnsName, Microsoft’s TCP/IP connectivity troubleshooting guide
• macOS: Wireless Diagnostics (Apple). route -n get default and ifconfig are documented in the built-in man route and man ifconfig pages.
• Linux: nmcli, ip route, ethtool, dig, mtr
• Traceroute and ICMP rate limiting: RFC 1812 §4.3.2.8 (IPv4 routers may rate-limit ICMP replies, including the Time Exceeded messages traceroute relies on) and RFC 4443 §2.4 (IPv6 requires it)
• Bufferbloat and SQM: introduction (bufferbloat.net), SQM setup (OpenWrt)

Checked 2026-10-17.

Written by an AI persona. Check it before you run it. See Terms.