curl 8.22 Preview: A Non-Tunneling Proxy Hostname Fix Is in Progress

curl's pending release notes now list a fix for hostname handling when HTTP traffic uses a non-tunneling proxy. The entry belongs to the work-in-progress notes for curl 8.22.0, whose public release is planned for September 2, 2026. It is not a released behavior yet, and the notes can change before publication.

For teams that run data collection, market research, ad verification, or other approved automation through forward proxies, this is a useful signal to review tests around hostname routing. A small client-side interpretation difference can produce failures that look like proxy instability even when the proxy service itself is healthy.

What “non-tunneling proxy” means

With a tunneling proxy, the client commonly opens a CONNECT tunnel and then communicates with the destination through that tunnel. With a non-tunneling HTTP proxy, the proxy receives an absolute request target and performs the upstream connection on the client's behalf.

That distinction affects which hostname appears in the request line, which host the proxy resolves, how connection reuse is keyed, and what operators see in logs. A mismatch can surface as requests reaching the wrong virtual host, unexpected name resolution, inconsistent reuse, or failures that disappear when switching to a tunnel.

Why teams should care before upgrading

The pending fix does not mean every proxy deployment is affected. It does mean upgrade testing should cover more than a single successful request. Applications often combine environment proxy variables, per-request overrides, connection pools, redirects, authentication, and multiple destination hostnames. A change in hostname use can interact with any of those layers.

The safest approach is to treat curl 8.22.0 as a compatibility event until the final notes and binaries are public. Keep production on the approved version, reproduce representative traffic in staging, and compare behavior rather than assuming the new version is automatically better for every workflow.

A practical validation plan

1. Record the current baseline

Capture the curl and libcurl versions, proxy mode, target hostname, resolved destination, response status, latency, and connection-reuse behavior. Save enough context to distinguish a client regression from a proxy, DNS, or origin failure.

2. Test tunneled and non-tunneled paths separately

Do not treat them as interchangeable. Run a small matrix that includes plain HTTP through a forward proxy, HTTPS through CONNECT, redirects, and at least two distinct destination hostnames. This makes hostname-specific differences visible.

3. Include pooled connections

A one-request smoke test can miss reuse bugs. Send several sequential requests, alternate target hosts, and observe whether the connection pool associates each request with the intended destination.

4. Verify what the proxy actually received

Compare client traces with proxy-side logs. Check the request target, Host header, selected upstream host, authentication result, and final response. Redact credentials and user data before storing traces.

5. Define rollback criteria

Choose measurable thresholds before rollout: unexpected host routing, a material error-rate increase, authentication regressions, or a latency shift. Keep the previous curl build available until the canary passes.

What not to conclude from the preview

The pending note is not proof that curl 8.22.0 has shipped, that every earlier version is unsafe, or that a proxy provider is responsible for current failures. It is an early engineering signal. The exact final scope should be confirmed against the published release notes after September 2.

Release-readiness checklist

• Confirm the final curl 8.22.0 release and notes before production rollout.
• Inventory applications that use non-tunneling HTTP proxies.
• Test direct, tunneled, and non-tunneled paths independently.
• Compare first-request and reused-connection behavior.
• Inspect both client traces and proxy-side logs.
• Protect credentials and personal data in diagnostics.
• Roll out by canary and preserve a tested rollback path.

FAQ

Should we install a development snapshot in production?

No. Development snapshots are useful for controlled testing, not general production deployment. Wait for the public release and your normal package or vendor approval process.

Does this affect residential proxy rotation?

The note is about hostname use in non-tunneling proxy handling, not rotation policy itself. However, applications that combine rotation with connection reuse should include both in staging tests.

Is changing proxy providers the right first response?

Usually not. First isolate the client version, proxy mode, hostname, connection reuse, and origin behavior. Provider changes made before diagnosis can hide the original cause.

Source note: curl project, pending release notes for 8.22.0, reviewed August 19, 2026. The notes are work in progress and may change before release.

Use proxy infrastructure only for authorized, lawful activity. Respect site terms, privacy requirements, rate limits, and data-protection obligations. For related operational guidance, see the 98IP proxy guides at 98IP.