Can Cisco Umbrella Inspect QUIC and HTTP/3? The Encrypted Traffic Your DNS Layer Never Sees

Cisco Umbrella was built around a simple idea: be the DNS resolver, and decide which domains are allowed to resolve. That model has a blind spot that gets wider every quarter, and it is not the one most teams worry about. It is the transport itself. A growing share of everyday web traffic now rides QUIC, the protocol underneath HTTP/3, over UDP port 443. Umbrella's DNS layer never sees inside it, and Umbrella's proxy tier was built for TCP, not UDP. So the actual session quietly slips past inspection.

If you are evaluating where this leaves you, start with the complete guide to replacing Cisco Umbrella, then come back here for the specific QUIC problem. The encrypted-DNS version of this gap is real too, and we covered it in how users bypass Umbrella with encrypted DNS. QUIC is the transport-layer cousin: same outcome, different mechanism.

Short answer: Cisco Umbrella cannot inspect QUIC or HTTP/3 traffic. Its DNS layer only resolves names, and its proxy tier is built for TCP, so as browsers shift to HTTP/3 over UDP 443 a growing slice of user web activity bypasses inspection entirely. dope.security, an agent-based endpoint secure web gateway, enforces on the request at the device, so it does not depend on a network proxy being able to parse QUIC.

What QUIC and HTTP/3 actually changed

For most of the web's history, browsers talked to sites over TCP. HTTP/1.1 and HTTP/2 both ride it. Network security tools learned to live in that world, because a TCP proxy can sit in the middle, terminate the connection, and inspect what flows through. QUIC broke the assumption. It runs over UDP on port 443, bundles the TLS handshake into the transport, and was designed from the start to resist middleboxes peering into the connection. HTTP/3 is just HTTP carried over QUIC.

This is not a fringe protocol. Chrome and Edge negotiate QUIC by default, and a large and rising share of traffic to major destinations, including Google properties, YouTube, and many CDNs, now uses HTTP/3 whenever the client and server both support it. For a typical workforce, that means a meaningful chunk of daily browsing is happening over a transport your DNS filter was never built to inspect.

Why DNS-layer filtering is structurally blind to it

Umbrella's core enforcement is a name lookup. It answers one question before the connection opens: should this domain resolve. Once the answer is yes, Umbrella's job at the DNS layer is done. It does not matter whether the session that follows is HTTP/2 over TCP or HTTP/3 over QUIC, because DNS never sees the session at all. The same limitation that hides URL paths and file uploads, which we detailed in whether DNS filtering is enough, hides the entire QUIC conversation. The domain resolved cleanly. Everything that happened afterward is invisible.

The proxy tier was built for TCP

Cisco's answer to the visibility gap is its Secure Internet Gateway, a cloud proxy that adds URL and TLS inspection. A proxy can inspect what it can terminate, and traditional web proxies terminate TCP. QUIC runs over UDP, and a TCP proxy cannot transparently sit inside a UDP session it was not designed to parse. So the common workaround is blunt: block UDP 443 at the network so the browser cannot establish QUIC and falls back to TCP, where the proxy can finally see it.

That workaround has two problems. First, it only works where you control the network path. A roaming laptop on a home network or a hotel Wi-Fi, sitting behind only the DNS resolver and a roaming client, can establish QUIC to an allowed domain and the proxy is nowhere in the path. Second, even on-network, you are deliberately breaking a faster, more resilient protocol to force traffic onto an older one your tooling can read. You are degrading the user experience to preserve visibility, which is the opposite of what security is supposed to do. We made the broader version of this argument in going beyond DNS filtering to an endpoint SWG.

QUIC inspection: DNS layer versus endpoint SWG

Question	Cisco Umbrella (DNS + SIG proxy)	dope.security (endpoint SWG)
Sees inside HTTP/3 over QUIC	No	Yes, enforces on the request at the device
Depends on a network proxy parsing the transport	Yes	No
Workaround required	Block UDP 443 to force TCP fallback	None, inspection is local
Works off-network without the proxy in path	No	Yes, agent travels with the device
Breaks HTTP/3 performance to inspect	Yes, by design of the workaround	No, traffic still flies direct
File upload and AI prompt visibility	No	Yes, via Dopamine DLP

Why the endpoint is the durable place to enforce

An agent-based endpoint secure web gateway changes where enforcement happens, and that is the whole point. dope.security performs SSL inspection, URL filtering, Cloud Application Control, anti-malware, and Dopamine DLP on the device, at the point where the application is actually making the request. It does not need to intercept a session mid-network, so it does not need to parse QUIC packets on the wire to apply your policy. The transport the browser negotiated, TCP or QUIC, is the browser's business. Enforcement happens locally either way.

That is the same structural reason an endpoint SWG is not bypassed by encrypted DNS, and it is why the comparison between Umbrella's proxy and an on-device model keeps landing the same way. We walked through the proxy-versus-endpoint tradeoff in Cisco Umbrella SIG versus an endpoint SWG. The headline is consistent: a model that depends on owning a chokepoint in the network is always one protocol change away from a new blind spot. A model that enforces on the device is not.

The cost of the blind spot is not theoretical

Think about what rides HTTP/3 today. Large file transfers to cloud storage, video, and a lot of SaaS sit on QUIC-capable infrastructure. If an employee uploads a sensitive file to a personal Google account over HTTP/3, the domain resolved fine at the DNS layer and the session never touched a TCP proxy. Umbrella logs a name lookup to an allowed domain and nothing else. The action that mattered, the data leaving, happened over a transport your control plane could not read. dope.security inspects that upload on the device with Dopamine DLP, which intercepts file uploads and AI prompts and classifies them through zero-retention APIs under US Patent 12,464,023, regardless of whether the browser used HTTP/2 or HTTP/3. For data already sitting in SaaS, CASB Neural covers the at-rest side.

Blocking QUIC is a treadmill, not a fix

Teams that try to preserve visibility by blocking UDP 443 quickly learn it is an ongoing chore, not a one-time setting. You have to block it consistently across every network you control, keep the block in place as new sites and apps adopt HTTP/3, and accept that the moment a device is off your network the block does not apply at all. Meanwhile users get the slower fallback protocol and occasionally broken experiences on services that assume HTTP/3 is available. You are spending effort to make your own users' web experience worse, purely so an inspection point that lives in the wrong place can keep up. That is the same backwards trade we flagged in what Cisco Umbrella cannot see: the control plane is fighting the way the modern web works instead of moving to where the work happens.

There is also a reporting consequence. When QUIC sessions go uninspected, they are also largely unlogged at the application layer, so your analytics undercount real activity. You think you have coverage because the dashboard is quiet, but the quiet is the blind spot, not the absence of risk. An on-device model logs the request regardless of transport, so what you see reflects what actually happened.

Proof from a team that made the move

Greylock Partners left Cisco Umbrella for dope.security in part because DNS-only filtering missed HTTPS traffic and the proxy option still backhauled through Cisco data centers, adding latency for a distributed, device-first team. They went from first proposal to signed contract in 27 days, detailed in the Greylock customer story. QUIC widens the exact gap that pushed them to move: the lookup is allowed, the session is invisible, and the only fix is to enforce somewhere the transport cannot hide the traffic.

Can Cisco Umbrella inspect QUIC or HTTP/3?

Does Cisco Umbrella see HTTP/3 traffic? No. Umbrella's DNS layer only resolves domain names and never sees the session that follows, whether it is HTTP/2 over TCP or HTTP/3 over QUIC.

Can the Cisco SIG proxy inspect QUIC? Not directly. The proxy tier is built to terminate TCP. The standard approach is to block UDP 443 so browsers fall back to TCP, which means breaking HTTP/3 to inspect it, and it only works where the proxy is in the network path.

How does an endpoint SWG inspect QUIC traffic? It does not have to intercept QUIC on the wire. dope.security enforces on the request at the device, so policy applies regardless of the transport the browser negotiated, on or off the network.

Should I just block QUIC? You can, but you are degrading a faster protocol to preserve visibility you could keep without the tradeoff by inspecting on the device.

The bottom line

QUIC is not an edge case. It is the direction the web is moving, and a security model that can only inspect traffic by forcing it onto an older transport is fighting that direction every day. Cisco Umbrella cannot see inside HTTP/3 because its enforcement lives at the DNS lookup and its proxy was built for TCP. Move enforcement to the device and the question disappears, because you are no longer depending on a network chokepoint to read a protocol designed to slip past chokepoints. For the full migration path off DNS-layer filtering, read the complete guide to replacing Cisco Umbrella, see how Fly Direct secure web gateway inspects on the device, and book a 20-minute demo.