HTTP/2 TLS requirements
HTTP/2 TLS requirements · h2 TLS · HTTP/2 certificate check
Practical TLS requirements for reliable HTTP/2 support on public websites and APIs.
By DN01 Network Team
Most public HTTP/2 traffic is negotiated over TLS, so protocol support depends on the certificate, SNI, cipher policy, ALPN, and the listener that terminates HTTPS. The safest way to answer that question is to test the same public hostname, scheme, and redirect path that users, crawlers, or API clients actually reach. A protocol badge in one browser tab is useful, but it does not prove that every hostname, CDN edge, or backend route is negotiating the same protocol.
The result should connect protocol status with TLS version, certificate hostname coverage, redirect targets, and any mismatch between the requested host and the served certificate. On DN01, start with the HTTP/2 Tester at /en/http2-tester, then keep the related HTTP Header Checker and SSL Certificate Checker close by. HTTP/2 is negotiated through TLS and frequently hidden behind redirects or proxies, so reading only one signal rarely explains the whole failure.
This article is part of the HTTP/2 Tester guide set. For adjacent checks, read /en/articles/h2-vs-http11 and /en/articles/http2-cdn-proxy-issues, especially when a result changes during a deployment window or CDN migration.
What to verify first
Check the host with /en/http2-tester and confirm the certificate chain with /en/ssl-certificate-checker before changing server directives. Use the exact production hostname instead of a convenient test domain. Include apex, www, API, static asset, and regional hostnames when they terminate TLS in different places.
Check the final URL after redirects. A site can redirect from an HTTP/2-enabled hostname to a legacy hostname, or from a modern CDN edge to an origin path that speaks only HTTP/1.1.
Record the time, target, final protocol, and any visible TLS or header clues. These details make later incident reviews more useful than screenshots without context.
How to read the result
A successful h2 result means the tested client and the public endpoint negotiated HTTP/2 for that request. It does not automatically prove that every upstream hop, internal service, or alternate hostname uses HTTP/2.
An HTTP/1.1 result is not always a defect. Some legacy clients, private origins, debugging endpoints, and explicit compatibility paths intentionally keep HTTP/1.1. The key is whether the result matches your architecture and user expectations.
A site can pass a basic certificate check but fail HTTP/2 because the HTTPS listener uses an old OpenSSL build, a legacy cipher profile, or an upstream proxy that only speaks HTTP/1.1. That is why protocol checks belong next to TLS and header checks rather than in a separate spreadsheet.
Links to neighboring checks
Open /en/ssl-certificate-checker when the protocol result points toward TLS, certificate, SNI, or ALPN trouble. Certificate hostname coverage and TLS listener policy are common reasons for unexpected fallback.
Open /en/http-header-checker when redirects, cache behavior, Via headers, Alt-Svc, HSTS, or server headers may explain why one path behaves differently from another.
For broader launch reviews, keep /en/http2-tester linked from your runbook beside DNS, SSL, and header checks so teams verify the same public surface before and after release.
Operational checklist
After renewal or load balancer changes, repeat both checks for apex, www, API, and regional hostnames rather than assuming one certificate path covers every entry point. Do not rely on a single green result from a local laptop if production traffic reaches multiple regions or providers.
Test before the change, immediately after rollout, and again after CDN or DNS caches have had time to settle. If a provider has regional edges, compare at least two client locations or monitoring regions.
Attach the DN01 result URLs or copied output to the ticket. When platform, security, and frontend teams share the same evidence, HTTP/2 investigations usually become much shorter.
| Signal | Why it matters |
|---|---|
| Negotiated protocol | Shows whether this request used h2 or HTTP/1.1. |
| TLS and ALPN | Explains many HTTP/2 fallbacks before headers are exchanged. |
| Redirect chain | Reveals protocol changes caused by canonical host or path rules. |
| Response headers | Shows CDN, proxy, cache, HSTS, and server clues. |
Frequently asked questions
- Does HTTP/2 Tester replace browser devtools?
No. It gives an independent outside check that is easier to share in tickets. Use it together with browser devtools when debugging user-specific behavior.
- Can a site support HTTP/2 and still be slow?
Yes. HTTP/2 reduces some connection overhead, but slow origins, cache misses, large assets, and blocking scripts can still dominate page speed.
- Why should I also check SSL and headers?
HTTP/2 depends on TLS negotiation for most public sites, while headers and redirects often reveal CDN or proxy behavior that changes the final protocol.