Your router's QoS settings are hurting more than helping, and the fix takes 30 seconds

Published Aug 17, 2026, 2:30 PM EDT Korbin is a Linux system administrator who spends most of his time in a terminal figuring out how things actually work. Over the last decade he's written hundreds of articles about Linux configuration, troubleshooting weird problems, and using open-source tools in the real world. He also works a lot with Windows systems and networking, especially in mixed environments where things don't always behave the way the documentation says they should. Writing things down is how he makes sense of it all and hopefully saves someone else a few hours. Every consumer router comes with a QoS page that's accessible in the admin control panel. At a glance, it seemed like a reasonable thing to turn on, so I did. The page usually looks like a sortable list with various application categories, a gaming mode, and the option to promote one device's priority over another. I arranged that list once and thought that's all I'd need to do. In my list, I had video conferencing at the top and file downloads at the bottom. Running Waveform's bufferbloat test is a good way to measure exactly how well your QoS settings are working. In some cases, they might even be working against you and increasing latency. During the test I ran, my latency went up to 300ms, even though all the priority rules I'd configured were turned on. The difference between prioritization and queue management is that the former determines whose packets go first, and the latter decides how long the line can get. Only one of those settings ended up fixing my setup, and it wasn't the one presented on my router's QoS page. Your router is guessing what your traffic is Encryption made it a lot worse at inspecting traffic Classifying traffic was a lot easier back when everything ran on a predictable port. Once that stopped being the case, vendors began using deep packet inspection. ASUS licenses Trend Micro's DPI engine for Adaptive QoS, which is why it only prompts you to accept a Trend Micro license when you turn it on. Most other vendors rely on some kind of database like that, too. With the advent of TLS 1.3 and QUIC, even that approach stopped working reliably some time ago. Apps using SSL encryption are hard to identify, so they get classified as general traffic. For example, the router sees a Teams call and a Steam download as traffic that both use UDP on port 443, so it won't know which one should have priority. DSCP (Differentiated Services Code Point) marking is supposed to address the issue by giving apps the ability to label their own packets, but routers commonly wipe those identifying bits, anyway. The prioritization only has any effect when the connection is saturated, and there's a good chance that the list I configured months ago isn't accounting for current conditions. The work laptop I promoted might be sitting idle; meanwhile, the phone I demoted is on a call. In that situation, the router is guessing what my traffic is and applying its ranking for the conditions I set a while back. None of that addresses what actually spiked my latency. Packet order wasn't affecting latency spikes It's a queue depth problem, and it needs a shaper Bufferbloat is the latency that builds up when network equipment buffers too much data. When the router can't push packets through a slow link fast enough, it queues them up, and everything new gets in line behind that backlog. That's why a saturated upload can send latency from 15ms to several hundred, all while keeping the throughput consistent. Reordering the packets won't accomplish much if there's still a queue building up inside the ISP's modem. Fixing the problem requires a shaper. On a consumer router, configuring this starts by switching off the per-device and per-application priority rules, then finding a setting that's labeled SQM, Smart Queues, or adaptive bandwidth control (different vendors use various names for it). In that setting, you need to enter your speeds manually. The OPNsense documentation recommends starting with 85% of your ISP's advertised rate. After that, you can inch it higher until latency begins to climb during a bufferbloat test. The number you end up on has to sit just below what your ISP actually delivers, because that's what moves the bottleneck from the modem into your router, where it can manage the queue. For full control, I migrated to OPNsense, because it offers a lot of granular knobs that aren't available in the admin panels of most consumer routers. OPNsense allows me to set a limit on how fast traffic can move, and set a queue to decide which packets get to use that limit first. I set the limits ("pipes" in OPNsense menus) for both the download and upload, then set FlowQueue-CoDel as the scheduler on each, which handles priority between devices, meaning that I don't need to set a priority list manually. This doesn't mean QoS is completely worthless It offers a noticeable improvement in some scenarios When I first flipped on QoS, I really did notice steadier video calls. But on my connection, which has limited upload bandwidth, a single app like a cloud backup can decimate speeds for all other devices on the router. What's really happening by toggling on QoS is that the bottleneck moves from the modem into the router, where the shaper can do its job. The priority list isn't doing much. You can test this yourself by keeping the bandwidth limits, deleting every priority rule, and rerunning the latency test. The numbers should be roughly the same. These days, a lot of networks don't benefit much from tweaking these settings anyway. With a gigabit connection and a modern router and modem, a shaper can have a reverse effect by costing more throughput than the latency it saves. Stop sorting packets and start managing the queue What worked for me was deleting the priority rules, setting a bandwidth number just below what my ISP says my line gets, and picking a flow queuing scheduler. Once that was done, I ran a bufferbloat test to confirm it worked. Now my latency doesn't climb when my network is congested, which is the problem I was trying to resolve with QoS in the first place.