QUIC on Paper, TCP in Practice: Auditing the Gap Between Alt-Svc and Real HTTP/3 Delivery

An Alt-Svc header is a routing suggestion, not proof of capability. When an edge advertises HTTP/3 over QUIC, it is telling the browser that a faster path exists on UDP port 443. Most URL monitors never take that path. They open a TCP connection, complete a TLS handshake, read the status line, and move on. That is a valid check for the HTTPS surface, but it is not an audit of the transport the header promised. Before a traffic peak, the gap matters: a broken HTTP/3 path usually degrades performance rather than producing a red status.

Why a Green Check Can Hide a Broken QUIC Path

A monitor that speaks only TCP is measuring half the handshake. If the edge advertises HTTP/3 but has no UDP listener, or if a security group allows TCP 443 and silently drops UDP 443, the browser falls back to HTTP/2 over TCP. The page still loads. The certificate still validates. The status code is still 200. For a visitor on a friendly network, the fallback may be invisible. For a visitor on a US carrier network, a hotel Wi-Fi network, or an enterprise VPN that blocks UDP, the fallback is the only path they ever had.

The result is a false sense of health. Your uptime report says the URL is available. Your performance dashboard may even show normal median load times because most samples come from networks that permit QUIC. The regression hides in the tail: higher time to first byte for affected users, more connection setup work, and a protocol mix that quietly shifts away from the transport you thought you deployed.

Read the Header Before You Trust It

Start with the response headers, but read them as a contract with conditions. Fetch the URL over HTTP/1.1 or HTTP/2 and inspect Alt-Svc:

Alt-Svc: h3=":443"; ma=86400

The protocol identifier, port, and ma lifetime all matter. A stale draft token is not useful to modern browsers. A short ma means clients will re-check the advertisement soon; a long ma means a mistaken advertisement can persist after you change the edge. Look for clear when a route is being retired. Also check whether the header appears on redirects, HTML responses, and cacheable assets, not just on the home page. If the header says HTTP/3 but the edge has no UDP path, you have published a promise without a route.

Test UDP, Not Just HTTPS

A real audit exercises the advertised transport from outside your own network. Use an HTTP/3-enabled client and force the protocol:

curl --http3-only -I https://example.com/

Then repeat the request from multiple US vantage points: a cloud instance in us-east-1, another in us-west-2, a residential ISP, and a mobile network. The goal is not to prove that one laptop can reach QUIC. The goal is to find where UDP 443 is filtered, where the load balancer lacks a QUIC listener, or where the CDN configuration advertises HTTP/3 only for some hostnames.

Check the infrastructure layer as well. Security groups, network ACLs, and on-premises firewalls must permit inbound UDP 443, not just TCP 443. If the edge terminates QUIC, confirm that the certificate and TLS 1.3 settings match the TCP path. If the CDN generates Alt-Svc, confirm that the setting is enabled consistently across the properties and hostnames you monitor. A single successful request from a friendly network is not an audit; it is a spot check.

Measure Fallback, Not Just Failure

HTTP/3 problems rarely look like outages. They look like a protocol mix that drifts, a regional TTFB regression, or a growing share of sessions that never negotiate QUIC. Instrument the difference. Real user monitoring can expose the negotiated protocol through Resource Timing where supported. CDN logs and edge analytics can show HTTP/3 request share by region. Origin logs may show the protocol the edge used to the origin, which is a different question.

Compare p75 TTFB for HTTP/3 and HTTP/2 sessions in the same region. If the HTTP/3 share collapses while status checks remain green, you have found a fallback event. Alert on the share of HTTP/3 sessions, not only on 5xx rates. Fallback is a feature; silent fallback is a hidden tax.

Audit the CDN and Origin Boundary

Alt-Svc is usually generated at the edge, so the origin does not need to speak QUIC. That separation is useful, but it creates its own failure modes. A hostname may move between CDN configurations while clients still hold a cached advertisement. A property may advertise HTTP/3 globally while one US point of presence lacks the UDP path. A decommissioned edge may leave clients trying an alternative authority that no longer serves traffic.

Treat Alt-Svc like a DNS TTL: it is a lease on a route. When you change edge providers, disable HTTP/3 on a property, or shift traffic between hostnames, publish Alt-Svc: clear and verify that clients stop attempting the old path. Then re-run the UDP and HTTP/3-only checks from your US vantage points.

A Pre-Peak Checklist

Before the next traffic peak, verify six things:

1. The Alt-Svc header uses current protocol tokens, the correct port, and a deliberate ma lifetime.
2. UDP 443 is reachable from external US vantage points, including at least one consumer ISP and one cloud region.
3. An HTTP/3-only request succeeds against every monitored hostname.
4. When UDP is blocked, the fallback to HTTP/2 completes cleanly and within an acceptable latency budget.
5. RUM or edge logs report the HTTP/3 share by region, with alerts on sudden declines.
6. Retired routes publish clear, and stale advertisements are allowed to expire.

The status code tells you that the page answered. Alt-Svc tells you which transport the browser was invited to try. Audit both, or your green check may be measuring the fallback rather than the path you intended to ship.