curl 8.22.0 shipped on September 2 with two proxy-relevant fixes: an HTTP/3 proxy path no longer dereferences a null pointer when a non-status response header arrives before :status, and CONNECT trailer handling was corrected.
If you operate proxy-backed jobs, the useful lesson is not “turn on more retries.” It is that your test suite needs to distinguish a client parser failure from a gateway failure, exit failure, and destination response.
How a client bug becomes fake proxy churn
Imagine a worker crashes while parsing an unusual HTTP/3 proxy response. The scheduler sees an incomplete job, selects a different exit, and retries. The same client hits the same condition and crashes again.
Your dashboard now shows several failed exits, but the exit was never the independent variable. Rotation multiplied the symptom.
CONNECT framing errors can produce a quieter version of the same mistake: a tunnel is labelled unavailable even though authentication and routing completed. That can degrade a healthy gateway cohort and increase cost per successful request.
A compact paired test
Run the old and new curl builds against the same authorized fixture. Hold the gateway, credentials, protocol backend, target, concurrency, timeouts, and rotation policy constant.
Include six cases:
- Normal HTTP/1.1 CONNECT.
- Your supported HTTP/2 proxy path.
- HTTP/3 proxy handling in a controlled fixture.
- A controlled CONNECT response with trailers.
- Invalid proxy credentials as a negative control.
- An unreachable gateway to prove fail-closed behavior.
For each run, capture the curl version and linked backend, negotiated protocol, sanitized gateway cohort, curl error code, process exit or crash signal, tunnel outcome, total latency, retry count, and application-level validity.
Do not store proxy credentials, cookies, authorization headers, or unnecessary payloads in the artifact.
Classify at the first failure boundary
- Process crash: quarantine the client build or test condition. Do not rotate exits.
- Protocol parser error: preserve a sanitized diagnostic and reproduce against a controlled server.
- 407 or explicit proxy denial: inspect authentication and gateway policy.
- Tunnel timeout: inspect gateway reachability, TLS to the proxy, and timeout phase.
- 403/429 from the destination: respect the response; do not treat rotation as a fix.
- 200 with invalid content: transport succeeded. Validate locale, redirect, cache, and schema separately.
This one change in taxonomy prevents a client problem from corrupting pool-health data.
Canary metrics that matter
Start with one worker or no more than one percent of eligible traffic. Compare old and new builds by protocol and gateway cohort:
- crashes per 10,000 attempts;
- successful tunnels per attempt;
- retries per valid result;
- unique exits consumed per valid result;
- p50/p95 connection time;
- categorized curl errors;
- application-valid responses per attempt.
Roll back if crash rate is nonzero, direct fallback appears, authentication errors rise unexpectedly, or cost per valid result worsens materially. Adding retries is not a rollback plan.
One important limit
A curl fix does not prove your proxy provider supports HTTP/3. Support still depends on how curl was built, the HTTP/3 backend, the proxy service, and the network path. Keep malformed-response tests inside infrastructure you control or are authorized to test.
I work with 98IP, a proxy service. I am sharing this because client-side failures are routinely mislabelled as “bad proxies,” which makes both reliability and cost analysis worse. For product details: https://en.98ip.com/?k=dev
Use proxies only where authorized. Follow destination terms, rate limits, robots guidance, privacy rules, and data-minimization requirements. Do not use retries or rotation to evade access controls.
Official basis: curl project, “Changes in 8.22.0,” September 2, 2026.
``
Top comments (0)