TLS ALPN and HTTP/2 Negotiation PCAP Analysis: h2 vs http/1.1, Handshake Evidence, and Protocol Fallback

Many "HTTP/2 not working" incidents are really TLS ALPN negotiation problems. Users search for "TLS ALPN pcap", "HTTP2 fallback to HTTP/1.1", "ALPN h2 not negotiated", "ClientHello ALPN extension", "ServerHello selected protocol", and "why is my browser using HTTP/1.1" when an endpoint should support HTTP/2 but traffic falls back.

PCAP Surgery is useful because ALPN evidence lives in the TLS handshake. If the capture includes the ClientHello and ServerHello, you can often prove whether the client offered h2, whether the server selected it, whether a proxy terminated TLS, or whether the connection never had a chance to negotiate HTTP/2.

What ALPN does

ALPN means Application-Layer Protocol Negotiation. It allows the client and server to agree on an application protocol during TLS setup.

Common ALPN values:

• h2 for HTTP/2 over TLS.
• http/1.1 for HTTP/1.1.
• Other protocol identifiers for specialized systems.

If the client does not offer h2, the server cannot select it. If the server does not select h2, the connection will not use HTTP/2 even if the server supports HTTP/2 elsewhere.

Common symptoms

ALPN failures appear as:

• Browser uses HTTP/1.1 instead of HTTP/2.
• gRPC connection fails.
• CDN works but origin does not.
• Reverse proxy downgrades protocol.
• Load balancer terminates TLS and forwards HTTP/1.1.
• Mobile app says protocol error.
• Server metrics show no h2 traffic.
• HTTP/2 works with one hostname but not another.

These symptoms often get debugged at the HTTP layer, but the answer may be in TLS negotiation.

ClientHello evidence

The ClientHello can show whether the client offered ALPN and which protocols it advertised.

Useful questions:

• Is the ALPN extension present?
• Does the offer include h2?
• Does it also include http/1.1?
• Is SNI present and correct?
• Which TLS version is offered?
• Is the capture taken before a proxy terminates TLS?

If h2 is absent from ClientHello, the server cannot choose HTTP/2. The reason may be client library configuration, old TLS stack, disabled HTTP/2 option, or a proxy client that opens a new upstream connection.

ServerHello evidence

The server side should select one protocol from the client's ALPN list.

Problems:

• Server selects only http/1.1.
• Server omits ALPN response.
• Server handshake fails before ALPN selection.
• Certificate or SNI mismatch routes to a default virtual host.
• TLS terminator supports h2 on public side but not upstream side.

Packet evidence can separate server support from routing and proxy behavior.

SNI and ALPN together

SNI and ALPN are often connected. The hostname selected by SNI may determine which certificate, virtual host, and protocol settings apply.

Example failure:

• Client offers h2.
• Client sends wrong SNI.
• Server returns default certificate.
• Default virtual host does not enable HTTP/2.
• Connection falls back to http/1.1.

In this case the problem is not "HTTP/2 broken globally". It is hostname routing.

Proxy and load balancer termination

Modern deployments often split TLS:

client -> CDN or load balancer -> reverse proxy -> origin

Each segment may have different ALPN behavior. The public side may negotiate HTTP/2 while the upstream side uses HTTP/1.1. Or the reverse proxy may accept h2 from clients but downgrade to HTTP/1.1 when talking to the application.

When analyzing a pcap, identify which segment you captured. A trace on the origin server may not show the public client handshake at all.

gRPC and ALPN

gRPC usually requires HTTP/2. If ALPN does not negotiate h2, gRPC clients may fail with protocol errors, unavailable errors, or connection reset messages.

For gRPC troubleshooting, preserve:

• DNS answer.
• TCP handshake.
• TLS ClientHello.
• TLS ServerHello.
• ALPN protocol selected.
• Any TLS alert.
• First HTTP/2 frames if decrypted or visible through logs.

Even without decrypting payload, ALPN can prove whether HTTP/2 was negotiated.

Fallback is not always failure

HTTP clients may intentionally fall back to HTTP/1.1 when:

• Server does not advertise h2.
• Client policy disables HTTP/2.
• TLS version or cipher constraints are incompatible.
• Proxy strips or terminates the connection.
• ALPN extension is missing.
• A middlebox interferes with handshake.

The diagnostic question is whether fallback was expected for that route.

Debug checklist

Use this workflow:

1. Capture from TCP handshake through TLS handshake.
2. Confirm SNI hostname.
3. Check ClientHello ALPN list.
4. Confirm whether h2 is offered.
5. Check ServerHello selected ALPN.
6. Compare certificate with SNI.
7. Identify CDN, proxy, or load balancer termination.
8. Compare public-side and origin-side captures if needed.
9. Check whether the client library enables HTTP/2.
10. Preserve the handshake when trimming the pcap.

Final diagnosis

TLS ALPN and HTTP/2 issues should be diagnosed from handshake evidence. The key facts are whether the client offered h2, whether the server selected it, whether SNI routed to the right virtual host, and whether a proxy changed protocol between network segments.

PCAP Surgery helps keep the exact handshake packets needed to prove HTTP/2 negotiation, fallback, or proxy termination behavior.