How to Test ALPN and HTTP Version Negotiation Through a Proxy

An HTTPS request can return the correct page even when the transport behavior differs from the direct path. A client that normally negotiates HTTP/2 may use HTTP/1.1 through one proxy gateway, while another route may fail during tunnel setup or reuse connections incorrectly. That difference affects concurrency, header compression, latency and error handling even though a basic status check passes.

This guide provides a controlled ALPN and HTTP-version audit for proxy buyers and operators. Use only endpoints you own or are authorized to test. The goal is compatibility evidence, not forcing a destination to accept an unsupported protocol.

What ALPN tells you

Application-Layer Protocol Negotiation is part of the TLS handshake. It lets a client and server agree on an application protocol such as HTTP/2 or HTTP/1.1. With an HTTP CONNECT proxy, the client normally establishes a tunnel first and then negotiates TLS with the destination inside that tunnel. A SOCKS5 route adds its own address and DNS choices before destination TLS begins.

Record three distinct outcomes:

• the protocol the client offered;
• the protocol the destination selected;
• the HTTP version the application actually used.

Do not infer all three from a response header. Capture client-side connection evidence and corroborate it at an authorized origin.

Create the direct baseline

Choose an HTTPS fixture under your control that supports both HTTP/2 and HTTP/1.1. From the same machine, runtime and trust store that will run the proxy test, make repeated direct requests. Record:

test_id
route_alias
client_runtime
address_family
offered_alpn
selected_alpn
effective_http_version
tls_version
connection_reused
time_to_first_byte_ms
failure_phase

Keep credentials, proxy passwords, cookies and authorization headers out of logs. Use a random challenge in the response to prove that an old cache entry was not mistaken for a fresh protocol test.

Build a route matrix

Run the same small request several times in each cell. Keep destination, payload, client version, cipher policy, timeout and network location stable. The multi-region routing test helps keep geographic comparisons structured.

Step 1: prove tunnel establishment separately

For HTTP CONNECT, distinguish proxy authentication, tunnel creation, TLS handshake and application response. A 407 response is a proxy-authentication failure. A CONNECT timeout is not an ALPN failure. A TLS alert after the tunnel exists belongs to the destination handshake phase.

This separation prevents a common mistake: labeling every failed HTTP/2 request as “the proxy does not support HTTP/2” when the connection never reached destination TLS.

Step 2: compare negotiated and effective protocols

Start with the client offering HTTP/2 and HTTP/1.1. Compare direct and proxy results. Then force HTTP/1.1 as a control. Classify results as:

• expected selection: proxy and direct paths choose a protocol allowed by the fixture;
• consistent fallback: the proxy path always reaches the origin but selects HTTP/1.1;
• intermittent downgrade: selection changes across equivalent samples;
• false report: the client reports HTTP/2 while the origin observes another version;
• handshake failure: TLS ends before a protocol is selected.

A fallback is not automatically a defect. It becomes a purchasing concern when the product promises HTTP/2, the change is undocumented, or the application depends on multiplexing.

Step 3: test connection reuse without confusing sessions

Send a small sequence over one client connection and confirm whether requests share the intended connection. For HTTP/2, observe stream concurrency and connection identity. For HTTP/1.1, distinguish keep-alive reuse from parallel sockets.

Repeat with a new proxy session identifier. A rotating exit does not necessarily require a new gateway connection, but route policy must be explicit. If sticky behavior matters, combine this audit with the session stickiness test.

Do not maximize concurrency yet. First prove protocol correctness at low load; then use the concurrency saturation test to find capacity limits.

Step 4: test controlled failure cases

Use an authorized fixture to produce:

1. no overlap between offered and supported protocols;
2. a delayed TLS handshake;
3. a connection closed after tunnel establishment;
4. a valid HTTP/1.1-only origin;
5. a normal HTTP/2 origin with one intentionally reset stream.

The client should preserve the failure phase. Retry policy should not transform a deterministic negotiation failure into a retry storm. Record whether a retry uses a new tunnel, a new TLS session or the same connection.

Interpret differences carefully

Before attributing a downgrade to the proxy, verify the destination did not change its protocol policy, the direct and proxy tests resolved the same authorized host, and the client did not use different TLS libraries or configuration. Check whether IPv4 and IPv6 reach different edges. Compare multiple gateways and repeat from a second controlled network.

The useful finding is reproducible and route-specific. One unexplained sample is a reason to investigate, not a final verdict.

Procurement scorecard

Set hard gates first:

• no false protocol reporting;
• no silent verification bypass;
• failures retain a diagnosable phase;
• promised HTTP/2 behavior is reproducible;
• connection reuse follows documented session policy.

Then score selection consistency, time to first byte, success rate, connection reuse, regional coverage and support response. Calculate cost per successful request separately for HTTP/2 and HTTP/1.1 workloads; a single blended average can conceal an expensive fallback route.

Release checklist

• Direct baseline is current and repeatable.
• Every purchased gateway and region is represented.
• CONNECT, TLS and HTTP failures are separated.
• Offered ALPN, selected ALPN and effective HTTP version are all recorded.
• IPv4 and IPv6 results are not blended.
• Fresh and reused connections are tested independently.
• Retries are bounded and preserve the original failure.
• No credentials or cookies appear in evidence.
• A compatible fallback route has been tested.

FAQ

Does an HTTP proxy need to speak HTTP/2 to the client?

Not necessarily. With CONNECT, the proxy establishes a tunnel and the client negotiates destination TLS inside it. The proxy control connection and the tunneled application protocol are separate questions.

Is HTTP/1.1 fallback always bad?

No. It can be a valid compatibility path. Measure whether it changes latency, concurrency, connection count or cost enough to violate your workload requirements.

Can one successful request prove HTTP/2 support?

No. Repeat across gateways, address families and fresh connections, then test reuse and controlled stream failures.

Should browsers and command-line clients be tested separately?

Yes. They may use different TLS stacks, protocol policies, connection pools and proxy configuration paths.

Compliance note

Run protocol tests only against systems and routes you control or have explicit permission to assess. Respect contract terms, destination policy, rate limits and privacy requirements. Do not use negotiation testing to bypass access controls, and never expose proxy credentials or user data in logs.