h2, h2c, and HTTP/1.1: Practical Choices for Real-World Stacks

By Greg Nowak. Last updated 2026-07-11.

HTTP/3 attracts the attention, but many teams still operate a mixture of HTTP/2 and HTTP/1.1 between browsers, CDNs, load balancers, reverse proxies, and application servers. The practical question is not which protocol looks most modern. It is which choice gives each hop reliable performance without making the stack harder to secure, troubleshoot, or hand over.

For most public websites, the sensible baseline remains simple: serve visitors over HTTPS with h2, retain HTTP/1.1 compatibility, and use cleartext HTTP/2 only inside a controlled environment where both endpoints are explicitly configured for it.

What h2, h2c, and HTTP/1.1 mean

h2 means HTTP/2 over TLS. A browser and server normally select it through ALPN during the TLS handshake. HTTP/2 can carry multiple concurrent request and response streams over one connection and compresses header fields, making it well suited to browser-facing sites with many assets or API calls.

h2c is commonly used to describe HTTP/2 over a cleartext TCP connection. This requires care: RFC 9113 made the old h2c HTTP/1.1 Upgrade mechanism obsolete. For an http:// endpoint, current standards depend on the client having prior knowledge that the server accepts HTTP/2 directly. Some servers retain legacy upgrade support, but it should not be the foundation of a new design.

HTTP/1.1 remains a valid operational choice. It is widely understood, easy to inspect, and often sufficient for a quiet origin connection, an older appliance, or an inherited integration. A visitor using HTTP/2 at the edge does not require every upstream hop to use HTTP/2 as well.

A practical protocol decision matrix

Traffic path	Preferred starting point	Reason	Watch for
Browser to CDN or web server	`h2` with HTTP/1.1 fallback	Secure, broadly compatible public delivery	TLS and ALPN configuration
CDN or proxy to origin	HTTP/1.1 or `h2`, based on support and measurement	The edge and origin protocols need not match	Keep-alives, connection limits, and origin latency
Internal service to service	`h2`, or prior-knowledge cleartext HTTP/2 when the network design permits it	Multiplexing may help busy, concurrent services	Encryption requirements and support at both ends
Legacy system or appliance	HTTP/1.1	Predictability may be worth more than protocol uniformity	Connection reuse and vendor constraints

Choose the protocol per hop. Uniformity is useful only when it reduces operational risk.

Do not confuse edge performance with origin performance

A healthy production path might use HTTP/3 from browser to CDN, HTTP/2 through a load balancer, and HTTP/1.1 to the application. That is not inherently inefficient. Each intermediary terminates one connection and establishes another, so each hop can use the protocol best supported by its endpoints.

Before changing an origin protocol, check whether the real constraint is application response time, cache misses, oversized assets, database work, or poor connection reuse. Moving a slow application from HTTP/1.1 to HTTP/2 does not make its business logic faster. It can also change concurrency and memory behaviour, so rollout decisions should be based on measurements rather than protocol labels.

Current Apache and NGINX patterns

For an Apache TLS virtual host, the standard starting point is:

Protocols h2 http/1.1

Apache also documents cleartext HTTP/2 support:

Protocols h2 h2c http/1.1
H2Direct on

Use the second pattern only when you control the client, server, and network path. Direct mode recognises the HTTP/2 connection preface without attempting the obsolete HTTP/1.1 upgrade dance. Apache enables direct mode by default for h2c, but stating the intent can make an internal configuration easier to review.

Apache’s mod_http2 uses additional worker threads and maintains more connection state than HTTP/1.1. On a busy server, observe memory, worker saturation, error rates, and tail latency during rollout. Shared certificates across several virtual hosts also deserve testing because incompatible TLS settings can result in 421 Misdirected Request responses when HTTP/2 connections are reused.

On NGINX 1.25.1 and later, the documented configuration is:

server {
    listen 443 ssl;
    http2 on;
}

Older installations commonly use listen 443 ssl http2;, so check nginx -v before copying a current snippet into an inherited estate. Remove stale HTTP/2 server-push tuning during the same review: NGINX marks http2_push and http2_push_preload obsolete.

Verify the live path with curl

Configuration files show intent; a request shows what was negotiated. Start with the public endpoint, then test each reachable internal hop separately:

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 HTTP version actually used. The next two help expose version-specific redirects, headers, or failures. The prior-knowledge command speaks cleartext HTTP/2 directly and should be used only when that endpoint is expected to support it. Finally, curl -V confirms whether the installed curl build includes HTTP/2 support.

A safer rollout checklist

Draw the complete request path, including TLS termination and health-check connections.
Record the current protocol, timeout, keep-alive, and connection-pool behaviour on every hop.
Change one boundary at a time and retain a tested fallback where appropriate.
Test normal pages, redirects, uploads, API bodies, authentication, and error responses.
Compare latency, memory, connection counts, upstream errors, and cache behaviour under realistic concurrency.
Document the reason for each choice so the next operator does not have to rediscover it.

If your delivery path has accumulated contradictory proxy settings or nobody can confidently explain which protocol each hop uses, Greg can help map the stack, test the live behaviour, and turn it into a maintainable operating plan. Talk with Greg about your web infrastructure.