HTTP/3 runs over QUIC, a UDP-based transport with TLS 1.3 built in. The payoff for your visitors is concrete: connection setup takes one round trip instead of two, repeat visits can skip the handshake entirely with 0-RTT, and head-of-line blocking disappears because each stream is independent. Every major browser has supported HTTP/3 for years, so enabling it is mostly a server configuration question. Here is how to turn it on for the two most common web servers on a VPS — Nginx and Caddy.
Prerequisites
You need three things: a TLS certificate (Let’s Encrypt works fine — QUIC requires TLS 1.3), UDP port 443 reachable, and a web server build that includes QUIC support. Nginx needs version 1.25.0 or newer compiled with --with-http_v3_module; many current distro packages include it, but check with nginx -V 2>&1 | tr ' ' '\n' | grep http_v3. Caddy 2.6 and newer include HTTP/3 out of the box.
Enabling HTTP/3 in Nginx
In your server block, listen on UDP 443 with the QUIC protocol alongside the normal TLS listener. Use reuseport so QUIC connections distribute across worker processes, and advertise the new protocol with the Alt-Svc header so browsers know to try it:
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
# ... rest of your server block ...
}
Validate and reload:
nginx -t && sudo systemctl reload nginx
Keep http2 on; — HTTP/3 is an addition, not a replacement. Browsers that cannot reach UDP 443 (some corporate networks block it) will silently fall back to HTTP/2 over TCP.
Enabling HTTP/3 in Caddy
Caddy is the easy path: since version 2.6, any site served over HTTPS automatically gets HTTP/3, including the Alt-Svc advertisement. There is no configuration flag to set — if your Caddyfile has a site block with a domain and you can reach https://your-domain over TCP 443, QUIC is already listening on UDP 443. Confirm the version with caddy version and update if it is older than 2.6.
Firewall and Network Notes
Most firewalls only open TCP 443 by default, and QUIC needs UDP 443. With ufw: sudo ufw allow 443/udp. If your VPS sits behind a cloud provider security group, add a UDP 443 rule there too. Some NAT or DPI equipment drops QUIC; that is fine — clients fall back to HTTP/2 — but it means your HTTP/3 adoption rate will vary by visitor region. Compare providers side by side in our VPS comparison table if you need a host with clean UDP routing and low loss.
Verifying HTTP/3 Works
Three ways to confirm. From the server, use a curl build with QUIC support (Debian/Ubuntu package curl 8.2+ compiled with ngtcp2):
curl --http3 -I https://example.com
In Chrome or Edge, open DevTools, click the Network tab, and look at the Protocol column — it should show h3 for resources served over QUIC (reload a couple of times, since the first load may still use HTTP/2). Online checkers such as http3check.net report the negotiated protocol from an external vantage point. Finally, confirm the advertisement is present: curl -sI https://example.com | grep -i alt-svc.
Troubleshooting
If the protocol column never shows h3, work through these in order. First, confirm the server is actually listening on UDP 443: sudo ss -ulpn | grep 443 should show your web server’s process. Second, verify UDP 443 is open end to end — a host firewall rule is not the same as a cloud security group, and both must allow it. Third, check that the Alt-Svc header is present on the TLS response; browsers only try QUIC after seeing it, and an always parameter matters because some proxies strip the header on cached responses. Finally, test from a different network: if QUIC works from your phone’s mobile data but not your office, a middlebox is dropping UDP, and there is nothing to fix on the server side.
Caveats Worth Knowing
0-RTT data is replayable, so QUIC stacks only send idempotent requests in the early data — keep that in mind for any custom QUIC applications. On networks that drop UDP or suffer high loss, HTTP/3 can feel worse than HTTP/2; the fallback handles this automatically, and Alt-Svc with a reasonable ma lets browsers re-evaluate periodically. There is also a small CPU cost for QUIC’s encryption per packet, which matters only on very high-traffic boxes.
Bottom Line
HTTP/3 is a low-risk, measurable win: one UDP firewall rule and a small config change on Nginx, or zero config on Caddy. Verify with curl and DevTools, keep HTTP/2 as the fallback, and monitor your protocol mix over a week. If you are also squeezing latency elsewhere — TLS 1.3 session resumption, BBR, or a closer data center — the gains compound; see the full specs and pricing on the main site to check which hosts offer the network options you need.


Leave a Reply
You must be logged in to post a comment.