HTTP/3 Proxy Blind Spot: Why QUIC Traffic Skips Your Inspection

A 26 October 2026 engineering post from the InterceptSuite team shows why the HTTP/3 proxy blind spot exists: HTTP/3 runs over QUIC on UDP, so TCP-based proxies such as Burp Suite never receive the packets. There is no CVE and nothing to patch. If your firewall, logs or test tooling only understand TCP, though, part of your HTTPS traffic is passing them by.

Is the HTTP/3 proxy blind spot a vulnerability?

No. The InterceptSuite engineering post, which surfaced on r/cybersecurity and is dated 26 October 2026, is a testing tutorial. It comes with no CVE, no vendor patch and no third-party exploit. What it documents is a visibility problem in tools that were designed around TCP.

The post explains how to intercept, read and edit HTTP/3 traffic in an authorized lab. It also explains why tools such as Burp Suite never receive those packets in the first place. That second part is the real news for site operators and security teams.

Browsers, CDNs and HTTP libraries have quietly moved large amounts of traffic onto QUIC over UDP port 443. An intercepting proxy, a TCP-only web filter or a log pipeline keyed on TCP sessions keeps running without a single error, while covering a shrinking share of what actually reaches the site.

Three groups should pay attention:

• Pentesters whose proxy history looks suspiciously thin while the target site loads normally.
• Security teams that enforce policy through an outbound proxy or a TLS inspection appliance.
• Website owners whose CDN or web server advertises HTTP/3 while their firewall rules and log reviews assume HTTP/1.1 and HTTP/2.

A control that cannot see a protocol enforces nothing on it. The fixes are configuration, tooling and verification, and the rest of this article covers each of them.

Why can't a normal HTTP proxy see HTTP/3 over QUIC?

Because the packets never reach it. In the InterceptSuite team’s words: “HTTP/3 does not go through an HTTP proxy, because it runs over QUIC, and QUIC runs over UDP.” A classic intercepting proxy accepts a TCP connection, terminates TLS and parses HTTP. HTTP/3 offers it none of those three hooks.

• HTTP/3 is standardized as RFC 9114 (June 2022).
• QUIC, RFC 9000 (May 2021), carries it inside UDP datagrams, normally on UDP/443.
• TLS 1.3 is built into the QUIC handshake itself (RFC 9001). There is no “open TCP, then negotiate TLS” phase where a proxy could insert itself.

Clients learn that a site speaks HTTP/3 in three ways: the ALPN token h3, the Alt-Svc response header, and DNS HTTPS/SVCB records (RFC 9460). In practice a browser often sends its first request over TCP, reads Alt-Svc, and moves later requests to QUIC.

Testers know the symptom well: the proxy captures the first page load, then goes quiet while the browser keeps working.

Fallback cuts both ways

A site that advertises HTTP/3 will not always get it. If UDP is blocked or the QUIC handshake fails, clients fall back to HTTP/2 or HTTP/1.1 over TCP, so one site can appear under different protocols in the same capture. Blocking UDP/443 therefore changes both performance and the inspection path the traffic takes.

UDP does not mean cleartext

HTTP/3 has no plaintext mode. QUIC’s Initial packets are protected with keys derived from the Destination Connection ID in the client’s first packet, so anyone on the path can compute them (RFC 9001 section 5). A passive observer can therefore still read handshake material such as the server name.

Everything after the handshake is encrypted with TLS 1.3 keys, and QUIC also encrypts transport details that TCP leaves exposed. A passive sensor gets less HTTP metadata from QUIC than it did from TCP. The authors put it bluntly: “A proxy that wants to read HTTP/3 has to be one of the two ends.”

The usual proxy workarounds don’t help. The classic CONNECT method, even over HTTP/3 (RFC 9114 section 4.4), asks the proxy to open a TCP connection to the target and relay bytes over it. Carrying UDP needs CONNECT-UDP (RFC 9298), and the post says most tools and applications do not use it.

What do QPACK and HTTP/3 streams hide from your logs?

They split each exchange across several streams and compress the headers into bytes that mean nothing without connection state. Even after a QUIC-aware proxy terminates the session, it does not get a tidy request line.

QUIC multiplexes streams, and the two lowest bits of each stream ID describe the stream: one bit records which side opened it, the other whether it is bidirectional or unidirectional (RFC 9000 section 2.1):

Low bits	Stream type
00	Client-initiated, bidirectional
01	Server-initiated, bidirectional
10	Client-initiated, unidirectional
11	Server-initiated, unidirectional

In HTTP/3, each client-initiated bidirectional stream (IDs 0, 4, 8 and so on) carries exactly one request and its response. The unidirectional streams handle housekeeping: one control stream, a QPACK encoder stream and a QPACK decoder stream. The first byte identifies each: 0x00 for control, 0x02 for the encoder, 0x03 for the decoder (RFC 9114 section 6.2, RFC 9204 section 4.2).

The post shows how that looks on the wire. A single lab request produced ten separate proxy history rows:

• 1-byte stream-type markers
• server and client control streams of 12 and 15 bytes
• a 3-byte QPACK instruction setting the dynamic table capacity to 4096
• a 144-byte request and a 171-byte response, each starting with a HEADERS frame followed by DATA

The client’s control stream is three bytes longer because it carries a MAX_PUSH_ID frame. The lab server’s SETTINGS frame advertised a QPACK table capacity of 4096, a limit of 16 blocked streams, and enabled Extended CONNECT.

QPACK (RFC 9204) replaced HTTP/2’s HPACK. It was redesigned so that header compression would not bring back head-of-line blocking when QUIC streams arrive out of order. Its dynamic table lets an endpoint send a header once and then refer to it by index.

The table is off by default: both QPACK settings default to zero under RFC 9204 section 5, and each endpoint has to opt in through SETTINGS. That opt-in is why the client you test with changes what you see:

• curl 8.23.0 advertised QPACK_MAX_TABLE_CAPACITY of 0. With no dynamic table, every header arrives as a literal, so curl traffic is easy to read and easy to edit.
• Microsoft Edge advertised a 64 KB (65,536-byte) table and up to 100 blocked streams. After the first request, its headers can arrive as references into a table built earlier on the same connection.

The blocked-streams value is a decoding limit: how many streams may wait for table updates. It has nothing to do with security blocking. A HEADERS chunk captured from browser traffic may not decode on its own, because its meaning depends on encoder-stream instructions sent earlier.

A proxy that edits headers has to keep that state consistent in both directions, or it breaks the connection.

Bodies behave differently. QPACK does not compress them, so in the raw view the lab’s URL-encoded login form was readable as plaintext while the headers beside it were opaque bytes. Anyone writing detection logic against raw QUIC captures should expect readable bodies and unreadable headers.

What did the InterceptSuite lab actually prove?

That an authorized, QUIC-aware proxy acting as one endpoint can read and modify live HTTP/3 requests without the client noticing. It also showed that getting the traffic into the proxy is the hard part.

The first obstacle was mundane. The curl that ships with Windows, version 8.21.0, does not list HTTP3 in its feature output. A second build installed through winget reported 8.23.0 with HTTP3, ngtcp2 and nghttp3. Neither the filename nor the version number tells you which transports were compiled in; only the feature list does.

The proxy CA was in the Windows trust store, and no proxy option was set in curl. An HTTP/3-only request to Cloudflare’s public QUIC test host returned HTTP/3 200, and the proxy logged protocol QUIC, the host and ALPN h3.

The proxy then rewrote the User-Agent in flight from curl/8.23.0 to edited-by-proxy. The echo endpoint reported the edited value, and curl had no way to tell.

Notice the phrase “no proxy option set.” SOCKS5 can relay UDP through its UDP ASSOCIATE command (RFC 1928). The UDP relay lasts only as long as the TCP control connection that created it.

Chromium does not use it. The post quotes Chromium’s documentation: SOCKSv5 in Chrome proxies only TCP-based requests. Pointing a browser at a SOCKS5 proxy therefore never exercises its QUIC path. The authors name two routes that do work:

• an application or library that speaks SOCKS5 UDP itself, or
• redirecting the application’s UDP traffic from outside the process, which InterceptSuite’s Redirect tab does via ProxyBridge.

One transport caveat applies to anyone building redirection or forensic capture. QUIC identifies connections by connection IDs, not only by IP address and port, so sessions survive NAT rebinding and migration. A capture keyed to one UDP five-tuple can lose a session when the client’s address changes.

Browsers add two more obstacles:

• Encrypted Client Hello hides the real site name. The proxy sees only the CDN’s public name and issues a certificate for the wrong host. ECH is not specific to HTTP/3; it weakens any TLS inspection that depends on a visible SNI value.
• Chromium will not run QUIC on a certificate that chains to a user-installed root, even when the operating system trusts that root.

The post gets around both by launching a throwaway Edge profile with command-line flags that disable ECH and DNS HTTPS record lookups, force QUIC, and pin trust to the proxy CA’s SPKI hash. Edge shows an unsupported-flag warning and ignores the flags unless every Edge window is closed first.

We are not reproducing the flag set here. It belongs in a lab, and if you use it, tear it down afterward: remove the pin and the test CA, then restore normal ECH and DNS behavior.

InterceptSuite describes itself as a raw-traffic tool. Its core handles TCP, TLS, UDP, DTLS and QUIC and shows bytes without an HTTP parser. HTTP/3 decoding comes from an open-source extension. Field filters such as connection_id and size help with the ten-rows-per-request noise.

What should you check on your own site and security stack?

Find out whether HTTP/3 is on, where it terminates, and whether your firewall and logs sit on that path. On WordPress and Joomla sites, HTTP/3 is almost always enabled at the CDN, load balancer or web server, not in the CMS. Look at the edge configuration before you go looking for a plugin.

1. Confirm what your client supports. Run curl -V and look for HTTP3 in the feature list. If it is missing, your HTTP/3 tests prove nothing.
2. Check what your site negotiates. Make a normal request and an HTTP/3-only request to your own domain, and print the protocol with curl’s -w '%{http_version}' option. The --http3-only flag stops a silent TCP fallback from muddying the result. Also check responses for an Alt-Svc header advertising h3, and check your DNS for HTTPS records.
3. Ask where QUIC terminates. Ask your host or CDN whether the WAF terminates QUIC and inspects HTTP/3, or only inspects HTTP/1.1 and HTTP/2 over TCP. If the CDN terminates QUIC and forwards to your origin over TCP, origin-side tools still see the requests, but only the CDN saw the original session. Ask for the answer in writing.
4. Make the protocol visible in logs. Add the negotiated protocol or ALPN field to your access log format. Nginx and Apache can both log the request protocol. If h3 requests are not labeled, you cannot tell a coverage gap from a quiet day.
5. Don’t read an empty proxy history as an idle client. A first TCP request followed by silence usually means the client moved to QUIC. Check UDP/443 separately, and remember that a packet capture alone will not decrypt post-handshake HTTP/3.
6. Decide on UDP/443 deliberately. Blocking it forces TCP fallback and puts traffic back in front of TCP-only inspection, at some performance cost. Leaving it open means your controls must understand QUIC. Either choice is defensible. Not knowing which one you run is the problem.

A practitioner’s note

In web application testing, a proxy history that stops after the first page load is one of the most common false trails. It leads testers to conclude an app makes no further API calls, when the browser has simply switched transports. We now confirm the negotiated protocol before drawing any conclusion about attack surface.

The defensive version of the same mistake is an access log with no protocol field, plus WAF rules only ever tested over HTTP/2. For forensics, keep the whole QUIC connection from its first packet, including the control and QPACK streams. A HEADERS chunk captured mid-session often cannot be decoded without the dynamic-table updates that came before it.

If any step leaves you unsure what your current plan covers, our security FAQ answers the common questions about monitoring, firewall scope and cleanup.

Does a QUIC visibility gap mean your website is hacked?

No. The InterceptSuite post describes no campaign, no payload and no compromise, and nothing in it suggests HTTP/3 sites are being attacked through QUIC itself.

What the gap affects is what you can see. Hostile traffic that arrives over HTTP/3, such as login brute-forcing, plugin probing or form spam, is hidden from a TCP-only log in the same way normal visitors are. An attacker needs no QUIC exploit for that. Your monitoring only has to be looking at the wrong transport.

Our breakdown of how attackers find and target vulnerable websites covers the reconnaissance patterns you want your logs to catch, whatever the protocol.

If a site is already infected, the transport makes no difference to cleanup. Backdoored files, injected database content and rogue admin accounts look the same whether they arrived over HTTP/1.1 or HTTP/3. File integrity monitoring and server-side malware scanning look at what is on disk, not at the wire, so they keep working when the edge loses sight of the traffic.

The sensible order of work: clean up anything already wrong, then make sure the firewall and logs cover both the TCP and QUIC paths.

What is still unknown?

Several questions remain open, and the post does not try to answer them.

• Vendor coverage. The post does not survey commercial WAFs, secure web gateways or TLS inspection appliances, so it does not show which ones fully terminate and inspect QUIC. Only your vendor can answer that for your deployment.
• Browser policy. Chromium’s refusal to run QUIC on user-installed roots is a deliberate design choice. The post gives no sign that it will change.
• ECH adoption. As more CDNs and browsers enable Encrypted Client Hello, inspection that relies on SNI will see less, over TCP and QUIC alike.
• Scope of testing. The demonstration covers curl and Microsoft Edge on Windows against a public test host and a local lab server. Other clients may advertise different QPACK settings and behave differently.

None of this calls for a patch cycle. It calls for an hour of checking what your edge negotiates and what your controls can see.

FAQ

Can a normal HTTP proxy see HTTP/3 traffic?

No. HTTP/3 runs over QUIC, which uses UDP, and a conventional intercepting proxy only accepts TCP. To read HTTP/3, a proxy must receive the UDP traffic and act as a QUIC endpoint itself.

Why does HTTP/3 bypass Burp Suite?

Burp-style proxies terminate TCP and TLS, but QUIC combines transport and TLS 1.3 encryption on top of UDP. Browsers also typically switch to QUIC after the first TCP request, so the proxy sees only the start of a session.

What is QPACK in HTTP/3?

QPACK, defined in RFC 9204, is HTTP/3's header compression scheme. With its dynamic table enabled, later headers become references to earlier entries, so a captured header block may be unreadable without the connection's full history.

Does a website firewall inspect QUIC?

It depends on the product and where it sits. Ask your host or CDN whether the WAF terminates QUIC and inspects HTTP/3, or only covers HTTP/1.1 and HTTP/2 over TCP.

What is Encrypted Client Hello?

ECH encrypts the part of the TLS handshake that names the destination site. Observers and proxies see only a CDN's public name, which breaks inspection methods that depend on reading the SNI.

Is the InterceptSuite HTTP/3 write-up a vulnerability?

No. It is a testing tutorial with no CVE, no exploit and nothing to patch. Its security relevance is the visibility gap it exposes in TCP-only tools and logs.

Not sure whether your firewall sees the HTTP/3 traffic your CDN is serving? SiteGuarding can review your edge setup and put firewall protection and monitoring in front of your site.