Your CDN turned on HTTP/3. Pages feel snappier on mobile, the marketing slide says "up to 30% faster," and everyone moves on. Then a corporate firewall silently blocks UDP 443, a chunk of your users quietly fall back to HTTP/2, and your monitoring — which only ever checked TCP — sees absolutely nothing wrong.
HTTP/3 is not just "HTTP/2 but faster." It runs on a completely different transport (QUIC over UDP), which means a new set of failure modes, new metrics, and new blind spots for monitoring tools built for the TCP era. This guide explains what actually changes and exactly what you need to watch.
The One Thing That Changes Everything: UDP
HTTP/1.1 and HTTP/2 run over TCP. HTTP/3 runs over QUIC, which runs over UDP.
That single fact cascades into everything else:
- TLS is built into QUIC. There is no separate TLS-over-TCP handshake — the crypto handshake is part of the QUIC handshake (TLS 1.3 baked in). Your old "connect TCP, then negotiate TLS" mental model no longer maps to what's happening.
- Port 443/UDP must be open end to end. Many corporate firewalls, some mobile carriers, and older middleboxes allow 443/TCP but block or rate-limit 443/UDP. When that happens, the client falls back to HTTP/2 — silently.
- No cross-stream head-of-line blocking at the transport layer. In HTTP/2 over TCP, one lost TCP segment can delay all multiplexed streams. QUIC gives streams independent delivery, so loss stalls data needed by affected streams without blocking unrelated stream data.
- Connections survive network changes. QUIC identifies connections by a Connection ID, not the IP/port 4-tuple, so a phone switching from Wi-Fi to cellular keeps its connection alive ("connection migration") instead of renegotiating.
If your monitoring only opens TCP connections, it is — by definition — not testing HTTP/3 at all.
How Clients Actually Discover HTTP/3
A client can discover HTTP/3 from a cached Alt-Svc advertisement received over HTTP/1.1 or HTTP/2, or from an HTTPS DNS record. On a first visit without either signal, it normally establishes HTTP over TCP before learning the alternative:
Alt-Svc: h3=":443"; ma=86400
This says "I also speak HTTP/3 on UDP 443; remember that for the next 86,400 seconds." A client may race or use that alternative on a later connection. HTTPS DNS records can advertise HTTP/3 before the first HTTP response, so Alt-Svc is important but no longer the only discovery path.
Monitoring implications:
- A first visit can use HTTP/3 when HTTPS DNS records, cached state, or another discovery mechanism provides the endpoint.
- If your
Alt-Svcheader disappears after a deploy or config change, clients stop upgrading and silently serve everything over HTTP/2. Nothing "breaks," but you have lost the feature you're paying for. - Monitor the presence and correctness of the
Alt-Svcheader as a first-class check. It is the switch that turns HTTP/3 on for real users.
The New Failure Modes
HTTP/3 introduces failure modes that simply did not exist over TCP. These are the ones that cause real, hard-to-diagnose incidents.
1. UDP blocked → silent fallback
The most common one. A network blocks UDP 443, the client falls back to HTTP/2, and everything works — just without the HTTP/3 benefits, and without any error. The only way to detect this is to explicitly test whether HTTP/3 negotiates, not just whether the page loads.
2. Alt-Svc regression
A CDN setting flips, a config deploys, and the Alt-Svc header stops being sent. HTTP/3 usage quietly drops to zero over the following hours as cached advertisements expire. Catch it by monitoring the header directly (and watching your HTTP/3 traffic share).
3. UDP rate-limiting and amplification defenses
Because UDP is spoofable, networks and anti-DDoS systems often rate-limit it more aggressively than TCP. QUIC has built-in amplification limits (a server won't send more than ~3x what the client sent before address validation). Misconfigured limits can throttle legitimate QUIC traffic while TCP sails through — an asymmetric failure your TCP checks won't see. (For the broader picture, see DDoS detection & traffic-spike monitoring.)
4. 0-RTT and replay risk
QUIC supports 0-RTT resumption: a returning client can send early data before the handshake completes. Early data can be replayed, so servers must only accept operations whose semantics and application controls are safe under replay. HTTP method names alone are not a sufficient policy—some GET endpoints mutate state, while an application may make other operations replay-safe with explicit protections.
5. MTU / fragmentation issues
QUIC tries to avoid IP fragmentation and does path MTU discovery. On networks with small or misconfigured MTUs, large QUIC packets can be dropped, causing stalls or fallback. These are maddening to diagnose because they're network-path-specific.
6. Middlebox ossification
Old middleboxes that "understand" TCP can't inspect QUIC (it's almost entirely encrypted, including most of the transport header). Most pass it through; some drop it. The result is regional or ISP-specific reachability differences — which is exactly why multi-region testing matters.
What To Actually Monitor
Protocol negotiation, explicitly
Don't just check that the site is up — check which protocol won. Use a client that supports HTTP/3 and assert the negotiated protocol:
# curl built with HTTP/3 support; fail instead of falling back
curl --http3-only -sI https://example.com -o /dev/null -w "%{http_version}\n"
# expect: 3
# Confirm the upgrade path is advertised over HTTP/2
curl -sI https://example.com | grep -i alt-svc
# expect: alt-svc: h3=":443"; ma=86400
A complete check verifies that HTTP/3 negotiates over UDP and that every discovery path you rely on—Alt-Svc, HTTPS DNS records, or both—is correct. Test graceful HTTP/2 fallback separately.
Key metrics
- HTTP/3 adoption rate — share of requests served over h3. A sudden drop is your earliest warning of an
Alt-Svcor UDP regression. - QUIC handshake success rate and latency — including the 1-RTT vs 0-RTT split.
- Fallback rate to HTTP/2 — rising fallback = something is blocking UDP somewhere.
- Connection migration events — relevant for mobile-heavy traffic.
- UDP 443 reachability from multiple regions and network types.
- Packet loss and retransmission at the QUIC layer (different from TCP retransmits).
Alt-Svcheader presence on every synthetic check.
Test from where TCP and UDP diverge
The whole point is that UDP and TCP take different fates on real networks. Test from:
- Multiple regions — middlebox behavior is geographic.
- Mobile/cellular vantage points where connection migration and loss recovery matter most.
- Networks that mimic restrictive corporate firewalls, to confirm graceful fallback.
This complements your existing TLS configuration monitoring (remember TLS 1.3 is now inside QUIC) and CDN monitoring, since the CDN is usually where HTTP/3 terminates.
HTTP/2 vs HTTP/3 At A Glance
| Aspect | HTTP/2 | HTTP/3 |
|---|---|---|
| Transport | TCP | QUIC over UDP |
| TLS | Separate handshake (TLS over TCP) | Built in (TLS 1.3 inside QUIC) |
| Head-of-line blocking | TCP loss can stall all streams | No cross-stream transport blocking |
| Connection setup | TCP + TLS round trips | 1-RTT, or 0-RTT on resumption |
| Survives network change | No (tied to IP 4-tuple) | Yes (Connection ID migration) |
| Default port | 443/TCP | 443/UDP |
| Discovery | ALPN during TLS | Cached Alt-Svc, HTTPS DNS record, then ALPN |
| Main monitoring risk | Well-understood | Silent UDP-block fallback, Alt-Svc regressions |
A Pragmatic Rollout & Monitoring Checklist
- Confirm your CDN/origin advertises
Alt-Svc: h3and monitor that header continuously. - Add a synthetic check that asserts the negotiated protocol is HTTP/3 over UDP.
- Track HTTP/3 adoption rate and alert on sudden drops.
- Track HTTP/2 fallback rate and alert on sustained increases.
- Verify graceful fallback works when UDP 443 is blocked (don't let HTTP/3 issues become outages).
- Ensure 0-RTT is restricted to idempotent requests.
- Monitor UDP 443 reachability from multiple regions and network types.
- Keep TLS 1.3 certificate/config monitoring in place — it now lives inside QUIC.
- Watch QUIC handshake success/latency and packet loss separately from TCP metrics.
- Pair protocol checks with response-time percentiles to confirm the promised speed-up is real for your users.
How Webalert Helps
Webalert's published feature and pricing pages do not list HTTP/3/QUIC negotiation assertions, UDP 443 checks, Alt-Svc header validation, or protocol/fallback reporting. Use an HTTP/3-capable client or specialist synthetic service for those protocol controls.
Webalert can provide a protocol-neutral baseline beside it:
- HTTP/HTTPS availability and content checks show whether the endpoint remains usable even when clients fall back.
- US, EU, and APAC monitoring surfaces regional user-visible failures in the published probe footprint.
- Server-certificate monitoring covers expiry and chain health for the HTTPS endpoint; use specialist TLS checks for QUIC-specific policy.
- Response-time tracking and alerts show whether the external request breaches its configured budget, alongside separate TTFB and ping/latency evidence.
Correlate the Webalert baseline with explicit curl --http3-only, Alt-Svc, HTTPS DNS, UDP reachability, adoption, and fallback measurements before declaring HTTP/3 healthy.
Summary
HTTP/3 moves the web onto QUIC and UDP, delivering real gains — no head-of-line blocking, faster handshakes, connection migration — but it also creates failure modes your TCP-era monitoring is blind to. The biggest risks are silent: UDP 443 getting blocked and clients falling back to HTTP/2, and Alt-Svc headers regressing so the upgrade never happens.
Monitor the protocol that actually negotiates, watch each configured discovery path and adoption/fallback rates, test from relevant networks, and confirm graceful fallback. Primary references are RFC 9000 (QUIC), RFC 9001 (TLS for QUIC), RFC 9114 (HTTP/3), and RFC 9460 (SVCB/HTTPS DNS records).