curl 8.22 Treats a Proxy Port Change as a New Proxy

curl 8.22 changes an important detail for applications that reuse a curl easy handle: changing CURLOPT_PROXYPORT is now treated as changing the proxy itself. Proxy-specific cached state is reset before the next transfer.

That is the safer model. A hostname may stay constant while its ports lead to different products, regions, authentication realms, upstream pools, or policy boundaries. Treating a port change as a minor edit can let assumptions from gateway A influence gateway B.

What changed

Earlier versions already reset relevant state when the proxy hostname changed. curl 8.22 applies the same boundary when only the proxy port changes. The upstream implementation routes both changes through a shared proxy-change path and includes a regression test for the behavior.

For operators, the practical rule is simple: proxy.example on port A and the same hostname on port B should be tested as two distinct proxy endpoints.

Why a port-only change happens in production

Port changes are common in proxy integrations:

• separate ports select sticky and rotating sessions;
• a provider exposes country or product pools through different ports;
• blue/green gateways share one DNS name;
• an application fails over to a secondary listener;
• credentials or authentication policy differ by listener;
• a control plane rewrites the selected endpoint without rebuilding the client.

The change may look small in configuration, but the security and routing meaning can be large.

Option state is not connection state

Updating an easy-handle option does not prove that the next request used the intended route. Connection reuse, multiplexing, DNS cache, shared handles, proxy authentication, and retry logic can all affect observed behavior.

Your test therefore needs two layers:

1. Configuration evidence: record the intended host, port, proxy type, session policy, and request identifier.
2. Transport evidence: verify which controlled listener received the request, whether a fresh connection was used, and whether authentication was negotiated for that listener.

Do not use the response body alone as proof of route selection.

Build a two-port regression fixture

Use two proxy listeners you control. Give each one a unique server-side marker and separate authentication realm. Do not place secrets in logs or command history.

Run this sequence with the same easy handle:

1. Configure listener A and make a successful request.
2. Change only CURLOPT_PROXYPORT to listener B.
3. Make a second request and confirm that B received it.
4. Change the port back to A and repeat.
5. Run the sequence with connection reuse enabled and again with reuse disabled.
6. Repeat with the same share and multi-handle topology used in production.

The key assertion is not merely that requests succeed. It is that each listener receives only its intended traffic and performs its own authentication flow.

Capture evidence that can diagnose a failure

For every attempt, record:

• application request ID and test case ID;
• curl version and build features;
• intended proxy hostname and port;
• selected proxy mode and session policy;
• fresh or reused connection status;
• HTTP status and curl result code;
• listener marker observed on the controlled side;
• retry count and final route decision.

Redact usernames, passwords, tokens, session identifiers, and full proxy URLs. Aggregate logs should answer whether state crossed a port boundary without exposing credentials.

Test authentication without leaking secrets

Use distinct test credentials or realms for A and B. A credential accepted by A should not silently appear as authenticated state on B. Include negative cases:

• B rejects A's test credential;
• a 407 Proxy Authentication Required response is handled as an authentication failure;
• retries do not fall back to a direct connection;
• the application does not rotate endlessly after a policy error;
• logs contain redacted endpoint labels, not raw credentials.

If you are troubleshooting a 407 response, use the structured checks in Proxy Authentication 407 Troubleshooting.

Upgrade acceptance checklist

• Inventory every code path that changes CURLOPT_PROXYPORT on a reused handle.
• Test A → B → A with controlled listeners.
• Cover fresh connections, reused connections, multi handles, and share handles.
• Verify listener-specific authentication and routing evidence.
• Confirm retries are bounded and remain on approved proxy routes.
• Confirm direct fallback is disabled unless explicitly allowed.
• Scrub credentials and session tokens from logs.
• Compare error rate, 407 rate, latency, and connection reuse before and after rollout.
• Roll out gradually and keep a tested rollback procedure.

For broader preparation, see Proxy Credential Rotation, Proxy Bypass Audit, and Proxy Failover Recovery Drill.

FAQ

Does a new port always mean a different proxy server?

Not necessarily at the infrastructure layer, but applications should treat it as a distinct endpoint boundary unless the operator has proven otherwise.

Is a successful request enough to validate the upgrade?

No. Success can hide wrong-route reuse or unintended authentication behavior. Validate the receiving listener and connection lifecycle.

Should every request use a new easy handle?

No. Handle reuse is valid and often efficient. The test should mirror your real lifecycle and verify that endpoint changes reset the right state.

What should happen if the new proxy port fails authentication?

Fail closed, report the 407 clearly, apply a bounded retry policy, and never silently bypass the proxy.

Source note and compliance

This news analysis is based on the curl 8.22 change log published September 2, 2026, and curl project change set 21485 merged May 3, 2026. Source addresses are retained only in the internal operations record.

Use proxies only for systems and data you are authorized to access. Respect contracts, privacy requirements, rate limits, robots directives where applicable, and regional law. This article does not recommend bypassing access controls or platform safeguards.