No Alt-Svc header advertises HTTP/3
What this check looks for
The response does not mention that an HTTP/3 endpoint is available. This is a note, not a problem — and it only tells you what was advertised, not what your site actually supports.
Why it matters
Nothing is wrong. HTTP/3 mainly helps visitors on lossy mobile networks, where it avoids one stalled packet holding up every other download. It is recorded here because it is usually a single switch on a CDN or a modern server.
When the check passes, your report says: “An Alt-Svc header advertises an HTTP/3 endpoint”.
What it costs your score
This check never deducts. It reports a fact — or reports that something could not be verified — and is shown on the report without moving the score.
- Severity
- info
- Default confidence
- confirmed
- Status when triggered
- info
- Deduction
- 0 points
- Family cap
- none
- Category
- HTTP
- Module
- Http headers
- Fix owned by
- user
- In the ruleset since
- 2026.09
Technical detail
**This rule grades advertisement only, and deducts nothing.** No Alt-Svc header naming h3 was present on the response from ‹origin›.
The honest limitation: the protocol version actually negotiated is not observable through the edge fetch API this scanner uses. We can read the headers a response carried; we cannot see whether the connection that carried them was HTTP/1.1, HTTP/2 or HTTP/3. So a site may well be serving HTTP/3 to real visitors without advertising it in a way this check can see, and the absence of the header is not evidence of absent support. That is why this is info and why it removes no points.
RFC 7838 defines Alt-Svc as the mechanism by which an origin announces an alternative service — Alt-Svc: h3=":443"; ma=86400 tells a client that HTTP/3 is available on the same port and that the announcement is good for a day. A client that has never seen the header still makes its first connection over TCP, so advertising is what lets a returning visitor upgrade. RFC 9114 is HTTP/3 itself.
Common reasons the header is genuinely absent: HTTP/3 is not enabled at the edge; the server predates support (nginx gained it in 1.25.0, and it requires listen … quic alongside http3 on); or UDP/443 is blocked by a firewall in front, in which case advertising it would only cause clients to try and fail back. Caddy enables and advertises HTTP/3 by default. Detected server: ‹detected server›.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other http headers checks
- The caching instructions contradict each other
- A text response does not declare its character encoding
- The declared Content-Encoding may not match the body
- A compressible response was sent uncompressed
- The response has a body but no Content-Type
- The response sends obsolete headers, one of them harmful
- A response header leaks an internal address
- The response does not say how long it may be cached
- The response cannot be revalidated without downloading it again
- A compressed response does not vary on Accept-Encoding
- Vary: * makes the response uncacheable by any shared cache