curl 8.22 Fixes Proxy CONNECT Trailer Handling: What Tunnel Operators Should Test

curl 8.22.0 was released on 2 September 2026. Its official change log includes a narrowly described but operationally relevant fix: proxy: CONNECT trailers handling. Teams that route scraping, market research, ad verification or data-collection traffic through HTTP proxies should include this boundary case in upgrade testing.

An abstract internet gateway carries packets through a proxy tunnel into an observability console

This is not evidence that ordinary CONNECT tunnels were broadly broken. A trailer is an additional header field sent after a chunked message body, so the affected path requires a proxy response and framing that actually use trailers. The practical lesson is to test the proxy handshake as its own protocol exchange instead of treating a final destination response as the only proof of success.

Why CONNECT response boundaries matter

For an HTTPS destination through an HTTP proxy, the client first asks the proxy to open a tunnel. A successful CONNECT response ends the proxy's HTTP response; bytes after that boundary belong to the tunnel and are interpreted by the next protocol, commonly TLS.

Incorrect trailer handling can confuse three separate layers:

  1. the proxy's CONNECT response, including status, headers and any framed body;
  2. the transition from HTTP proxy parsing to an opaque tunnel;
  3. the destination protocol carried inside that tunnel.

When those layers are mixed, symptoms can appear as a receive error, truncated metadata, a TLS handshake failure or a retry storm. That is why an upgrade check should record both the proxy result and the destination result.

Build a controlled regression matrix

Use a proxy and destination you are authorized to test. Create cases for a normal successful CONNECT, an authenticated 407 challenge, a deliberate proxy rejection, a chunked response without trailers, and a chunked response with one or more trailers. If your production estate includes HTTP/2 or experimental HTTP/3 proxy transport, test each negotiated hop separately rather than assuming HTTP/1 behavior carries over.

For every case, record:

  • curl and libcurl version plus TLS and HTTP backends;
  • proxy scheme, hostname label and negotiated HTTP version;
  • address family, DNS owner and expected exit region;
  • CONNECT status and proxy-authentication method;
  • whether headers and trailers reach the intended callback or log field;
  • tunnel transition, destination TLS result and application response class;
  • curl error code, retry count, total duration and final disposition.

Do not store proxy passwords, bearer tokens or raw authentication headers in the test artifact.

Run positive and negative tests

Start with the currently deployed client and capture a baseline. Upgrade only the test cohort to curl 8.22.0, then replay the same matrix with the same controlled proxy behavior.

The positive case should prove that a valid CONNECT exchange reaches the destination and that expected trailer metadata is handled without contaminating tunneled bytes. Negative cases should prove that malformed trailer syntax, an incomplete chunk terminator, an unexpected status and invalid proxy credentials fail closed. A tunnel failure must not silently fall back to a direct connection.

Compare more than the process exit code. Validate the observed exit IP, destination certificate, expected response marker and proxy access record. A zero exit code without the intended route is not a successful proxy test.

Protect retries and telemetry

A parser-level failure can become expensive when a worker retries immediately across the same unhealthy route. Classify CONNECT framing errors separately from authentication failures, destination failures and rate limits. Apply bounded exponential backoff with jitter, cap the retry budget and stop retrying deterministic malformed responses.

Keep trailer values in a separate, size-limited telemetry field. Redact sensitive material and control cardinality before exporting labels. Operators need enough evidence to distinguish a proxy response from tunneled destination data without turning diagnostic logs into a credential or personal-data store.

For broader checks, use the proxy 407 troubleshooting guide, the HTTP/2 proxy compatibility matrix, and the retry budget runbook.

Release checklist

  • [ ] The deployed curl and linked libcurl versions are inventoried.
  • [ ] Normal, 407, rejection, chunked and trailer-bearing CONNECT responses are covered.
  • [ ] Proxy and destination protocol results are recorded separately.
  • [ ] Malformed trailers fail closed and never trigger direct fallback.
  • [ ] Exit IP and destination identity are verified, not inferred.
  • [ ] Retry limits prevent a repeated parsing failure from becoming an outage.
  • [ ] Logs redact credentials and bound trailer size and label cardinality.
  • [ ] A small canary cohort passes before broad rollout.
  • [ ] Rollback criteria and an owner are documented.

FAQ

Does every HTTP proxy user need an emergency upgrade?

The release note alone does not justify that conclusion. Prioritize testing if your proxy can return chunked CONNECT responses or trailers, if callbacks inspect CONNECT headers, or if unexplained tunnel-boundary errors exist. Apply your normal security and support policy for upgrade timing.

Are trailers the same as headers after the tunnel opens?

No. Trailers belong to a framed HTTP message. After a successful CONNECT exchange is complete, subsequent bytes belong to the tunnel. The parser must keep that boundary precise.

Can I test with a public proxy?

Use infrastructure you own or are explicitly authorized to test. Public proxy lists create uncertain consent, unstable behavior and unnecessary data risk.

Compliance note

Test only approved proxy infrastructure and destinations. Respect access controls, contractual limits, robots policies and applicable privacy law. Minimize captured traffic and never use this procedure to bypass restrictions or conceal abuse.

Research note: curl project, “Changes in 8.22.0,” released 2 September 2026. The public article intentionally contains no external source links; research locations are retained in the internal operations record.