Notes on running QUIC at the edge in 2026
Six months in production with HTTP/3 turned on across our small CDN footprint. Latency wins are real but smaller than the marketing slides suggest, and the middlebox compatibility story is still messy in some regions. Here's what we found.
The latency picture
For users on mobile networks with frequent connection migrations (transit, spotty Wi-Fi), QUIC's connection migration support cut median request latency by 8–12% in our measurements. That's solid but not transformative. On stable wired connections the improvement was within noise.
The bigger win for us was actually 0-RTT for returning visitors — first byte time dropped by ~40ms for a meaningful chunk of repeat traffic.
What broke
Roughly 3% of our regional traffic refused to upgrade to HTTP/3. The pattern was clear: corporate networks and certain mobile carriers with deep packet inspection middleboxes that don't understand UDP-on-443. The fallback to HTTP/2 over TCP worked, but it added ~200ms to the first request.
Cloudflare and Fastly handle this better than we did. If you're rolling your own edge, plan for a careful capability negotiation rather than blindly trying QUIC first.
Operational notes
One unexpected bill increase: QUIC's connection ID rotation defeats some naive log-aggregation tools that assumed source IP was a stable identifier. We swapped to a request-id correlation scheme that should have been in place anyway.
Debugging is harder. tcpdump habits don't transfer cleanly. quiclog output is verbose and tooling around it is still immature.
Would we do it again?
Yes, but we'd wait three more months before turning it on for any region with significant corporate-network traffic. The carrier compatibility issues are slowly resolving as middleboxes get firmware updates, but it's not done.