Tester HTTP/2

Use the tester after enabling HTTP/2 on a CDN, load balancer or origin server. A successful TLS certificate does not guarantee that ALPN advertises h2 for every hostname.

Run it before and after redirect or HSTS changes. The protocol seen on the final public URL is the one browsers and synthetic monitors care about.

Check apex and www separately, especially when DNS points them at different providers or CDN zones.

If a host falls back to HTTP/1.1, inspect TLS settings and ALPN configuration first. Older load balancer profiles may support TLS but not advertise h2.

If only one hostname fails, compare DNS and certificate SAN coverage. The request may reach a different edge or origin than expected.

If redirects are involved, test the final hostname directly and inspect headers to understand whether the first hop is changing scheme or host.

HTTP/2 support is negotiated before application headers are interpreted. ALPN tells the client whether h2 is available on the TLS connection.

CDNs can enable h2 at the edge while origins still speak HTTP/1.1 behind the proxy. This tester reports the public path, which is usually what users experience.

Protocol support is only one layer. Keep checking certificate validity, redirect policy and response headers when hardening production sites.

curl with verbose TLS output is powerful, but not every teammate has it available or knows the flags. DN01 gives a browser-based protocol snapshot with copyable output.

Browser DevTools show protocol per request after loading a page. The tester is faster for a single hostname when you need evidence for a ticket or deployment checklist.

Dedicated performance suites measure waterfalls, prioritization and Core Web Vitals. This tool answers the narrower question: does the public host negotiate HTTP/2 now?