HTTP/3 on a First Visit: How a Client Discovers the Protocol and What Twenty Sites Answered

HTTP/3 can carry the first request to a site. Whether that happens depends on the client, available endpoint information and the network path. A server advertising HTTP/3, a reachable QUIC endpoint and a request actually using HTTP/3 are three different observations.

A different transport, still a TLS handshake

HTTP/3 uses QUIC over UDP. HTTPS with HTTP/1.1 or HTTP/2 normally uses TLS over TCP. QUIC integrates a TLS handshake too: HTTP/3 is normally selected with the ALPN identifier h3. It cannot be negotiated into an existing TCP connection.

QUIC transfers separate HTTP exchanges in independent streams. A missing packet in one stream therefore does not automatically hold up unrelated streams as it can with TCP. That does not make packet loss harmless: a packet can contain data from several streams, congestion control affects the connection, and application dependencies can still delay work. HTTP/3 is not a universal speed guarantee.

Three ways to reach HTTP/3

• An alternative-service announcement: an HTTP response can include Alt-Svc: h3=":443"; ma=3600. It advertises an equivalent endpoint on UDP port 443 of the same host for a freshness lifetime of one hour. A supporting client may use it for later requests, including resources within the same page load. No automatic switch of every subsequent request is guaranteed.
• DNS information: an HTTPS record can provide protocol and endpoint information before the first HTTP request. Client and resolver behavior determine whether that information is obtained and used.
• An explicit attempt or other endpoint knowledge: RFC 9114 permits a client to attempt a QUIC connection directly. A tool configured for HTTP/3 does not require an earlier HTTP/2 response.

Fallback is possible. For example, curl with --http3 can race a TCP-based alternative after a short delay; --http3-only deliberately excludes that fallback. Browser strategies vary. A failed UDP attempt can add delay, but does not necessarily force the page to wait for a full UDP timeout.

What twenty recorded requests showed

The following sample was collected on 24 October 2026, between 04:45:33 and 04:45:37 UTC, from one network using curl 8.14.1 with HTTP/3 support. Each domain started a separate curl process. HTTPS redirects were followed, up to five; there was no --http3 option or persisted Alt-Svc cache. The configured timeout was 25 seconds and the transfer-size limit 10 MB. These were command-line requests, not browser page loads.

The table reports the final response in each redirect chain, not every intermediate connection. Eighteen final responses used HTTP/2 and two used HTTP/1.1. Four final responses advertised the standard h3 token. That is an announcement count, not a complete HTTP/3 capability test.

Seventeen responses contained regular page HTML. The New York Times and ZEIT returned 403 access blocks; Microsoft returned a blocking page with status 200. Those three rows still identify the transport used for the response, but do not describe the requested homepage. A missing Alt-Svc header in one response does not prove that HTTP/3 is unavailable.

A direct first request can use HTTP/3

A separate check on 25 October 2026 at 14:47:15 UTC used a fresh process with --http3-only for each of cloudflare.com, bbc.com and w3.org. No Alt-Svc cache was supplied and redirects were not followed. All three requests completed with curl exit code 0, HTTP version 3 and status 301, pointing to the corresponding www host.

This demonstrates a successful HTTP/3 response without a previous HTTP/2 request in those test processes. It does not demonstrate browser discovery, homepage delivery or a speed advantage. The choice of protocol was explicitly configured.

Reading an HTTPS DNS record

example.com. 3600 IN HTTPS 1 . alpn=h3,h2

This illustrative record uses ServiceMode because the priority is nonzero. The dot means that the target is the name at the start of this record, here example.com; alpn advertises HTTP/3 and HTTP/2. The TTL allows this DNS record to remain cached for 3600 seconds. The record requires an actually configured endpoint and suitable address records; publishing the text does not activate a server. It also does not force every client to choose HTTP/3.

Further details are described in The HTTPS Record in DNS: Finding HTTP/3 Without the Detour.