Why turning on UniFi Threat Management slows your internet

Every UniFi cloud gateway at techspecs.ui.com lists a line called IDS/IPS Throughput. That is the number Ubiquiti will quote you if you ask support. It is the published ceiling above which DPI cannot run. The list below is current at the date of this article; the spec pages get edited from time to time, but the trend has been one direction only — newer hardware is faster.

Two things to read off that table. First: every gateway up to and including the UDM-SE has an IDS/IPS ceiling belowwhat a US residential fiber line typically delivers today (Verizon Fios 2 Gig, Optimum 5 Gig, Frontier 5 Gig, AT&T Fiber 5 Gig). The UDM-Pro's 3.5 Gbps ceiling is a hard cap on a 5 Gbps plan whether the WAN port is SFP+ or not. Second: the published number is the ceiling, not the floor. Whether you hit it depends on traffic mix, signature set, CPU contention from other features (Smart Queues, traffic identification, content filtering), and how busy the gateway is doing everything else. The number is what the silicon can do under good conditions, not what you will see on a Tuesday-night Zoom call with three 4K streams running.

A standard layer-3 forwarding decision — “does this destination IP match a route in my table, and if so which interface do I send it out of?” — is cheap. Most modern home routers offload it to dedicated forwarding silicon and can hit line rate on a 1 Gbps or 2.5 Gbps WAN port without breaking a sweat. Stateful NAT is a little more expensive, but still trivial in hardware-accelerated forms.

Deep packet inspection is a fundamentally different workload. For every packet, the engine has to:

• Reassemble it into the application-layer flow it belongs to (TCP segments, IP fragments, the TLS client-hello if visible, the DNS query, the HTTP request line).
• Run the reassembled payload past every signature in the loaded rule set — tens of thousands of regular expressions, byte patterns, and protocol-specific match conditions.
• Maintain per-flow state across packets, since a lot of signatures only fire on sequence (an HTTP request with one header followed by a body matching another pattern).
• Decide, before the packet is allowed to forward, whether to drop, reset, or alert.

Suricata can be very fast at this — multi-gigabit throughput is routine on a dedicated x86 server with multi-queue NICs and many cores pinned to packet threads. On the ARM SoC inside a UDM-Pro, with the same chip also handling routing, switching, the controller process, the Protect process if installed, and whatever else the gateway is doing, the math is different. Ethan Word's 2025 field tests on a UDM-Pro reported “CPU usage was completely maxed out across all 4 cores” even while throughput sat well below the line rate of the WAN.⁹

That's the engineering shape of the problem. It's not that Ubiquiti shipped a slow IDS engine — Suricata is a competent piece of software. It's that running it on a residential gateway, where the same CPU has many other jobs, leaves a very small budget for line-rate signature matching. The hardware ceiling is the cost of running a tool designed for dedicated security appliances on a box that also has to be a router, switch, controller, and (optionally) NVR.

Ubiquiti's published IDS/IPS throughput figure is a synthetic-traffic number generated under controlled conditions. The actual factors that move it around in a real home:

• Signature set selected. UniFi exposes categories (Malware, Exploit, Scan, Reputation, etc.). More categories loaded means more rules in memory but, somewhat counter-intuitively, not always meaningfully slower steady-state throughput once the rule cache is hot.⁹ The hit is mostly at the category-toggle boundary — the first three or four categories cost the most, and additional ones are nearly free in throughput terms.
• Traffic mix. A single bulk-TCP download is the easiest case for DPI — long-lived flow, predictable packet sizes. A house full of video chat, screen sharing, gaming, and many short-lived TLS connections is much harder, and CPU climbs faster.
• Concurrent gateway load.Smart Queues (SQM/cake), application identification, honeypot, country blocking, content filtering, the embedded UniFi controller process — all of these share the CPU with Suricata. Ubiquiti's own Optimizing Wired Network Speedsguidance flags this directly: “resource- intensive features such as Threat Management and Smart Queues may reduce throughput by up to 30 percent.”¹³ That figure is from Ubiquiti, not us, and is the closest thing to an official acknowledgement we could find.
• Single-flow vs. aggregate. The spec number is aggregate across all flows. A single iperf-style test from one client may not hit it even when the gateway is otherwise idle, because of how Suricata distributes flows across worker threads.

The pragmatic read: treat the published number as a not-to-exceedceiling. The realistic expectation on a residential gateway is somewhere between 60 and 90 percent of the published figure on a good day, and meaningfully lower when the gateway is also doing Smart Queues or application identification at the same time.

The diagnostic is simple: run a wired speedtest with Threat Management on, disable Threat Management, wait a minute for the gateway's rule processes to wind down, run the same speedtest. Three patterns are possible.

1. Speed jumps to (or near) the WAN line rate.

Diagnostic confirmed. The gateway's IDS/IPS throughput ceiling was the cap. On a UDM or UDM-Pro on gigabit fiber, this is the most common reading we see — speedtest jumps from ~300 Mbps to ~940 Mbps after disabling Threat Management. Re-enabling brings the cap right back.

2. Speed barely changes.

The bottleneck is somewhere else. Common other culprits at this point: a 100 Mbps-negotiated Ethernet link (cable, port, NIC), an ISP-side provisioning issue, a Smart Queue limiter you forgot you turned on, or — for wireless tests — the airtime / TX-power issues covered in our too many APs at too high power writeup.

3. Speed jumps part of the way.

Both are contributing. Threat Management is one ceiling, and there is another ceiling you'll surface only when you fix this one. Disable Threat Management, document the new floor, and continue the audit from there.

A wired test from a laptop plugged directly into the gateway LAN port — not over Wi-Fi, not through a switch hop with PoE budget contention, not from a phone over 2.4 GHz — is the only test that isolates the gateway. Anything else mixes wireless airtime, switch behavior, and gateway load into the same number.

There is no fourth path. We've looked. The community has looked. Trimming the signature set does almost nothing to the ceiling once the engine is warm.⁹Tuning Suricata variables from the UniFi side isn't exposed in the UI. Hardware acceleration of DPI doesn't exist on the current consumer-tier SoCs. The honest options are these:

Option A. Disable Threat Management.

The fastest and cheapest fix. Settings → Security → Threat Management → off. The gateway immediately reclaims the throughput ceiling. The cost is the loss of IDS alerts and the IPS block action on known signatures. On a residential network already running endpoint protection on the machines (most do, even if it's just the OS vendor's built-in), behind a proper firewall with no inbound port-forwards, the marginal security benefit of a Suricata-based home-grade IDS is modest. The marginal performance benefit of turning it off is large.

Option B. Upgrade to a gateway whose IDS/IPS ceiling clears your WAN.

If the homeowner is on a 2 Gbps plan and wants Threat Management, the gateway needs to be at least a UCG-Max (2.3 Gbps), UDR-7 (2.3 Gbps), UDM-Pro (3.5 Gbps), UDM-SE (3.5 Gbps), UCG-Fiber (5 Gbps), or UDM-Pro Max (5 Gbps) depending on rackmount preference. On a 5 Gbps plan, the practical options shrink to UCG-Fiber, UDM-Pro Max, or above. The conversation is honest — the existing gateway is what it is, and the new gateway costs what it costs.

Option C. Accept the cap.

Leave Threat Management on, accept that the WAN will cap at the IDS/IPS ceiling, document that to the homeowner. This is sometimes the right answer when the actual sustained traffic mix in the home (streaming + web + light video chat) doesn't hit the cap anyway. The speedtest number is lower than it could be; the lived experience is fine. What we won't do is leave it on without naming the trade-off.

There is a related configuration trap we want to name even though it is not the same problem as the throughput ceiling. UniFi's Threat Management does not automatically apply to every VLAN. Ubiquiti's help-center article notes directly that enabling IDS/IPS “increases CPU and memory utilization,” and as a result the controller imposes a limit on the number of networks it can be applied to at once.² Practically: when Threat Management is first turned on, the user selects which VLANs it monitors. New VLANs created later — for guest, for IoT, for a kid's gaming network, for any segmentation added after the initial enable — are not automatically added to the monitored list.

On audit, the pattern looks like this: a homeowner with an old UDM-Pro proudly shows that “Threat Management is on,” and on inspection it's only on for the main LAN. The IoT VLAN, the guest Wi-Fi, the camera VLAN are all bypassing IDS entirely. Two opposite mistakes hide in the same place — the network is paying the throughput ceiling cost for the LANs Threat Management isapplied to, while getting none of the security benefit on the LANs it isn't.

Mitigation on audit: when Threat Management is on, check which VLANs it is applied to. If the list hasn't kept up with the network's segmentation, decide deliberately — add the missing VLANs to the monitored list, or accept that those VLANs are out of scope for IDS by design. Either is defensible. The one we want to retire is the accidental version.

The recommendation we make on most residential audits, in order of likelihood:

1. If the gateway is at or below UDM-SE class and the WAN plan is 1 Gbps or faster:turn Threat Management off. The performance ceiling outweighs the marginal security benefit on a home network with no exposed inbound services. The audit report names the decision and the reasoning so it's reversible.
2. If the gateway is UCG-Max / UDR-7 / UDM-Pro Max / UCG-Fiber and the WAN plan is at or below the gateway's IDS/IPS ceiling: Threat Management on, with a deliberate VLAN application list. Re-test wired throughput after enabling; document the new ceiling.
3. If there are exposed inbound services (port forwards for a home server, a public game server, a CCTV NVR with a public hostname, a SIP trunk):have the conversation about whether the exposure is actually necessary first, because almost every one of those services has a modern WireGuard / UniFi Teleport / VPN-based alternative that doesn't need the port forward at all. Where the exposure is genuine and must remain, prefer the gateway upgrade path over running an undersized gateway with Threat Management on.
4. For commercial / multi-tenant / PCI-scoped networks:Threat Management alone is not a substitute for a real layered security posture. UniFi's own CyberSecure documentation makes that point as well — the feature is one layer in a stack, not a SOC in a box.

The throughput-ceiling problem is not a UniFi indictment. It's a consequence of running a line-rate security feature on consumer hardware, and every vendor in this segment has the same trade-off — the spec sheets just spell it out with more or less candor. Ubiquiti's actually do spell it out, on every per-model page; the audit finding is that homeowners don't see those pages until someone shows them.

• The per-model IDS/IPS throughput numbers are firm.Each is read directly from Ubiquiti's own tech-specs page for that gateway. They are footnoted to the source. The exception is the original UDM, whose current tech-specs page lists IPS/IDS as a feature but omits the throughput figure; the 850 Mbps number we use for it is the Ubiquiti-blog launch number widely cited in community write-ups.
• The “reduce by up to 30 percent” figure is from Ubiquiti, not us. It appears on the official Optimizing Wired Network Speeds help- center article and is the closest thing to an official acknowledgement that Threat Management has a real performance cost.¹³ It is not a guarantee. Some homes see less. Some see more.
• Real-world numbers vary widely by signature set and traffic.The single largest public benchmark we found — Ethan Word's August 2025 UDM-Pro tests — showed raw throughput drop from ~8 Gbps without IDS/IPS to ~3.5 Gbps with three categories enabled, with little further drop as categories were added.⁹A homeowner's test on a normal traffic mix may not match those synthetic numbers in either direction.
• This is finding #7 in our residential UniFi audit series.Among multi-gigabit homes that brought us in because “the internet is slow,” the most common single cause we've found that points at the gateway itself rather than the Wi-Fi is Threat Management running on a gateway that can't carry it at line rate. That is a narrow population — the homes where the problem is worth auditing. It is not a claim about every UniFi network or every homeowner.
• This does not apply uniformly to business deployments. Commercial deployments often need the IDS layer for compliance or insurance reasons that outweigh the throughput trade-off, and the gateway tier is usually higher to begin with. The framing in this article is residential. The mechanics are the same on a UDM-Pro in an office; the conclusion may not be.
• We don't publish per-home audit numbers in this article. The audit produces a written report for a specific home, not a public dataset. The pattern described above is what we and the cited community sources observe.

None of these caveats changes the headline: the IDS/IPS throughput ceiling on UniFi gateways is real, it is published on the per-model spec sheets, and Ubiquiti does not display it next to the Threat-Management toggle. That is the gap this article exists to close.