Why Your OpenWrt Router Speed Test Looks Slow
An OpenWrt router speed test can look slower than your plan even when the ISP line is healthy. The gap usually comes from CPU limits, Wi-Fi conditions, WAN negotiation problems, or settings like SQM and VPN that trade peak throughput for stability and lower latency. This article explains what the symptoms mean, how to separate router issues from modem or ISP issues, and how to test each layer in a clean sequence. It also covers practical tuning steps so you can improve download, upload, and latency without weakening reliability.
A slow router speed test does not always mean your ISP line is bad. On OpenWrt, the result can reflect the router CPU, Wi-Fi quality, WAN link negotiation, or settings that intentionally trade raw throughput for lower latency.
What a slow result on OpenWrt actually means
When you run a test on the router itself, you are measuring more than the broadband circuit. The router may be handling NAT, firewall rules, PPPoE, SQM, VPN encryption, or packet inspection at the same time. If the result is much lower than expected, the first question is not whether the ISP is broken, but which layer is limiting throughput.
Compare download, upload, and latency separately. A line that looks fast on download but unstable on latency usually points to congestion or queue management, not raw access speed.
Cause 1: CPU and software overhead
Many OpenWrt routers are fast enough for basic routing but not for full-speed testing once extra services are enabled. PPPoE, VPN tunnels, ad blocking, deep packet inspection, and certain firewall rules can saturate the processor before the WAN link does. In that case, the speed test result reflects router capacity, not ISP capacity.
The usual sign is a router that tops out at a repeatable ceiling, such as 200 Mbps or 400 Mbps, while CPU usage stays high during the test. If throughput rises after disabling a feature, the bottleneck is software or hardware acceleration, not the access line.
Cause 2: Wi-Fi is the real bottleneck
If the test runs from a wireless device, the result may be limited by the radio link rather than the internet connection. Signal strength, neighboring networks, channel width, client hardware, and band choice all affect the number you see. A 2.4 GHz connection often favors range over speed, while 5 GHz can be faster but more sensitive to distance and walls.
Test the same line with an Ethernet cable before changing router settings. If wired speed is healthy and Wi-Fi is not, the issue is radio placement, interference, or channel planning.
Cause 3: WAN link negotiation, cable, or modem issues
A bad Ethernet cable or a port that negotiates at the wrong speed can quietly cap throughput. OpenWrt may show a 100 Mbps link where you expected gigabit, or the modem may not be passing traffic cleanly in bridge mode. That produces a result that looks like an internet problem but is really a local handoff issue.
Check the reported WAN link speed, replace suspicious cables, and compare the router directly against the modem or optical terminal when possible. If the result changes sharply after a cable swap, you have found the cause.
Cause 4: SQM, VPN, and security features reduce peak speed by design
Some settings are supposed to lower the headline number. SQM can reduce maximum throughput so queues stay short and latency stays stable under load. A VPN adds encryption overhead, and security packages can inspect traffic before forwarding it. These features are useful, but they make raw speed tests look worse than a plain routed path.
If you value responsiveness for gaming, calls, or work traffic, a slightly lower speed test is not automatically a problem. The key is whether latency stays controlled when the network is busy.
Cause 5: The test method itself is misleading
Different test servers, browser engines, and times of day produce different numbers. Background downloads, cloud backups, or another device on the network can also distort the result. Even the same router can show different speeds if you test at peak congestion versus a quiet hour.
Run several tests against the same server, keep other traffic idle, and compare repeated runs rather than a single result. A stable pattern is more useful than one impressive peak.
How to diagnose the bottleneck step by step
Start with a wired test. That isolates Wi-Fi. Next, watch router CPU usage while the test runs. If CPU is near its limit, reduce the load by disabling optional services one at a time. Then verify WAN link speed and cable quality. If the router still looks slow, test the modem or optical terminal path directly.
What to record
- Wired and wireless results
- Download, upload, and latency separately
- WAN link speed shown by OpenWrt
- Which features were enabled during the test
- Whether the same server produced consistent results
Practical ways to improve speed without guessing
- Update OpenWrt and router firmware to get current driver and stability fixes.
- Use wired backhaul for benchmarking and reserve Wi-Fi for actual client mobility.
- Choose a cleaner Wi-Fi channel and a channel width that matches your environment.
- Disable unneeded services during speed testing, then add them back only if they are useful.
- Check MTU, PPPoE settings, and hardware offloading support if your connection uses them.
- Upgrade router hardware if your ISP speed is now higher than the device can process reliably.
The right goal is not the highest possible number in one test. It is a router that delivers stable throughput, reasonable latency, and predictable behavior under load.