HTTP/3 rides QUIC over UDP with TLS 1.3, Alt-Svc, and QPACK. Use this 2026 cheat sheet for curl, NGINX, Caddy, and HAProxy. Read now.
What HTTP/3 and QUIC Change
HTTP/3 is HTTP over QUIC. QUIC runs on UDP and carries its own transport features—streams, congestion control, and connection migration—while TLS 1.3 is built into the handshake. That design cuts connection setup cost and avoids head-of-line blocking at the transport layer: a lost packet delays only the streams that depend on it, not every stream on the connection. QPACK compresses headers in a way that fits this multi-stream model so a blocked decoder does not stall unrelated requests.
Clients discover HTTP/3 through Alt-Svc (and related negotiation signals). The first contact is often still TCP-based HTTP; the server advertises an HTTP/3 endpoint, and subsequent requests can switch to QUIC when the client supports it and the path allows UDP. Treat that as a dual-stack rollout, not a hard cutover.
Operational Checklist Before You Flip the Switch
UDP must be open end-to-end on the ports you advertise. Middleboxes that drop or rate-limit UDP will force fallbacks and make metrics look like “HTTP/3 is broken” when the path is the problem. Certificate and SNI behavior must match what clients expect on both stacks; TLS 1.3 is mandatory for QUIC, so weak cipher suites and legacy TLS settings simply do not apply. Plan logging and tracing for connection IDs and stream IDs, not only for TCP 4-tuples, or you will lose the plot during incidents.
- Confirm UDP reachability and idle timeouts on load balancers and firewalls.
- Publish Alt-Svc only for endpoints that actually speak HTTP/3 and share the same origin semantics.
- Keep a clean HTTP/1.1 or HTTP/2 path so clients can fall back without hard errors.
- Validate header compression and large header edge cases under QPACK, not only under HPACK.
curl, NGINX, Caddy, and HAProxy
With curl, exercise both stacks explicitly: request the HTTPS origin over HTTP/3 when your build supports it, and compare status lines, timing, and error paths against the TCP baseline. Use that as a quick client-side smoke test after any proxy or origin change. Prefer reproducible flags and a fixed test URL so regressions show up as protocol or path failures, not as vague “slowness.”
On the server and edge side, the pattern is similar across NGINX, Caddy, and HAProxy: enable the QUIC/HTTP/3 listener, terminate TLS for QUIC correctly, and advertise Alt-Svc only when that listener is healthy. Terminate or pass through consistently—mixed modes (edge speaks HTTP/3, upstream only HTTP/1.1) are fine if hop-by-hop framing is correct and you do not assume end-to-end stream identity. HAProxy and reverse-proxy roles need extra care on connection reuse, health checks, and whether UDP listeners share the same certificates and SNI map as TCP. Caddy tends to emphasize automatic TLS and sensible defaults; still verify that HTTP/3 is actually enabled for the hostnames you care about and that redirects and canonical hosts do not strand Alt-Svc on the wrong name.
Rollout, Debugging, and Day-Two Habits
Ship HTTP/3 behind the same canary discipline you use for any protocol change. Watch error rates, retry volume, and fallback frequency before and after Alt-Svc is advertised widely. When clients fail to upgrade, check UDP first, then certificate identity, then whether Alt-Svc points at a live endpoint. Packet captures help, but application logs that record negotiated protocol version and reason for fallback are usually faster for production triage.
Keep this cheat sheet mindset: HTTP/3 is QUIC over UDP with TLS 1.3, discovery via Alt-Svc, and headers via QPACK. Your job is to make that path reachable, observable, and safely optional—using curl for client checks and NGINX, Caddy, or HAProxy for consistent edge and origin configuration—without abandoning the TCP stack that still carries most first requests.