QUIC
The transport behind HTTP/3, built on UDP to fix TCP's delays, and the reason a proxied browser quietly falls back to older protocols.
QUIC is the transport that carries HTTP/3, and it exists to fix problems baked into the older stack. Where the classic web runs HTTP over TCP over a separate TLS handshake, QUIC folds transport and encryption together and runs the result on UDP, so a connection establishes in fewer round trips and, crucially, a single lost packet no longer stalls every other stream waiting behind it. It is a genuine performance improvement, and adoption across large sites has been rapid.
For proxy users the salient fact is not the performance but the incompatibility. Conventional proxies relay TCP; QUIC is UDP, and most proxy protocols have no way to carry it. So when a browser configured to use a proxy meets a site offering HTTP/3, it does not fail, it falls back: the connection quietly drops to HTTP/2 or HTTP/1.1 over TCP, which the proxy can carry and every site still serves. Nothing breaks, and the transport is simply older than it would have been directly.
That fallback is itself worth knowing about, because it is a small behavioural difference between proxied and direct traffic. A client that would normally speak HTTP/3 to a given site but speaks HTTP/2 through your proxy is showing one more way the two paths differ, alongside the TLS fingerprint and the header order. It is rarely decisive on its own, and it is one more entry in the ledger of things that must be consistent to look ordinary.
The direct-connection side has a detection wrinkle too. Because QUIC clients negotiate their own set of parameters much as a TLS ClientHello does, HTTP/3 traffic carries its own fingerprint, so the arrival of QUIC has not removed the identification surface that fingerprinting reads, it has added another layer of it. For proxy work that mostly stays theoretical, since the proxy forces you off QUIC anyway, but it is the reason nobody should assume the newer transport is a fresh start for anonymity.
Frequently asked questions
Do proxies support QUIC and HTTP/3?
Mostly not. QUIC runs on UDP, and conventional proxy protocols relay TCP, so a proxied browser negotiates HTTP/2 or HTTP/1.1 over TCP instead. Every HTTP/3 site also serves those, so pages load normally; the connection just uses the older transport. Carrying QUIC through a proxy requires specific UDP support that is uncommon.
What is the difference between QUIC and HTTP/3?
HTTP/3 is the version of HTTP; QUIC is the transport it runs on. Where earlier HTTP versions ran over TCP with a separate TLS layer, HTTP/3 runs over QUIC, which combines transport and encryption on UDP. In everyday use the names are used almost interchangeably, but strictly HTTP/3 is the application protocol and QUIC is what carries it.
Does using a proxy disable HTTP/3?
In effect, yes, for traffic routed through the proxy. Since the proxy cannot carry QUIC, the browser falls back to a TCP-based HTTP version for those connections. It is not a setting you chose and not a failure; it is the automatic consequence of routing UDP-based transport through TCP-based proxy infrastructure.
Back to the full glossary.