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 head-of-line blocking at the transport layer. In HTTP/2 over TCP, one lost packet stalls every multiplexed stream. QUIC eliminates this; a lost packet only affects its own stream. This is the headline performance win, especially on lossy mobile networks.
- 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 subtle but critical detail: a browser does not start a connection in HTTP/3. It starts over HTTP/2 (TCP), and the server advertises HTTP/3 availability via the Alt-Svc response header:
Alt-Svc: h3=":443"; ma=86400
This says "I also speak HTTP/3 on UDP 443; remember that for the next 86,400 seconds." The browser caches this and upgrades to HTTP/3 on the next request. There is also Alt-Svc advertised via HTTP/2, and newer setups can use HTTPS DNS records (the HTTPS/SVCB record) to learn about h3 before the first connection.
Monitoring implications:
- The very first visit is almost never HTTP/3 — it's the upgrade that matters.
- 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 data in the very first packet, before the handshake completes, shaving a round trip. The catch: 0-RTT data is replayable by an attacker. It must only be used for idempotent requests (GETs), never for state-changing operations. A misconfiguration that allows 0-RTT on POSTs is a real security issue worth monitoring for.
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
curl --http3 -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: HTTP/3 negotiates over UDP and Alt-Svc is advertised over TCP for discovery.
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 | At TCP layer (one loss stalls all streams) | Eliminated at transport |
| 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 | Alt-Svc header / HTTPS DNS record |
| 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 checks your site from outside, across regions and networks — the only vantage point that can tell you whether HTTP/3 actually works for real users:
- Protocol-aware HTTP checks that confirm what your endpoints negotiate, not just that they respond.
- Header validation so a missing or malformed
Alt-Svcis caught the moment it regresses. - Multi-region monitoring to surface the geographic/ISP differences that define QUIC reachability.
- TLS monitoring for the TLS 1.3 layer now embedded in QUIC — see TLS configuration & certificate chain monitoring.
- Response-time tracking to verify the HTTP/3 speed-up is materializing, alongside TTFB monitoring and ping/latency checks.
- Content validation and uptime alerting so a fallback never silently degrades into a real outage.
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 the Alt-Svc header and adoption/fallback rates, test from multiple regions and network types, and confirm graceful fallback. Do that, and HTTP/3 becomes a measured, reliable performance win instead of a feature you hope is working.