curl 8.22 Extends Connection-Age Checks to Multiplexed Reuse: Revalidate Proxy Pools

curl and libcurl 8.22.0, released September 2, 2026, includes a connection-reuse change that matters to long-running proxy clients. When a transfer has CURLOPT_MAXLIFETIME_CONN configured, libcurl now checks the age of a matching connection before reuse even if that connection is currently active and supports multiplexing. The project change record says aged matches are rejected and aged idle connections are closed.

The change was proposed on August 25 and closed on August 27 in the curl project. It is listed in the 8.22.0 release notes as “connection reuse: age check.” It is a behavior correction, not a new proxy rotation feature and not, by itself, a security advisory.

Why active multiplexed connections are different

With HTTP/2 or HTTP/3, several transfers may share one transport connection. A busy connection can remain continuously active while accepting new streams. A maximum-lifetime policy that is checked only when a connection is idle may therefore fail to create the intended retirement boundary for a heavily multiplexed connection.

After the 8.22 change, a connection older than the configured maximum lifetime should not be selected for an additional transfer merely because it is still serving other streams. Existing work is not described as being abruptly terminated by this selection check; the operational effect to validate is that new work moves to an eligible or newly established connection.

Do not confuse three lifetimes

Proxy operations often use “session lifetime” for different controls:

1. Transport connection lifetime: how long the client may reuse one TCP or QUIC connection. CURLOPT_MAXLIFETIME_CONN addresses this layer.
2. Proxy authentication or gateway session: state the proxy service associates with credentials, a connection or another provider-defined key.
3. Exit identity lifetime: how long an upstream IP or route remains stable under a sticky or rotating product policy.

Retiring a libcurl connection does not guarantee a different exit IP. Conversely, an exit may rotate while the client-facing connection remains open. Document and test each layer separately.

Who should review the change

Prioritize a regression test if the application:

• uses libcurl 8.21 or earlier and is moving to 8.22;
• sets CURLOPT_MAXLIFETIME_CONN to enforce connection retirement;
• uses HTTP/2 or HTTP/3 multiplexing;
• keeps proxy workers alive for long periods;
• shares connection caches or runs high concurrency;
• depends on connection-bound authentication or provider session rules;
• has strict limits on new connections, TLS handshakes or egress cost.

Applications that never set the option are not directly governed by its configured maximum. Still inventory defaults, wrappers and language bindings: a framework may set it without exposing the value in the application configuration.

Build an incumbent-versus-candidate canary

Use a deterministic endpoint you own or are explicitly authorized to test. Compare the exact incumbent build with 8.22 while holding these variables constant:

proxy_route_alias
requested_market
address_family
proxy_protocol
negotiated_http_version
session_mode
max_lifetime_seconds
concurrency
request_rate
response_size
test_duration

Run long enough for connections to cross the configured lifetime. A five-minute test cannot validate a 30-minute retirement policy. Use a small, deliberate lifetime in a non-production fixture to observe the transition quickly, then repeat with the intended production value.

Capture the retirement boundary

For every transfer, record sanitized evidence:

client_build
connection_id
connection_created_at
connection_age_at_selection_ms
stream_id_or_sequence
connection_reused
new_connection_opened
proxy_connect_ms
tls_ms
queue_ms
ttfb_ms
total_ms
first_attempt_result
response_digest_ok
observed_market
exit_alias
failure_phase

Do not log proxy credentials, cookies or personal data. An internal connection ID should be random and non-secret; an exit alias should be a controlled label if raw addresses are not required.

Plot connection age when each new transfer begins. For the candidate, no newly assigned transfer should select a connection beyond the configured maximum, allowing for the measurement precision and semantics documented by the client. Separately confirm that streams already running remain correct through the retirement transition.

Expect second-order capacity effects

A more effective lifetime boundary can change fleet behavior even when request correctness improves:

• Connection churn: more transport connections may be created per hour.
• TLS and proxy handshake cost: p95 latency and CPU may rise around retirement waves.
• Queueing: strict total or per-host connection limits can delay work while a replacement is created.
• Port and file-descriptor use: short lifetimes under high concurrency can increase resource pressure.
• Provider accounting: some plans or gateways may treat new connections differently from reused traffic.
• Session continuity: connection-bound state may reset even if the provider returns the same exit.

Stagger worker start times and add modest lifetime jitter in the application only if the application can do so without violating its policy. A fleet in which every process creates and retires connections on the same second can generate avoidable handshake bursts.

Test the interaction with pool limits

Record the configured per-host and total connection limits. At the retirement boundary, verify:

1. old connections stop receiving new transfers after the lifetime rule applies;
2. replacement connections do not exceed the intended pool limits;
3. queued requests remain bounded and observable;
4. no retry storm hides connection-creation failures;
5. first-attempt success and response integrity remain stable;
6. HTTP/1.1, HTTP/2 and HTTP/3 results are not mixed into one conclusion.

If the proxy path uses CONNECT, distinguish the connection to the proxy from the tunneled destination behavior in telemetry. A single client-to-proxy connection can have protocol-specific semantics, and wrappers may expose only part of the path.

Choose a lifetime from evidence

Do not lower the value simply to force frequent renewal. Choose it by balancing:

• observed idle and maximum connection behavior;
• proxy gateway and target timeouts;
• authentication and certificate policy;
• latency added by DNS, proxy connect and TLS;
• multiplexed stream duration;
• route and market stability;
• file-descriptor, port and bandwidth budgets;
• provider documentation and contract terms.

Compare cost per verified result before and after the upgrade. A policy that reduces stale-connection failures but doubles handshakes may still be correct, yet it needs a capacity adjustment rather than an unnoticed rollout.

Rollout checklist

• [ ] Confirm the exact runtime libcurl version and TLS/HTTP backends.
• [ ] Inventory where CURLOPT_MAXLIFETIME_CONN is set and its unit/value.
• [ ] Separate transport lifetime from provider session and exit-IP lifetime.
• [ ] Exercise at least one active multiplexed connection past the boundary.
• [ ] Verify new transfers avoid aged connections without corrupting active streams.
• [ ] Measure connection creation, handshakes, queues, retries and useful-result cost.
• [ ] Check total and per-host connection limits during replacement.
• [ ] Canary separately by protocol, market, address family and proxy product.
• [ ] Keep a tested rollback artifact and alert threshold.

FAQ

Does curl 8.22 terminate every connection at the exact lifetime?

The official change concerns checking the age of a matched connection before reuse, including an active multiplexed connection, and closing aged connections when idle. Validate the actual retirement timing and active-stream behavior in your selected backend rather than assuming a wall-clock kill.

Will this make a rotating proxy change IP?

Not necessarily. The option controls client transport connection reuse. Exit selection follows the proxy provider's product and session rules.

Should the maximum lifetime be shorter than the idle timeout?

They solve different problems. Idle limits retire unused connections; maximum lifetime limits reuse based on total age. Test both against the proxy gateway and workload instead of deriving one mechanically from the other.

Is this change a reason to skip upgrading?

No. It is a reason to canary. Upgrade decisions should include release provenance, relevant fixes, regression evidence, capacity impact and rollback readiness.

Related 98IP guides

• Test proxy idle timeouts and keep-alive reuse
• Find the safe proxy concurrency knee
• Audit HTTPS proxy TLS trust layers

Source note

Internal research is based on the curl project’s “curl 8.22.0” release announcement dated September 2, 2026, and “connection reuse: age check” project change record opened August 25 and closed August 27, 2026. Public source names and dates are provided as plain text to preserve 98IP’s zero-external-link policy.

Compliance note

Test only endpoints and proxy accounts you own or are authorized to use. Respect concurrency limits, access rules, privacy requirements and provider contracts. Do not shorten connection lifetimes or rotate routes to evade blocks or rate controls. Keep credentials and user data out of traces.