Slow Internet Speed: How to Diagnose and Fix
Embed This Widget
Add the script tag and a data attribute to embed this widget.
Embed via iframe for maximum compatibility.
<iframe src="https://ipfyi.com/iframe/guide/slow-internet-speed/" width="420" height="400" frameborder="0" style="border:0;border-radius:10px;max-width:100%" loading="lazy"></iframe>
Paste this URL in WordPress, Medium, or any oEmbed-compatible platform.
https://ipfyi.com/guide/slow-internet-speed/
Add a dynamic SVG badge to your README or docs.
[](https://ipfyi.com/guide/slow-internet-speed/)
Use the native HTML custom element.
Measure your true internet speed, isolate whether the bottleneck is Wi-Fi, your router, your ISP, or your hardware, and apply targeted fixes including QoS and MTU tuning.
Measuring Your Speed Correctly
Before blaming your ISP, measure your speed accurately. Many users run one speed test on a congested server and draw incorrect conclusions.
# Install speedtest-cli
pip install speedtest-cli
speedtest --simple
# Or use the Ookla CLI (more accurate)
# macOS
brew install speedtest-cli
speedtest
# Linux (Ubuntu/Debian)
sudo apt install speedtest-cli
speedtest-cli --simple
# Test against a specific server (avoids congested test nodes)
speedtest-cli --list | grep "New York"
speedtest-cli --server 1234
Rules for accurate speed measurement:
- Run at least three tests and take the average — single measurements vary by 20-30%.
- Test at different times of day. ISP speeds often drop 20-40% during peak hours (7–10 PM).
- Use a server geographically close to you for baseline, then a distant server to check routing.
- Close all other applications and browser tabs before testing.
Understanding your results:
| Metric | Good | Concerning |
|---|---|---|
| Download | ≥ 80% of advertised speed | < 50% of advertised speed |
| Upload | ≥ 80% of advertised (fiber), ≥ 40% (cable) | < 25% of advertised |
| Latency | < 20 ms (fiber), < 40 ms (cable), < 60 ms (DSL) | > 100 ms |
| Jitter | < 5 ms | > 20 ms |
Wi-Fi vs Wired Testing
Wi-Fi is the most common source of perceived slow internet. Always test wired before concluding the ISP is at fault.
# Test from a wired device connected directly to the modem (bypass router)
speedtest --simple
# Compare to wireless test from the same location
speedtest --simple
Wi-Fi speed killers:
- Distance and walls — Speed drops sharply at range. 2.4 GHz penetrates walls better; 5 GHz is faster but shorter range.
- Channel interference — Check nearby networks with
iwlist wlan0 scan | grep -E "ESSID|Channel"(Linux) or a Wi-Fi analyzer app. Switch to a less congested channel. - Outdated Wi-Fi standard — Wi-Fi 4 (802.11n) maxes at ~150 Mbps. Wi-Fi 5 (802.11ac) reaches 1300 Mbps. Wi-Fi 6 (802.11ax) reaches 9.6 Gbps theoretical.
- Too many connected clients — A router managing 30+ devices at once becomes CPU-bound.
# Linux: check Wi-Fi signal strength and link rate
iwconfig wlan0
# Look for: Link Quality and Bit Rate
If your wired speed matches the ISP plan but wireless is slow, the problem is your Wi-Fi setup, not the ISP.
Router Bottlenecks
Consumer routers, particularly older ones, become the bottleneck on high-speed connections.
Signs your router is the bottleneck:
- Wired speed from the router is 40-50% of the speed measured by connecting directly to the modem.
- CPU usage on the router admin page shows sustained 90%+ during speed tests.
- The router model was purchased when your plan was slower.
Common router CPU limitations:
| Router Class | Typical Max Throughput |
|---|---|
| Budget router (2015-2018) | 200-400 Mbps |
| Mid-range router (2019-2021) | 500-900 Mbps |
| High-end router (2022+) | 1-2.5 Gbps |
If you have a 1 Gbps plan and a 2018 budget router, the router is your ceiling. Upgrading to a router with hardware NAT offloading (such as TP-Link Archer AX series or ASUS RT-AX series) resolves this.
Also check: DNS query latency from the router. Some routers forward DNS inefficiently. Setting your devices to use 1.1.1.1 directly instead of routing through the router's DNS relay can reduce latency by 10-30 ms.
ISP Throttling Detection
Some ISPs throttle specific services (Netflix, YouTube, torrent traffic) while leaving speed test traffic unthrottled. This means your speed tests look fine but streaming is slow.
# Test speed through a VPN (bypasses ISP traffic shaping)
# Install a VPN client, connect to a server in the same region
speedtest --simple
# Compare:
# Without VPN: Netflix slow, speed test fast → ISP throttling specific services
# With VPN: everything fast → confirmed throttling
# Test specific video streaming paths
# Using curl to download from a CDN node
curl -o /dev/null -s -w "%{speed_download}" https://proof.ovh.net/files/100Mb.dat
The Internet Health Test (https://www.battleforthenet.com/internethealthtest/) specifically tests connections to interconnection points where throttling commonly occurs.
If ISP throttling is confirmed, your options are:
- VPN — Encrypts traffic so ISP cannot classify it. Adds some latency but prevents throttling.
- Contact ISP — Ask about their traffic management policies.
- Switch providers — If throttling violates your service agreement.
QoS Configuration
Quality of Service (QoS) prioritizes important traffic when your connection is saturated. Without QoS, a file download can monopolize the connection and make video calls unusable.
Most modern routers include QoS in the admin panel. Configure it to prioritize:
- VoIP and video calls (UDP, ports 5060, 16384–32767) — Highest priority
- DNS (UDP port 53) — High priority
- Interactive browsing (HTTP/HTTPS) — Medium priority
- Background downloads (BitTorrent, Windows Update) — Lowest priority
For Linux routers or advanced setups, use tc (traffic control):
# Limit background traffic to 10 Mbps (leaves 90 Mbps for interactive traffic)
# Replace eth0 with your WAN interface
# Create a root qdisc
sudo tc qdisc add dev eth0 root handle 1: htb default 30
# Total bandwidth limit (e.g., 100 Mbps connection)
sudo tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit
# High priority class (60 Mbps)
sudo tc class add dev eth0 parent 1:1 classid 1:10 htb rate 60mbit ceil 100mbit prio 1
# Low priority class (background, 10 Mbps)
sudo tc class add dev eth0 parent 1:1 classid 1:30 htb rate 10mbit ceil 30mbit prio 3
# Mark BitTorrent traffic (port 6881-6889) for low priority
sudo iptables -t mangle -A POSTROUTING -p tcp --dport 6881:6889 -j MARK --set-mark 30
MTU Optimization
The Maximum Transmission Unit (MTU) is the largest packet your connection can carry. A misconfigured MTU causes fragmentation, which slows throughput and can break certain connections entirely.
The standard Ethernet MTU is 1500 bytes. PPPoE connections used by DSL and some fiber reduce this to 1492. VPNs reduce it further (1400-1450 typical).
# Find the optimal MTU using ping with the DF (don't fragment) bit
# Start at 1500 and decrease until ping succeeds
# Linux/macOS
ping -M do -s 1472 8.8.8.8 # 1472 bytes payload + 28 bytes ICMP header = 1500 total
ping -M do -s 1464 8.8.8.8 # Try smaller values until it works
# Windows (DF bit is -f)
ping -f -l 1472 8.8.8.8
# Once you find the maximum working payload size, add 28 for ICMP overhead
# That is your optimal MTU
# Set MTU on Linux
sudo ip link set dev eth0 mtu 1492
# Persist across reboots (add to /etc/network/interfaces or NetworkManager config)
A symptom of MTU mismatch: websites load slowly or not at all, but ping works fine. Large packets are silently dropped while small control packets pass through.
When Hardware Is the Problem
After eliminating software causes, test hardware:
# Check network card errors (Linux)
ip -s link show eth0
# Look for: TX errors, RX errors, dropped packets
# Check cable quality (if you have a managed switch)
# Look for CRC errors in switch interface statistics
# Test with a different cable
# Cable testers are inexpensive ($15-30) and quickly identify bad cables
# Check for NIC firmware updates
# For Intel NICs:
ethtool -i eth0 # Shows driver version
Faulty cables, failing network cards, and degraded cable modem signal levels (check the modem admin panel for SNR and power levels) all cause sustained speed degradation that software changes cannot fix.