CH-J Server Managerserver management over SSH
Menu
All guides and articles →

How to verify that HTTP/3 and QUIC really work

Why an Alt-Svc header is not proof, what to check in NGINX and the firewall, and how to confirm a real QUIC transfer.

Advertised is not the same as working

A server announces HTTP/3 in the Alt-Svc response header, which the client receives over HTTP/1.1 or HTTP/2. The header is only a promise. HTTP/3 runs over QUIC on UDP, so the page can load normally with UDP completely blocked, and the browser silently stays on HTTP/2.

curl -sI https://server.example/ | grep -i alt-svc

Confirm a real transfer

Only a completed request over QUIC confirms HTTP/3. Use a curl that was built with HTTP/3 support; many system packages are not, and then the option is rejected, which says nothing about the server. In a browser, open the developer tools and read the Protocol column, which shows h3 for such a request. The browser may use HTTP/2 for the first visit, so load the page again.

curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/

Check the NGINX configuration

NGINX needs a QUIC listener next to the TCP one, and the version and its build must support it. TLS 1.3 is required, because QUIC uses it directly. Check the configuration before reloading. The ma value in Alt-Svc is the time in seconds for which clients remember the promise, so use a short value while testing.

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;

nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -t

Open UDP 443 everywhere on the path

The most frequent reason for failure is a firewall that allows TCP 443 and not UDP 443. Check the server and any external filter. Listening on the socket can be confirmed on the server. Some corporate and public networks block QUIC deliberately, so a failed test from one network does not prove that the server is at fault: repeat it from another one.

sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443

Is the new protocol faster?

HTTP/3 helps most on connections with packet loss or changing networks, because a lost packet does not hold up other streams. On a good wired connection the difference may be small and CPU use on the server may be higher. Measure your own case instead of assuming a gain, and keep HTTP/2 available for clients that cannot use UDP.

The HTTP/3 test in CH-J Server Manager

Server Diagnostics has a bundled HTTP client, so the test does not depend on the system curl. It reports HTTP/3 as confirmed only after a completed QUIC transfer and treats Alt-Svc as an advertisement only. On a UDP timeout it says that server support stays unverified, because the cause may be the network between you and the server, and it does not count a fallback to another protocol as success.

Detailed documentation

RFC 9114: HTTP/3 →

NGINX: QUIC and HTTP/3 →

Biometric unlock and security →