curl, the Swiss Army knife of command-line network tools, can now speak HTTP/3 thanks to its QUIC support.

Here’s a quick demo. First, find an endpoint that advertises HTTP/3 support. Many public HTTP/3 test servers exist, but for a quick local test, you can run a simple QUIC server. Let’s assume you have nghttp installed and running on localhost:8080 with HTTP/3 enabled.

curl --http3 https://localhost:8080/

If that works, you’ll see the content of your / endpoint. If it fails, you might see an error like curl: (92) Protocol 'quic' not supported or disabled in build. This means your curl binary wasn’t compiled with QUIC support. You’ll need to install a version of curl that has it. On many Linux distributions, this might be curl itself if it’s recent enough, or you might need to install a specific package like curl-quic. On macOS, brew install curl --with-openssl --with-quic is often the way.

Now, what if curl is built with QUIC support, but you still can’t connect? The most common reason is that the server isn’t actually offering HTTP/3, or it’s using a different port than you expect.

curl --http3 -v https://example.com/

The -v flag is your best friend here. Look for lines indicating the TLS handshake and ALPN negotiation. If you see ALPN, server accepted to use h3, that’s a good sign. If you see ALPN, server did not advertise h3, then the server isn’t advertising HTTP/3. The server might be configured to only accept HTTP/1.1 or HTTP/2.

Another common pitfall is firewalls. QUIC (and thus HTTP/3) typically runs over UDP port 443. If your network infrastructure, or a firewall on the server, is blocking UDP traffic on port 443, your HTTP/3 connection will fail, often with a connection timeout or a "network unreachable" error.

Sometimes, the server might advertise HTTP/3 but have issues with its certificate. QUIC, like TLS for HTTP/1.1 and HTTP/2, requires a valid certificate. If curl reports certificate errors (e.g., curl: (60) SSL certificate problem: unable to get local issuer certificate), you’ll need to ensure the server’s certificate is trusted by your system or use the --insecure flag (not recommended for production).

If you’re connecting to an IPv6 address, ensure your system’s IPv6 stack is functional and that the server is correctly configured for IPv6. QUIC works over both IPv4 and IPv6, but misconfigurations in either can lead to connectivity issues.

Finally, consider the nghttp3 library and ngtcp2 library versions curl was built against. Compatibility issues between curl and its QUIC dependencies can sometimes manifest as subtle connection failures or unexpected behavior. If you’re building curl from source, ensure you’re using compatible versions of these libraries.

Once you’ve successfully connected via HTTP/3, you’ll likely encounter the next challenge: understanding the performance characteristics and debugging specific HTTP/3 frame issues.

Want structured learning?

Take the full Http3 course →