SNI vs ALPN: TLS Handshake Analysis and HTTP/2 Negotiation in Wireshark PCAPs

An endpoint advertised as HTTP/2-capable may still serve HTTP/1.1 when the TLS ALPN exchange does not select h2. Preserve the ClientHello to see what the client offered, identify the ServerHello-selected protocol where visible, and note any proxy that terminates TLS before the origin. That handshake evidence can distinguish client omission, server fallback, and a changed TLS boundary; it cannot show encrypted application protocol details without keys.

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.

Build a handshake evidence table

Start at the TCP three-way handshake and preserve the ClientHello, the first server handshake record, any TLS alert, and connection close. Record the capture point as carefully as the packets: client device, CDN edge, load balancer, reverse proxy, or origin. A correct ALPN result at an edge does not describe a separate TLS connection from a proxy to an origin.

Handshake field	What to record	Interpretation boundary
Destination and TCP peer	IP, port, DNS answer, capture location	Identifies which TLS leg was observed
SNI	Offered hostname or absence	Determines virtual-host routing request
Client ALPN list	Exact ordered identifiers such as h2, http/1.1	Shows what the server could select
Server ALPN selection	Selected identifier or omission	Establishes the negotiated protocol on this leg
Certificate/alert	Name, issuer evidence, alert code if visible	Separates route/certificate failure from HTTP fallback
First application behavior	HTTP/2 preface only when decryptable, logs otherwise	Avoids claiming encrypted payload details from handshake alone

Use PCAP Surgery capture scope guidance before collecting a production trace. Retain enough pre-handshake DNS and TCP context to show which endpoint was contacted, then create a redacted failure window rather than sharing a broad packet dump.

Compare the same hostname through each TLS boundary

Run a controlled comparison with the same hostname and client policy. One capture at the public client side may show h2, while the origin-side capture correctly shows a new connection using http/1.1; that is normal for many reverse-proxy designs. The failure exists only if the observed leg contradicts the intended architecture or an application requirement such as gRPC.

Comparison	Evidence to align	Conclusion it supports
Working hostname versus failing hostname	SNI, ALPN offer, certificate, selected protocol	Virtual-host or certificate policy difference
Browser versus application client	ClientHello ALPN list and TLS version	Client library/configuration omission
Public edge versus origin-side trace	Peer address and distinct handshake IDs	Where TLS terminates and protocol changes
HTTP/2-enabled policy versus fallback policy	Server selection and first request behavior	Intentional versus unexpected fallback
Before/after proxy configuration	Same capture point and hostname	A real configuration-driven change

Do not call http/1.1 a failure by itself. A website can deliberately terminate HTTP/2 at a CDN and forward HTTP/1.1 upstream. For gRPC, however, a missing h2 selection is a material signal because the client generally needs HTTP/2 on its own connection.

Diagnose SNI and ALPN as separate questions

SNI asks “which name is this connection for?” ALPN asks “which application protocol did the peers choose?” They interact when a server's per-name virtual-host configuration enables different certificates or HTTP/2 settings, but changing the SNI should not be used as a blind workaround. Compare expected and observed names first.

Pattern in PCAP	Most likely boundary	Next verification
h2 absent from ClientHello	Client library, proxy client, or HTTP/2 policy	Inspect client configuration and a known-good client
h2 offered; server selects http/1.1	Server/edge virtual-host policy	Compare SNI and server configuration for that hostname
Wrong SNI and default certificate	DNS/URL/proxy route selection	Verify hostname mapping before TLS tuning
Handshake alert before selection	TLS/certificate/cipher problem	Preserve alert and handshake parameters
Edge selects h2; origin trace uses HTTP/1.1	Expected proxy termination unless design says otherwise	Document the intended boundary

When a slow request follows successful ALPN, move to application timing rather than re-litigating the handshake; HTTP slow request and TTFB PCAP analysis is a separate diagnosis. When a proxy response is an error, use HTTP 502 vs 504 gateway timeout PCAP analysis with the same capture-boundary discipline.

FAQ: TLS ALPN and HTTP/2 negotiation

Can Wireshark prove that HTTP/2 was used without TLS keys?

It can often prove the ALPN offer and server selection in visible handshake metadata. It cannot reveal encrypted application frames or request semantics without authorized decryption or independent server evidence.

Why does a browser use HTTP/2 while a service client falls back?

The clients may offer different ALPN lists, TLS versions, SNI values, or proxy paths. Compare the two ClientHello messages before changing the server.

Does an omitted server ALPN extension always mean a broken server?

Not always. It means no visible application protocol was selected on that observed TLS connection. Whether that violates the deployment depends on the intended client and protocol requirement.

Produce a reviewable PCAP verdict

The useful handoff states the capture leg, DNS peer, SNI, client ALPN offer, server selection, certificate/alert observation, and expected policy. For example: “At the public edge, the client offered h2,http/1.1 with SNI api.example; the server selected http/1.1 for that name, while the control hostname selected h2.” Open PCAP Surgery with the retained handshake window and preserve timestamp evidence if the cross-boundary timeline is disputed.

What belongs in an ALPN A/B test?

Use the same client build against the affected hostname and a known-working hostname or edge policy. Record DNS answer, destination, TLS version, SNI, ordered ALPN offer, server selection, certificate identity, alert, handshake completion, and the first application bytes. If a proxy terminates TLS, capture or obtain evidence on both legs and never infer the origin negotiation from the public leg alone.

The acceptance statement should name the policy that changed and show the resulting selection. A client offering h2 does not prove the server selected it; an HTTP/2-looking symptom does not prove ALPN caused it. Preserve the capture scope and unmodified handshake windows for independent review.

If the A/B run changes the route, proxy, certificate policy, or connection-reuse state as well as ALPN, label it inconclusive and repeat it. Those variables can create the same visible result while answering a different question.

Name the owner of the next unobserved TLS leg in the final report.

<!-- multilingual-related-reading:start -->

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:

• HTTP/2 GOAWAY and RSTSTREAM PCAP Analysis: Debugging Reset Streams, Proxy Limits, and gRPC Failures
• Asymmetric Routing and One-Sided PCAP Analysis
• HTTP Slow Request and TTFB in PCAP: Proving Whether the Delay Is DNS, TCP, TLS, or Server Time

<!-- multilingual-related-reading:end -->