curl's work-in-progress notes for 8.22.0 list a fix for hostname use with a non-tunneling HTTP proxy. The planned public release date is September 2, 2026, so this is an engineering preview rather than a statement about released behavior.
The useful action today is not to install a development snapshot everywhere. It is to build a reproducible test that distinguishes proxy modes, destination selection, and connection reuse.
Why a hostname fix can be operationally significant
For a plain HTTP request through a forward proxy, the client typically sends an absolute request target. The proxy then resolves and connects to the upstream host. For HTTPS, curl commonly establishes a CONNECT tunnel first.
That difference changes where hostname decisions happen. It can also change:
- the request target seen by the proxy;
- the Host header;
- DNS responsibility;
- authentication scope;
- connection-pool keys;
- redirect behavior.
A single 200 OK smoke test cannot cover these interactions.
Build a small compatibility harness
Create a matrix with two curl builds: your current approved version and, only in an isolated environment, the candidate version after it is officially available. Use two destination hostnames and test direct, non-tunneled HTTP proxy, and HTTPS CONNECT paths.
For each case, record:
client_version
proxy_mode
target_hostname
proxy_endpoint
response_status
remote_endpoint
connection_reused
elapsed_ms
Do not log proxy passwords, authorization headers, cookies, or personal data.
Exercise reuse, not just first connections
Run a sequence such as host A, host A again, host B, and host A again. If your application maintains a pool, test through the same library and pool configuration used in production. A CLI-only test may miss application-level reuse behavior.
Compare client-side traces with sanitized proxy logs. Confirm that each request reaches the intended virtual host, that authentication remains scoped correctly, and that redirects do not move a pooled connection into an invalid state.
Define a rollout gate
An upgrade passes only if the candidate stays within explicit thresholds. Useful gates include zero unexpected host routing, no new authentication failures, stable status-code distribution, and latency within the accepted range.
Roll out to a small canary first. Keep the previous build ready for rollback. After September 2, verify the published release notes because pending entries can change before release.
Retain the sanitized test results as a baseline for later upgrades.
Avoid three premature conclusions
- Pending notes do not mean the release has shipped.
- A bugfix entry does not mean every earlier version fails.
- A hostname symptom does not automatically identify the proxy provider as the cause.
Disclosure: I work with 98IP, a proxy infrastructure provider. This tutorial describes a neutral validation process and does not claim that curl's pending implementation is final. Additional proxy engineering guides: https://en.98ip.com/?k=dev
Use proxy infrastructure only for authorized, lawful work. Respect rate limits, privacy requirements, data-protection obligations, and site terms.
