EnglishHTTP/3 on a First Visit: How a Client Discovers the Protocol and What Twenty Sites Answered
Contents
A protocol version is not something a client can simply ask for. HTTP/1.1 and HTTP/2 are agreed during the encrypted handshake, in a step where both sides list what they speak. HTTP/3 cannot take part in that step, because it does not use the same kind of connection at all.
Twenty large sites were opened once each. Six of them speak HTTP/3. Not one of the twenty connections used it.
What HTTP/3 does differently
HTTP/1.1 and HTTP/2 both run over TCP. HTTP/3 runs over QUIC, which sits on UDP instead.
The practical gain is in how loss is handled. Under HTTP/2 several requests share one TCP connection, and a single lost packet stalls all of them until it has been resent: every stream waits for one. QUIC keeps the streams independent, so a lost packet delays only what it belonged to.
The cost is that this is a different transport altogether. A client wanting HTTP/3 has to open a UDP connection to a port that may or may not be listening, and it cannot find that out during a TCP handshake, because there is no TCP handshake.
How a client learns that HTTP/3 exists
There are two ways, and both have to happen before the connection that would use it.
The first is a header. A server answering over HTTP/2 can add Alt-Svc: h3=":443", which says: the same content is also available over HTTP/3 on this port, and the offer holds for so many seconds. The client stores that and uses it next time.
The second is DNS. An HTTPS record can name the protocol before any connection exists at all, and that is the only path which works on a genuinely first visit.
Both are announcements. Neither is a request. A client cannot simply try HTTP/3 and fall back, because a failed UDP attempt costs a timeout, and a timeout is worse than not having tried.
What twenty sites answered
On 2 September 2026, a client built for HTTP/3 opened each site once, following redirects. All twenty answered with status 200.
Eighteen connections were made over HTTP/2. Two were made over HTTP/1.1: nginx.org and www.gnu.org, both long-standing project sites.
None were made over HTTP/3 – not even at the six sites whose answers advertised it, because the advertisement arrives inside the answer, and by that point the connection has already been made.
The second request looks different
Three of the sites were then asked twice in a row, with the client keeping what it had been told the first time.
For cloudflare.com, bbc.com and w3.org the first request went over HTTP/2 and the second over HTTP/3, every time. Nothing changed on the server in between. The only difference was that the client had been there once.
That is the shape of HTTP/3 adoption in practice: the first page of a visit is never delivered over it, and everything after it may be. Whether that matters depends on how much of a visit the first request is – for a single page read and left again, quite a lot.
Announced but unreachable, and the reverse
Two sites broke the pattern in opposite directions.
python.org completed an HTTP/3 connection whenever one was forced, but sent no Alt-Svc header and carried no DNS record either. It speaks the protocol and announces it nowhere, so a browser has no way of finding out.
spiegel.de advertised HTTP/3 in its answer, yet five forced attempts from this network never completed. That is a statement about this measurement rather than about the site: a UDP connection can fail along the way for reasons that have nothing to do with the server.
The DNS path turned out to be rare as well. Of ten names checked, three carried an HTTPS record: cloudflare.com, www.cloudflare.com and w3.org.
What follows from this
For anyone running a site, the useful part is the ordering.
Sending Alt-Svc costs one header and moves every request after the first onto HTTP/3. That is the cheap half, and six of twenty sites have it.
The HTTPS DNS record is the half that reaches the first request, and it is the one almost nobody has set. Where a visit is typically a single page, that is exactly where the benefit would sit.
And a measurement of whether a site supports HTTP/3 answers a different question from whether a site is used over HTTP/3. The twenty here support one thing and were used with another.
How the HTTPS record is built, which parameters it carries and what twenty domains published in it in a separate measurement on 5 September 2026 is described in The HTTPS Record in DNS: Finding HTTP/3 Without the Detour.
Questions and answers
What has to be right on the network before a site sends Alt-Svc?
UDP port 443 has to be open along the whole path. Many setups are configured for TCP only: the server firewall allows 443/tcp, the router forwards only TCP, an upstream filter at the provider does not let UDP through. HTTP/2 then works perfectly, and nothing points to the problem.
If the site sends Alt-Svc in that state, browsers, on their next request, run into a connection attempt that never succeeds. They fall back to HTTP/2, but the article names the price: a failed UDP attempt costs waiting time. The announcement then makes the site slower instead of faster.
Two things help. First, a check from outside the local network with a client that can force HTTP/3; as the spiegel.de case shows, the result depends on the path. Second, a short ma value in the header, which is how long the announcement stays valid, in seconds. Without ma, RFC 7838 makes the announcement valid for 24 hours, and for that long a wrong announcement stays in circulation even after it has been removed.
Does HTTP/3 still count when a CDN sits in front of the site?
Yes, but only on the stretch between browser and CDN. The origin server behind it can keep speaking HTTP/1.1 or HTTP/2, and the Alt-Svc header then usually comes from the CDN, not from the origin.
What does an HTTPS record in DNS look like?
In its simplest form, like this:
example.com. 3600 IN HTTPS 1 . alpn=h3,h2
The 1 is the priority and indicates that the record carries service parameters; the dot after it stands for the same name; alpn lists the protocols the server speaks. A browser that queries this record therefore knows before the first connection that HTTP/3 is on offer.
Two prerequisites apply. The DNS provider has to support the HTTPS record type, which not every provider does. And the record does not replace an open UDP port 443: like Alt-Svc it only announces, and an announcement without a reachable port costs the same waiting time, this time on the very first visit.
Related articles
