HTTP/3 keeps the request and response model intact, so most teams assume nothing about caching changes. Something does change: the transport underneath. Connection reuse, header ordering, and the way clients discover the protocol all shift, and cache keys built on TCP-era assumptions start splitting traffic they used to share.

The Quiet Divergence in Cache Keys

HTTP/3 is the third major version of the Hypertext Transfer Protocol, and unlike its predecessors it runs over QUIC on UDP rather than TCP. The semantics carry over. GET still means GET, and a response still carries cache directives. What does not carry over is the shape of the connection that carries those requests.

Cache keys date from an era when a client opened a TCP connection, sent a request, and the edge could reason about that connection as a stable identity. QUIC gives each connection an identifier that can outlive an address change, and it multiplexes streams independently. Reuse patterns that operators relied on without documenting them now behave differently.

Operators who flip HTTP/3 on at a large CDN report hit-ratio movement that does not match their traffic graphs. The byte counts look stable. The cache does not. Explaining the gap means going down to the transport layer and asking what the edge actually keys on.

What QUIC Actually Changes at the Edge

0-RTT resumption lets a returning client send application data on the first flight, before the handshake completes. At the edge, that collapses the boundary between connection setup and request arrival. Middleware that inspected connection metadata before routing a request now sees the request first, and the metadata arrives alongside it or later.

Connection migration is the second shift. A client can move between networks, say from Wi-Fi to cellular, and keep the same QUIC connection because the connection ID persists. Any edge logic that pinned sessions or cache partitions to a client IP address quietly loses its anchor. Mobile-heavy properties feel this first, because their clients change networks several times in a session and each move can land them on a different PoP with a different warm set.

Stream multiplexing changes header arrival order across concurrent requests. Alt-Svc headers reroute traffic silently: a response over HTTP/1.1 or HTTP/2 can advertise an HTTP/3 endpoint, and the browser switches on subsequent requests without a visible redirect. A portion of your traffic changes transport with no change to the URL.

There is a subtler effect worth naming. QUIC implementations negotiate header compression state per connection, and the exact behavior differs between stacks. Two clients sending byte-identical request headers can produce different wire representations, and middleware that inspects the wire rather than the decoded headers will see divergence that has nothing to do with the user.

Why Cache Keys Drift in Practice

Most default cache keys include scheme and host, and little else. That was sufficient when the transport was uniform. Once HTTP/3 negotiation adds implicit variants, two requests that look identical at the key level can arrive over different transports, from clients with different resumption state, and land on different edge behavior.

Vary headers behave differently across transports in ways that are easy to miss. A Vary on a header that QUIC compresses or reorders may not produce the same partitioning you tested over TCP. The header is present. The matching is not what you assumed.

Edge points of presence also see asymmetric protocol adoption. Some PoPs serve a browser population that has moved to HTTP/3 aggressively. Others serve clients that have not. A global hit-ratio number averages those populations together and hides the split entirely. The same discipline that applies to measuring before committing to a sharded database applies here: measure the dimension you are about to depend on.

Cache invalidation compounds the problem. A purge that targets a URL works the same on both transports, but a purge that targets a keyed variant may miss the HTTP/3 copy if the key schema quietly added a transport component during rollout. Teams discover this when a stale asset keeps serving to one segment of users and not another, and the purge dashboard shows green.

The Debugging Reality in 2026

Packet captures now require QUIC decryption. The handshake is encrypted, and the keys come from the TLS exchange, so a tcpdump on the edge box gives you ciphertext where it used to give you readable headers. Teams that built debugging habits around plaintext HTTP/2 captures have to rebuild them.

Browser devtools hide transport-level variance. The network panel shows a request and a status. It rarely makes the protocol version and the connection reuse decision obvious in the same view, so a front-end engineer cannot easily tell whether a cache miss came from the key or from the transport.

CDN logs rarely expose protocol version as a first-class field. Some providers include it, some bury it in a free-text field, and some omit it. That gap is the core problem: you cannot correlate hit ratio with transport if the transport is not in the log line. Teams split between curl and quiche-based tooling to reproduce what the edge sees.

Expect the reproduction to be imperfect. A local client that negotiates HTTP/3 cleanly against a test endpoint tells you the protocol works. It does not tell you how a real browser population with mixed resumption state and mid-session network changes will partition your cache. The only faithful reproduction is production traffic with the transport dimension recorded.

Rebuilding Cache Key Discipline

Normalize keys at the origin rather than the edge. The origin knows what actually distinguishes one representation from another, and it can emit a canonical key or a normalization header that every edge honors. Pushing that logic to each PoP guarantees drift the moment one provider updates its defaults.

Treat protocol version as an explicit dimension when it changes behavior. If HTTP/3 responses differ in any way that matters, say in early hints or in header casing, then the version belongs in the key. If they do not differ, document that decision so the next engineer does not re-litigate it during an incident.

Audit Vary headers after the rollout, not before. The behavior you need to verify is the behavior under the new transport, and that only exists once real clients are negotiating HTTP/3. A related piece on how SSH certificates and API keys diverge on revocation makes a similar point about assumptions that only fail in production.

Weigh the cost of adding the dimension. Every variant you add to the key multiplies the number of objects the edge must store and the number of misses it must fill on a cold PoP. For most sites the multiplier is small, because protocol version splits traffic into two or three buckets and the buckets are stable. For a site with a large object catalog and thin long-tail traffic, the extra variants can push a PoP below the working-set size it needs to stay warm, and the added misses cost more than the correctness buys.

What to Do This Quarter

Instrument cache hit ratio by protocol version before anything else. Add the transport to your log schema and your dashboards, even if the field is only available from one provider today.

Add Alt-Svc awareness to your key schema and your runbooks. Know which endpoints advertise HTTP/3 and which clients follow the advertisement.

Run a controlled test with HTTP/3 disabled on a single PoP and compare hit ratios against a matched PoP. That gives you a baseline the global number cannot.

Document key normalization in the runbook, including who owns the origin-side logic and how a change propagates to every edge. Review the CDN contract for protocol-specific SLAs, because a hit-ratio commitment that does not name the transport is not a commitment you can enforce.

Finally, put a date on the review. Protocol adoption keeps moving, and a key schema that is correct this quarter can drift again as more of your traffic lands on HTTP/3 and the PoP-level splits shift. A quarterly check against the same dashboards is cheap insurance against the same surprise twice.