How it works
HTTP/3 (RFC 9114) carries the same requests and responses as HTTP/2 but swaps TCP for QUIC (RFC 9000) as its transport. QUIC runs over UDP, usually on port 443, and has TLS 1.3 built in, so the transport and encryption handshakes happen together. A browser that has talked to the server before can even send data in its very first packet.
With QUIC, a lost packet only stalls the stream it belongs to, not every file loading in parallel as it would over TCP. You notice the difference mostly on cellular networks and spotty Wi-Fi. A QUIC connection can also survive a network switch, say from Wi-Fi to mobile data.
Browsers always start with HTTP/1.1 or HTTP/2 and learn from the Alt-Svc response header (for example Alt-Svc: h3=":443"; ma=86400) that the server also speaks HTTP/3. From then on they try QUIC for that origin. An HTTPS record in DNS (RFC 9460) can advertise HTTP/3 as well.
Why it matters
Not offering HTTP/3 is not a security issue; the site simply stays on HTTP/2. Trouble starts when a server advertises HTTP/3 but does not answer over QUIC. After a server move, a firewall change or a new load balancer, UDP 443 is often closed while the Alt-Svc header keeps going out.
Browsers then attempt QUIC, wait, and only fall back to HTTP/2 after a delay. The site feels randomly sluggish even though every regular uptime check is green, which makes this a problem clients notice and hardly anyone tracks down.
How to prevent it
- Ask the host or CDN whether HTTP/3 is available and turn it on there instead of building it into your own web server; many CDNs and managed hosts offer it as a toggle.
- Allow UDP port 443 in every firewall and security group in front of the web server. TCP 443 alone is not enough for HTTP/3.
- Only send the Alt-Svc header when the server really listens on QUIC, and drop it during a migration until HTTP/3 works on the new system.
- Check whether a proxy or load balancer in front of the server passes UDP through at all; many older setups only forward TCP.
- Test over QUIC specifically after every change, for example with curl --http3-only -I https://example.com/ from a machine outside your own network.
How DomainWarn detects it
The HTTP/3 check fetches every monitored website normally and reads the Alt-Svc header of the final response. If it advertises h3, a second request goes out over HTTP/3 only, on the advertised UDP port. No answer there is a warning, and after two runs in a row DomainWarn opens the incident “HTTP/3 advertised but unreachable”. A site without h3 only gets an informational note.
Before reporting anything, DomainWarn verifies its own QUIC path against reference targets, so a broken probe location never turns into a false alarm. The monitor runs hourly, starts switched off and turns itself on once the Website monitor sees HTTP/3 advertised. The Website monitor also records the negotiated HTTP version and flags sites that do not even offer HTTP/2.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.