curl 8.22 Restores Connection Limits for Shared Pools: A Proxy Client Upgrade Test

curl 8.22.0, released on 2 September 2026, includes a connection-cache fix described as applying multi-handle limits to transfers that use a shared pool. The underlying report concerns CURLMOPT_MAX_HOST_CONNECTIONS and CURLMOPT_MAX_TOTAL_CONNECTIONS when easy handles share connections through CURL_LOCK_DATA_CONNECT.

The report states that affected limits could be silently unenforced in curl 8.13.0 through 8.21.0 for this specific architecture. That does not mean every curl user exceeded connection caps. Applications must combine a multi handle, configured limits and a share-owned connection pool. Still, high-concurrency proxy clients should treat the 8.22 upgrade as a capacity-control change, not only a routine patch.

Why proxy teams should care

Connection caps protect more than the destination. They limit open sockets to proxy gateways, bound file-descriptor and ephemeral-port use, control authentication bursts, and prevent one host from consuming the entire worker budget.

If a configured cap is not applied, symptoms may include:

• more simultaneous connections than the operator intended;
• unexpected 407 authentication bursts at the proxy;
• destination throttling or proxy-side rate limits;
• source-port pressure and rising connection failures;
• poor fairness between destinations or tenant workloads;
• a sudden change in throughput and cost after an upgrade.

Do not infer this bug from traffic volume alone. Measure actual active connections and reproduce the exact share-handle design.

Identify the affected architecture

Inventory applications that use libcurl's multi interface. For each process, record whether easy handles share connection data, which multi limits are set, whether multiple multi handles use the same share handle, and which proxy gateways or destinations receive most traffic.

Pay special attention to frameworks that hide libcurl configuration behind an HTTP client, worker pool or SDK. Record the loaded libcurl version at runtime; the command-line curl version on the host may be different.

Never place proxy passwords or session tokens in the inventory. Record secret references and authentication method, not values.

Build a two-dimensional limit test

Use an authorized proxy and a controlled destination. Configure a low, observable per-host limit and a separate total limit. Generate enough parallel transfers to exceed both.

Test at least four shapes:

1. one destination through one proxy gateway;
2. several destinations through one proxy gateway;
3. one destination through several proxy endpoints;
4. several multi handles using the same shared connection pool.

For each shape, measure active connections, queued transfers, completed requests per second, p50 and p95 latency, proxy authentication attempts, error codes, socket count and observed exit routes. The expected result is not simply “all requests succeeded.” The measured peak must remain within the intended cap, while excess work queues and later completes.

Compare versions under identical load

Capture a baseline with the currently approved build, then run the same test with curl 8.22.0 in a canary environment. Keep proxy route, destination, concurrency, timeouts, connection reuse, DNS mode and request payload fixed.

If the older affected build opened more connections than configured, the corrected version may show lower instantaneous throughput and more queueing. That is expected evidence of the cap being enforced, not necessarily a regression. Judge the result against the intended resource and service-level budget.

Also compare a control with connection sharing disabled. This helps confirm whether the observed difference belongs to the shared-pool path rather than the proxy, destination or load generator.

Test failure and recovery behavior

Limit enforcement must remain stable when connections fail. Restart the controlled proxy, expire idle connections, inject a bounded timeout and rotate one proxy endpoint. Verify that dead connections leave the pool, queued work resumes, and replacement connections still respect both caps.

Ensure a failed proxy never triggers silent direct access. Use the proxy failover drill and ephemeral-port diagnosis guide to distinguish a connection-limit change from recovery or local networking problems.

Roll out with capacity evidence

Start with a small worker cohort. Track active proxy connections, queue age, successful throughput, tail latency, authentication rate, retry amplification and cost per validated result. Increase the cohort only when the cap is respected and the queue drains within the workload objective.

Do not compensate for new queueing by immediately raising limits. First confirm that the previous setting reflected the provider agreement, destination rules, local socket budget and intended fairness. Use the proxy concurrency ramp test before changing production capacity.

Upgrade checklist

• [ ] Runtime libcurl versions are recorded for every client.
• [ ] Multi handles and share handles using CURL_LOCK_DATA_CONNECT are inventoried.
• [ ] Per-host and total connection settings have explicit owners.
• [ ] Test load exceeds both configured limits.
• [ ] Active connections and queued transfers are measured directly.
• [ ] Shared and non-shared control cases are compared.
• [ ] Proxy authentication, retries and exit routes are verified.
• [ ] Failure recovery continues to respect both caps.
• [ ] Direct fallback is disabled and tested.
• [ ] Canary and rollback thresholds are documented.

FAQ

Does this affect the curl command-line tool by default?

The reported case requires a libcurl application using multi-handle limits with a shared connection pool. A simple standalone command does not automatically match that design.

Will curl 8.22 make my workload slower?

It can change instantaneous concurrency if an older affected build exceeded the configured cap. More queueing may be correct behavior. Evaluate successful throughput, queue time and resource safety together.

Should I raise the cap after upgrading?

Only after an authorized capacity test. A cap may protect proxy contracts, destination limits, local ports and workload fairness. Do not restore old throughput by recreating uncontrolled concurrency.

Compliance note

Run load tests only against proxy accounts and destinations you own or are authorized to test. Respect provider concurrency limits, destination policies, privacy obligations and rate limits. Use synthetic traffic where possible and do not use connection sharing to evade access controls.

Research note: curl project, “Changes in 8.22.0,” released 2 September 2026; curl issue “CURLMOPT_MAX_HOST_CONNECTIONS is ignored with CURL_LOCK_DATA_CONNECT,” opened 4 July 2026 and closed before the release. External research locations are stored only in the internal operations record.