How to Audit HTTP/2 Proxy Connection Reuse Without Mixing Tenants

HTTP/2 can carry many concurrent streams over one persistent connection. With an HTTP/2 proxy, multiple requests may reuse the single connection to that proxy, while CONNECT establishes destination tunnels as individual streams. This improves latency and capacity, but it also makes the connection pool a security and correctness boundary.

A safe audit must prove that the client reuses only compatible connections, preserves destination authority, keeps tenant and authentication state isolated, and recovers correctly when a server returns 421 Misdirected Request or a connection drains with GOAWAY.

Map the connection identity

Record a sanitized identity for every physical connection and logical stream:

connection_id
stream_id
proxy_gateway_alias
proxy_protocol
proxy_auth_profile
destination_authority
tls_sni
certificate_profile
tenant_alias
cookie_jar_alias
client_identity_alias
ip_family
created_at
last_used_at
goaway_seen
response_class

Do not log proxy passwords, cookies, tokens, raw client certificates or customer identifiers. The objective is to prove separation, not capture secrets.

Define the allowed reuse key

Create a documented reuse key before testing. At minimum, consider proxy gateway, proxy protocol, proxy authentication profile, destination authority, TLS settings, client certificate, tenant, privacy mode and network namespace.

Do not key a pool only by proxy host and port. Two tenants can use the same gateway while requiring different credentials, cookies, destination policies or audit trails. Conversely, two streams for one authorized job can safely share a connection when every relevant property matches.

Separate three layers

Treat these layers independently:

A single proxy connection does not imply a single destination connection. Likewise, a successful CONNECT does not prove that the origin request used the intended authority or session state.

Build a controlled multiplexing test

Use only proxies and test destinations you are authorized to operate. Create two tenant aliases and two controlled origins with distinguishable, harmless response markers.

1. Open an HTTP/2 connection to the approved proxy.
2. Start parallel streams for tenant A to origin A and tenant B to origin B.
3. Attach different proxy-auth and application-state aliases.
4. Confirm each origin sees only its expected non-secret marker.
5. Record whether streams shared the client-to-proxy connection.
6. Repeat with sequential requests after one stream completes.
7. Repeat after credential rotation, DNS change and idle time.
8. Confirm incompatible requests open a new connection or fail closed.

The pass condition is correct isolation under reuse, not maximum reuse. Unexpected state on the wrong origin is a hard failure even when every HTTP status is successful.

Validate authority and certificate rules

HTTP/2 connection reuse across origins is permitted only when the server is authoritative for the new origin. For HTTPS, the certificate must satisfy the checks that would apply to a new connection for that host.

Test that the client sends the correct :authority, TLS SNI and Host semantics. Never disable certificate or hostname verification to increase connection reuse. If infrastructure routes by SNI, a connection that is otherwise authoritative can still reach an unintended backend; controlled canaries must verify the response marker as well as the certificate.

Test 421 recovery

A server can return 421 Misdirected Request when it does not want a reused connection for that authority. The client should retry only the affected request on a suitable fresh connection, within a strict retry budget.

Verify that:

• the 421 response is not treated as a generic proxy-quality failure;
• unrelated streams are not replayed;
• request bodies are retried only when safely replayable;
• the retry uses the correct tenant and authentication context;
• the old connection is not immediately selected again for the same authority;
• retry count and final outcome are observable.

Do not rotate proxy exits automatically after a 421. The signal concerns request routing or authority on an existing connection, not residential IP reputation.

Test GOAWAY and partial completion

When a peer sends GOAWAY, some lower-numbered streams may have completed while newer streams may need recovery. Your client must know which requests are safe to retry.

Use idempotent laboratory requests first. Inject GOAWAY while multiple streams are active, then confirm that completed requests are not duplicated and unprocessed requests stay within the task retry budget. Non-idempotent operations require an application-specific idempotency key or manual recovery rule.

Check pool limits and fairness

One busy tenant must not occupy every stream or connection. Set and test limits for concurrent streams per connection, connections per gateway, queue wait time, task deadline and tenant share.

Measure useful results, queue latency, first-attempt success, 421 rate, GOAWAY recovery, new-connection rate and retry amplification. High reuse with rising tail latency or cross-tenant queueing is not a healthy optimization.

Production checklist

• [ ] The pool reuse key is documented and tested.
• [ ] Proxy credentials are part of the compatibility decision.
• [ ] Tenant and cookie-jar identities remain separate.
• [ ] Destination authority, SNI and certificate checks are preserved.
• [ ] CONNECT streams map to the expected destinations.
• [ ] Controlled response markers prove backend identity.
• [ ] 421 retries use a suitable fresh connection.
• [ ] GOAWAY does not duplicate completed work.
• [ ] Non-idempotent requests have explicit recovery rules.
• [ ] Per-tenant stream and queue limits prevent starvation.
• [ ] Connection age, idle time and active version are observable.
• [ ] Logs contain aliases rather than credentials or cookies.

Related 98IP guidance covers residential proxy session stickiness, proxy failover recovery drills, and proxy gateway DNS cache rollover.

FAQ

Does HTTP/2 multiplexing mean all destinations share one tunnel?

No. An HTTP/2 connection to a proxy can carry multiple streams, and each CONNECT stream identifies its own destination authority. Instrument both the physical connection and logical tunnel.

Should tenant identity always force a new connection?

That is the safest default when credentials or state differ. A shared connection is acceptable only after the implementation proves every security and policy property is isolated at stream level.

Is disabling reuse a permanent fix?

It can be a temporary diagnostic or containment measure, but it reduces performance and can increase connection load. Correct the reuse key and isolation controls, then re-enable reuse through a canary.

Should a 421 response trigger proxy rotation?

No. Retry the affected, safely replayable request on a suitable fresh connection. Treat proxy rotation as a separate, explicitly justified routing decision.

Compliance note

Use only authorized proxies and test origins. Respect destination terms, rate limits and privacy requirements. Isolate customer state, minimize logs, protect authentication material and never use connection reuse to bypass an origin's routing or access decision.

Source note: IETF, RFC 9113, “HTTP/2,” June 2022; curl project, “libcurl API overview” and “CURLOPT_FORBID_REUSE,” reviewed September 5, 2026.