h2, h2c, or HTTP/1.1? Practical Choices for Real-World Stacks

By Greg Nowak. Updated 11 August 2026.

HTTP/3 gets the headlines, but most production stacks still contain a mixture of HTTP/2 and HTTP/1.1. A browser may connect to a CDN using HTTP/2 while the CDN, load balancer, reverse proxy, and application use different protocols between them.

That is not necessarily technical debt. The useful question is whether each hop is secure, supported, observable, and appropriate for its traffic. For most public websites, a sound starting point is h2 over HTTPS for visitors, HTTP/1.1 compatibility, and no cleartext HTTP/2 unless the relevant network boundary is deliberately controlled.

Choose the protocol one hop at a time

What h2, h2c, and HTTP/1.1 actually mean

h2 is HTTP/2 over TLS. The client and server normally select it through ALPN during the TLS handshake. HTTP/2 can multiplex concurrent exchanges over one connection and compress header fields, which is valuable for busy browser sessions and APIs.

h2c is still widely used as shorthand for HTTP/2 over cleartext TCP. However, RFC 9113 made the old HTTP/1.1 Upgrade: h2c mechanism obsolete. A current cleartext implementation should use prior knowledge: the client is configured to know that the endpoint accepts HTTP/2 and sends the HTTP/2 connection preface immediately.

Cleartext does not become safe merely because a hostname is internal. Use it only where encryption is supplied elsewhere or where the organisation has explicitly accepted the exposure. Otherwise, use TLS.

HTTP/1.1 remains a sensible choice for quiet upstreams, inherited systems, and well-tuned connection pools. Switching protocol versions will not repair slow application code, database queries, cache misses, oversized responses, or poorly configured keep-alives.

Do not mistake edge performance for origin performance

A request might use HTTP/3 from browser to CDN, HTTP/2 from CDN to load balancer, and HTTP/1.1 from proxy to application. Each intermediary terminates one connection and opens another, so the versions do not need to match.

Before changing an origin hop, establish what is actually constrained. Record response time, upstream connection counts, reuse rates, memory, timeouts, error rates, and tail latency. HTTP/2 can improve connection utilisation under concurrency, but it also changes resource use and failure behaviour.

Current Apache configuration patterns

For an Apache TLS virtual host, start with:

Protocols h2 http/1.1

If a controlled cleartext endpoint genuinely needs prior-knowledge HTTP/2, make that intention explicit:

Protocols h2c http/1.1
H2Direct on
H2Upgrade off

H2Direct recognises the HTTP/2 preface immediately. Disabling H2Upgrade avoids building a new deployment around the obsolete upgrade route that Apache can still support for compatibility.

Apache’s mod_http2 uses additional worker threads and retains more per-connection state than HTTP/1.1. Watch memory, worker saturation, concurrent streams, and tail latency. Also test virtual hosts sharing certificates and TLS connections: inconsistent SSL settings can produce 421 Misdirected Request responses when a connection is reused across hostnames.

Current NGINX configuration patterns

NGINX 1.25.1 introduced the separate http2 directive used by current configurations:

server {
    listen 443 ssl;
    http2 on;
}

Older installations commonly use listen 443 ssl http2;, so run nginx -v before changing an inherited configuration. Remove stale server-push tuning during the review: NGINX documents http2_push and http2_push_preload as obsolete.

Recent NGINX releases also changed the upstream picture. Generic proxying gained proxy_http_version 2; in 1.29.4, while HTTP/1.1 became the default in 1.29.7. Do not assume those behaviours exist on an older packaged release:

location / {
    proxy_pass https://application_pool;
    proxy_http_version 2;
}

Adopt upstream HTTP/2 only after confirming the installed build, application support, TLS expectations, and performance under realistic concurrency.

Test what the live path negotiated

Configuration shows intent; requests reveal behaviour. Test the public endpoint, then every internal boundary you can reach safely:

curl -sS -o /dev/null -w '%{http_version}\n' https://example.com
curl --http1.1 -I https://example.com
curl --http2 -I https://example.com
curl --http2-prior-knowledge http://internal-service:8080/health
curl -V

The first command reports the negotiated version. Forced-version requests can expose different redirects, headers, or failures. Use the prior-knowledge command only for an endpoint expected to accept cleartext HTTP/2. curl -V confirms whether that curl build includes HTTP/2 support.

Roll out without making diagnosis harder

1. Draw the full request path, including TLS termination, health checks, and service-mesh boundaries.
2. Record the current protocol, timeouts, keep-alives, pools, and baseline measurements for every hop.
3. Change one boundary at a time and retain a tested fallback where appropriate.
4. Exercise pages, redirects, authentication, uploads, API bodies, streaming responses, and failure paths.
5. Compare latency, memory, connection counts, cache behaviour, and upstream errors under realistic load.
6. Document why each protocol was chosen and how operators can verify it.

If your stack has accumulated contradictory proxy settings—or nobody can confidently explain what happens between the CDN and application—Greg can map the path, test its live behaviour, and turn the findings into a maintainable operating plan. Talk with Greg about your web infrastructure.

Related on GrN.dk

• NGINX 1.30 changed upstream connection reuse: what to check before you upgrade
• JavaScript-Heavy Service Pages Still Lose Leads: What to Audit in 2026
• Upgrading PHP 5: Use PHP 7 as a Bridge, Not the Destination

Need help with this kind of work?

Talk with Greg about your web stack Get in touch with Greg.

Sources

• RFC 9113: HTTP/2
• Apache Module mod_http2
• NGINX ngx_http_v2_module
• NGINX ngx_http_proxy_module
• curl command-line manual