Nginx, Apache, and Caddy HTTP/2 config checks
nginx HTTP/2 config · Apache HTTP/2 config · Caddy HTTP/2 check
Configuration checkpoints for enabling HTTP/2 safely on common web servers.
By DN01 Network Team
Nginx, Apache, and Caddy expose HTTP/2 through different configuration surfaces, but the production checklist is the same: TLS listener, ALPN, hostname, proxy path, and post-change verification. 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.
A practical check confirms the public protocol after reload, then compares expected headers, certificate chain, redirects, and cache behavior from the outside. 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/http2-seo-performance-impact and /en/articles/troubleshoot-http2-failures, especially when a result changes during a deployment window or CDN migration.
What to verify first
After changing server config, run /en/http2-tester and pair it with /en/ssl-certificate-checker and /en/http-header-checker for the same hostname. 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.
Configuration can look correct locally while a managed load balancer, container ingress, or stale virtual host serves the public hostname with 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
Keep separate notes for each virtual host, especially when apex, www, admin, and API domains terminate TLS in different places. 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.