What is HTTP/3 and what is QUIC?

**HTTP/3 is the same HTTP semantics** (same methods, same status codes, same headers) running over a different transport called **QUIC**. QUIC is a UDP-based protocol that bundles **TLS 1.3 into the transport layer**, so the handshake is one round trip instead of two (or zero for return visits, with 0-RTT). Crucially, QUIC streams are **independent at the transport layer**, so a lost packet only stalls one stream, not the whole connection. The win is most visible on **mobile networks with packet loss**: HTTP/3 is up to twice as fast on flaky links. The cost is more CPU at both ends and corporate firewalls that block UDP/443 by default.

How do I enable HTTP/2 on nginx?

In your server block add `http2` to the listen directive: `listen 443 ssl http2;`. That is literally it on **nginx 1.9.5+** (released October 2015). You still need TLS, since the browser uses ALPN to negotiate h2 only over TLS. Reload nginx (`sudo nginx -s reload`) and run this detector to confirm. If the card still shows http/1.1, double-check that the listen line is **actually on the server block your TLS cert is bound to**, not a stale default block.

How do I enable HTTP/2 on Apache?

Two steps. First, `a2enmod http2` to load the module. Second, in your virtual host add `Protocols h2 http/1.1` inside the ` ` block. Restart Apache and re-test. Apache 2.4.17+ supports it. **Watch out for mod_php with prefork**: HTTP/2 in Apache requires the **event or worker MPM**, not prefork. If you are still on prefork, switch to PHP-FPM first and then enable http2.

What is ALPN and why is it the source of truth for HTTP/2?

ALPN (Application-Layer Protocol Negotiation) is a **TLS extension** where the client lists which application protocols it speaks (e.g. `["h2", "http/1.1"]`) inside the ClientHello, and the server picks one and announces it in its ServerHello. The result is **negotiated during the TLS handshake**, before any HTTP request goes out. This is why ALPN tells the truth: if the server picks `h2`, you know HTTP/2 is going to be used. If it picks `http/1.1` even though h2 was offered, HTTP/2 is not enabled on this server. Our tool runs exactly that handshake and reports what the server chose.

What is the Alt-Svc header?

Alt-Svc (RFC 7838) is the **standard way for a server to advertise an alternative service** for the same origin. For HTTP/3 it looks like `Alt-Svc: h3=":443"; ma=86400` and translates to: "you reached me over TCP, but I also speak HTTP/3 on UDP 443, and you can cache this fact for 24 hours". On the next request the browser will try QUIC directly. **Without Alt-Svc, browsers will never attempt HTTP/3**, even if your server speaks it. Cloudflare, Fastly, and other modern CDNs send Alt-Svc automatically. Vanilla nginx requires you to add it by hand with `add_header alt-svc 'h3=":443"; ma=86400';`.

Why does my server speak HTTP/3 internally but Alt-Svc is missing?

Three classic causes. **First**, the server is configured to listen on UDP/443 but the operator forgot to add the `add_header Alt-Svc ...` directive, so browsers never learn about it. **Second**, the Alt-Svc header is added inside a virtual host that is not the one the browser hits (proxy block vs main block). **Third**, there is an upstream reverse proxy or WAF that strips Alt-Svc out of responses (Cloudflare in front of an origin sometimes does this). Fix: run this detector to confirm the header is missing, then add it explicitly on the **outermost** layer that touches the public response.

Cloudflare claims it serves HTTP/3, how do I verify?

Run the detector against your cloudflare-fronted hostname. You should see **HTTP/2 card: supported** (Cloudflare always speaks h2), and **HTTP/3 card: advertised** with a raw Alt-Svc value like `h3=":443"; ma=86400, h3-29=":443"; ma=86400`. If HTTP/3 is **not** advertised, open the Cloudflare dashboard, go to Network, and confirm "HTTP/3 (with QUIC)" is **On**. The setting is per-zone (per-domain), not account-wide.

What are 103 Early Hints?

103 Early Hints (RFC 8297) is an **informational HTTP status code** the server can send **before** the final response is ready. It is used to ship a few Link rel=preload headers (CSS, JS, fonts) so the browser can start fetching them in parallel while the backend is still rendering the actual HTML. Implemented by Cloudflare since 2021 and by Fastly, it can shave 50 to 200 ms off the first-paint on slow backends. The catch: most fetch APIs (including the one in modern browsers) consume the 103 frame internally and never expose it to JavaScript, which is why our tool flags Early-Hints as "not detectable from fetch". Use `curl --http2 -v` or Chrome DevTools to actually see them.

I see HTTP/3 is advertised but the page still loads over HTTP/2. Why?

Common reasons. **First request**: the browser does not know HTTP/3 is available until it sees Alt-Svc, so the very first page load is always over h2/h1.1. From the second request on, the browser tries QUIC. **Corporate networks** frequently block UDP/443 at the firewall, so QUIC times out and the browser falls back to TCP. **Some browsers** (older Safari, Edge with strict policies) ship HTTP/3 off by default. **A short Alt-Svc max-age** (a few minutes) means the browser keeps re-learning instead of using the cached value. To force a clean test in Chrome, use `chrome://net-export` and watch the QUIC session events; if you only see TCP, your network is the problem, not the server.

HTTP/2 + HTTP/3 + QUIC Detector - free

Does this site speak HTTP/2 and HTTP/3?

Paste a URL, hit "Check", and we open a TLS handshake to the host, ask the server which ALPN protocol it picks (`h2` or `http/1.1`), then do a HEAD request and read the Alt-Svc header (the canonical way servers advertise HTTP/3 over QUIC).

You get three cards (HTTP/1.1, HTTP/2, HTTP/3) with a status pill on each one, the raw Alt-Svc value parsed into a small table, a list of Link rel=preload entries (server-push hints), and a note about 103 Early-Hints (these are invisible to the Web fetch API).

This is the same kind of check you would run with `curl -v --http2 --http3` or Chrome DevTools, but laid out as a single one-shot diagnostic page.

How to use it

Paste the full URL of the site (e.g. `https://cloudflare.com`). You can omit `https://`, we add it.
Click "Check" or press Enter. The server has ~12 seconds total (two TLS handshakes plus one HEAD fetch), in practice 1 to 4 seconds.
Read the three protocol cards. Green pill = directly confirmed via ALPN. Yellow pill = the server advertises it via Alt-Svc but we could not directly verify (typical for h3). Gray pill = no support detected.
Look at the raw Alt-Svc value. `h3=":443"; ma=86400` means HTTP/3 is offered on UDP 443 for 24 hours. Multiple comma-separated entries are fine, the parser handles them.
Check Link rel=preload entries. These are the server hints a CDN issues so a browser can grab CSS/JS in parallel with the HTML response (works with HTTP/2 and 103 Early-Hints).
Open the Evidence list at the bottom for the per-source detail: which ALPN was offered, what the server replied, what Alt-Svc value came back, why HTTP/3 is or is not advertised.

When this is useful

Six typical jobs this tool gets pulled in for:

Verifying that you actually shipped HTTP/2 after enabling it in nginx / Apache / Caddy. The config check is one thing, an end-to-end probe is another. ALPN tells the truth.
Checking that a CDN is advertising HTTP/3 for your origin. Cloudflare, Fastly, Bunny, AWS CloudFront all set Alt-Svc; if you do not see `h3=` here, the browser will never try QUIC.
Debugging a "site feels slow on mobile" report. HTTP/3 is dramatically more resilient on flaky cellular networks. If the tool shows HTTP/3 is not advertised, that is one cheap fix.
Before submitting your site to a performance audit (Lighthouse, PageSpeed, WebPageTest). A missing HTTP/2 is a one-line nginx fix that often jumps the score 5 to 10 points.
After a CDN switch (Cloudflare to Fastly, or vice versa). Confirm the new CDN is advertising the protocols you expect and that Alt-Svc points at the right port.
Procurement / vendor checks. You are evaluating a hosting provider and want a one-glance answer: does their default config ship HTTP/2 and HTTP/3, or are you on HTTP/1.1?

Questions and answers

HTTP/1.1 opens one request per TCP connection and processes them in order. If your page needs 30 assets, browsers spin up 6 connections in parallel, and the 7th request has to wait. HTTP/2 introduces multiplexing: a single TLS connection carries many concurrent streams (typically up to 100), interleaved on the wire. The benefit is biggest on pages with lots of small assets (CSS sprites, icons, lazy chunks). HTTP/2 also adds header compression (HPACK) so repeated cookies and User-Agent strings stop dominating the request size. The cost is a heavier handshake and a single TCP head-of-line blocker (one lost packet stalls all streams), which is exactly what HTTP/3 fixes by moving to QUIC.

Does this site speak HTTP/2 and HTTP/3?

This is the same kind of check you would run with `curl -v --http2 --http3` or Chrome DevTools, but laid out as a single one-shot diagnostic page.

How to use it

Paste the full URL of the site (e.g. `https://cloudflare.com`). You can omit `https://`, we add it.

Click "Check" or press Enter. The server has ~12 seconds total (two TLS handshakes plus one HEAD fetch), in practice 1 to 4 seconds.

Read the three protocol cards. Green pill = directly confirmed via ALPN. Yellow pill = the server advertises it via Alt-Svc but we could not directly verify (typical for h3). Gray pill = no support detected.

Look at the raw Alt-Svc value. `h3=":443"; ma=86400` means HTTP/3 is offered on UDP 443 for 24 hours. Multiple comma-separated entries are fine, the parser handles them.

Check Link rel=preload entries. These are the server hints a CDN issues so a browser can grab CSS/JS in parallel with the HTML response (works with HTTP/2 and 103 Early-Hints).

Open the Evidence list at the bottom for the per-source detail: which ALPN was offered, what the server replied, what Alt-Svc value came back, why HTTP/3 is or is not advertised.

When this is useful

Six typical jobs this tool gets pulled in for:

Verifying that you actually shipped HTTP/2 after enabling it in nginx / Apache / Caddy. The config check is one thing, an end-to-end probe is another. ALPN tells the truth.
Checking that a CDN is advertising HTTP/3 for your origin. Cloudflare, Fastly, Bunny, AWS CloudFront all set Alt-Svc; if you do not see `h3=` here, the browser will never try QUIC.
Debugging a "site feels slow on mobile" report. HTTP/3 is dramatically more resilient on flaky cellular networks. If the tool shows HTTP/3 is not advertised, that is one cheap fix.
Before submitting your site to a performance audit (Lighthouse, PageSpeed, WebPageTest). A missing HTTP/2 is a one-line nginx fix that often jumps the score 5 to 10 points.
After a CDN switch (Cloudflare to Fastly, or vice versa). Confirm the new CDN is advertising the protocols you expect and that Alt-Svc points at the right port.
Procurement / vendor checks. You are evaluating a hosting provider and want a one-glance answer: does their default config ship HTTP/2 and HTTP/3, or are you on HTTP/1.1?

Questions and answers

HTTP/2 + HTTP/3 + QUIC Detector

Does this site speak HTTP/2 and HTTP/3?

How to use it

When this is useful

Questions and answers

Related tools

SSL Certificate Inspector

HTTP Headers Inspector

HTTP request tester

Cloud Provider / CDN Detector

HTTP/2 + HTTP/3 + QUIC Detector

Does this site speak HTTP/2 and HTTP/3?

How to use it

When this is useful

Questions and answers

Related tools

SSL Certificate Inspector

HTTP Headers Inspector

HTTP request tester

Cloud Provider / CDN Detector