HTTP/3 and QUIC: why your browser already changed protocols and you didn't notice

If you opened Chrome to read this article and you did not configure anything, there is a good chance the page came in over HTTP/3. Cloudflare reports that around 30% of all the requests it sees in 2026 are HTTP/3, and that share has been climbing steadily. Google, Meta, Apple, Microsoft and most of the CDN industry have shipped HTTP/3 as the preferred transport for at least three years. Nobody told users. Nobody had to.

But HTTP/3 is not "HTTP/2 with bug fixes". Underneath the same Request and Response semantics is a completely different transport stack. The change matters for performance, for firewall design, and — if you run a VPN — for how your tunnel interacts with the traffic your users are actually sending.

What HTTP/3 actually is

HTTP/3 (RFC 9114) is HTTP semantics — methods, headers, status codes, the whole familiar surface — running over QUIC instead of TCP. QUIC (RFC 9000) is a new transport protocol that runs over UDP. So the layer cake is: HTTP semantics on top, QUIC in the middle, UDP at the bottom, IP underneath. Compare to HTTP/2: same HTTP semantics on top, HTTP/2 framing, TLS 1.2 or 1.3, then TCP, then IP.

The visible API for web developers did not change. The same JavaScript fetch() call works. The same nginx config works. What changed is everything below the dotted line in the TCP/IP textbook diagram.

What changed mechanically

Four shifts, all of them load-bearing.

• Transport moved from TCP to UDP. The kernel is no longer responsible for ordering and retransmission. QUIC does that itself in user space, which is a significant performance win and an even more significant deployment headache.
• Encryption is mandatory and integrated. There is no unencrypted QUIC. The TLS 1.3 handshake is woven into the QUIC handshake — they finish together in a single round trip, sometimes zero if 0-RTT resumption is in play.
• Streams are first-class at the transport layer. HTTP/2 multiplexed streams over a single TCP connection, but a single dropped TCP segment stalled every stream. QUIC streams are independent: loss on stream A does not block stream B. Real head-of-line blocking is gone.
• Connection IDs replace the IP/port tuple. You can change networks — Wi-Fi to LTE, for example — without losing the connection. Mobile users finally get something they should have had a decade ago.

For a typical page load with twenty parallel asset fetches over a slightly lossy mobile link, this combination produces noticeably faster page renders. Not because any single download is faster, but because the transport stops punishing parallelism.

Where HTTP/3 breaks

Moving the web onto UDP exposed how much corporate infrastructure assumed UDP was for VoIP and DNS and could be ratelimited or dropped without consequence.

Corporate firewalls

A non-trivial fraction of enterprise firewalls block all UDP outbound except DNS and a few VoIP ports. HTTP/3 traffic to UDP/443 is silently dropped. Browsers detect this — they race a TCP HTTP/2 connection against a UDP QUIC connection, and if QUIC times out, they cache the failure and stop trying. So inside many corporate networks, HTTP/3 simply does not happen, and nobody notices because the fallback is invisible.

Middleboxes that strip or mangle UDP

Some carrier-grade NATs and DPI boxes do not understand QUIC packets and either drop them or, worse, mangle them in ways that break the QUIC version negotiation. The IETF designed QUIC version negotiation to survive this, but the long tail of broken middleboxes is real.

UDP rate limiting at the edge

Cloud providers historically gave UDP packets less attention than TCP segments because UDP was rare, bursty, and assumed to be VoIP or game traffic. Some load balancers still apply per-flow UDP rate limits that were perfectly reasonable in 2018 and are now actively hostile to HTTP/3 traffic.

What this does to VPN throughput

This is where it gets interesting for us. A modern VPN tunnel — WireGuard, OpenVPN over UDP, IKEv2 — is itself UDP traffic. Now your users are also generating QUIC, which is UDP traffic, inside that tunnel. You have UDP inside UDP, and the host kernel has to do work for both layers.

We benchmarked this on our own infrastructure. The setup: a residential gigabit fiber connection in Frankfurt, a PlanetProxy exit in Amsterdam (low-latency hop), and two test workloads — a 1 GB file download from a CDN that supports HTTP/3, and the same download forced to HTTP/2 over TCP via curl flags.

• WireGuard tunnel, HTTP/2 over TCP: 711 Mbps sustained, 1.6 ms added RTT.
• WireGuard tunnel, HTTP/3 over QUIC: 768 Mbps sustained, 1.4 ms added RTT.
• OpenVPN UDP tunnel, HTTP/2 over TCP: 412 Mbps sustained.
• OpenVPN UDP tunnel, HTTP/3 over QUIC: 449 Mbps sustained.

HTTP/3 is consistently a few percent faster than HTTP/2 even inside a VPN tunnel, because the transport-layer wins (no head-of-line blocking, fewer round trips on resumption) compound rather than cancel. The often-cited concern that "UDP-in-UDP is bad" turns out to be mostly a myth at gigabit speeds on modern kernels with GRO/GSO offload working correctly.

Where it does fall apart: tunnels that run over TCP. If you are using OpenVPN/TCP because UDP is blocked on your network, you are now stacking QUIC over TCP, which means TCP is doing reliability work for packets that QUIC already retransmits, and you get the worst of both worlds. Avoid TCP-mode VPN if you possibly can.

How to tell what protocol you are actually on

In Chrome DevTools, open the Network tab, right-click a column header, enable "Protocol". You will see h3, h2, or http/1.1 next to each request. Firefox shows the same info under "Transferred" if you expand. On the server side, "ALPN: h3" in your TLS logs is the giveaway.

A practical exercise: load any large site, count how many requests came over h3 versus h2. On Cloudflare-fronted sites in 2026, the answer is usually "almost all of them, after the first connection".

The take

HTTP/3 is the largest protocol transition the web has ever made silently. It made things measurably faster on lossy networks, broke a fraction of corporate firewalls in ways nobody is fixing, and incidentally pushed the entire industry toward UDP-aware infrastructure. If you run a VPN, the right thing to do is pass UDP cleanly, monitor for kernel offload regressions on your exits, and stop being scared of UDP-in-UDP. We tested it. It is fine.