curl Tightens CONNECT Handling: 401 Is Not Proxy Authentication

The curl project merged a focused HTTP proxy change on September 4, 2026: when a proxy answers a CONNECT request with 401 Unauthorized, curl should ignore WWW-Authenticate for that tunnel exchange and fail the connection. Proxy authentication remains driven by 407 Proxy Authentication Required and Proxy-Authenticate.

This distinction matters because CONNECT is addressed to the proxy, not the destination origin. A 401 challenge belongs to origin authentication semantics; a 407 challenge belongs to the proxy. Acting on a 401 during tunnel setup can blur those trust boundaries and may trigger an unintended authentication retry.

As of September 9, the change is merged into curl's development branch and listed in the release notes for the next maintenance release. It is not evidence that every installed curl package already contains the fix. Check the shipped version and your distributor's patch set before changing production policy.

Public source note: curl project, pull request 22817, “HTTP-CONNECT: do not react to 401 responses,” opened September 3 and merged September 4, 2026; curl project, development release notes, reviewed September 9, 2026.

What changed

During an HTTP CONNECT handshake, the client asks a proxy to create a byte tunnel to a destination authority. A successful response establishes that tunnel. A 407 response means the proxy requires authentication and can advertise acceptable methods through Proxy-Authenticate.

The merged change prevents the CONNECT parser from forwarding or interpreting WWW-Authenticate when the CONNECT response is 401. Instead, curl treats the response as a failed tunnel attempt. The patch also adds a dedicated regression test so this behavior stays explicit.

This is a parser and authentication-boundary correction. It does not add a new authentication method, bypass proxy policy, or make a rejected tunnel eligible for unlimited retries.

Why the difference between 401 and 407 matters

A proxy-backed client often holds two separate credential sets:

• proxy credentials used before a tunnel exists;
• destination credentials used only inside the established tunnel.

Mixing the two creates operational and security risk. A client might send a destination credential toward the proxy layer, retry a deterministic rejection, rotate healthy exits, or mislabel the event as a destination login problem. In a shared connection pool, ambiguous authentication state can also make incident evidence harder to interpret.

The correct classification is simple:

The curl CONNECT trailer testing guide covers the surrounding response-framing boundary. The SPNEGO and NTLM fallback article explains a separate proxy-authentication hardening change.

Build a controlled regression fixture

Use a proxy simulator and destination that you own or are authorized to test. Keep concurrency at one and disable automatic gateway rotation so each result has one cause. Prepare four proxy behaviors:

1. Return a normal 2xx CONNECT response and relay the tunnel.
2. Return 407 with a supported Proxy-Authenticate challenge.
3. Return 401 with WWW-Authenticate and close the connection.
4. Return another deterministic non-2xx response without authentication headers.

Run each case with the currently deployed build and a build containing the merged change. Do not test malformed authentication behavior against unrelated public proxies.

Evidence to capture

Record the client version, build identifier, TLS backend, proxy transport, gateway cohort, address family and timestamp. For the CONNECT exchange, retain only sanitized fields:

• response status;
• whether Proxy-Authenticate or WWW-Authenticate was present;
• selected proxy-auth method, if any;
• number of CONNECT attempts;
• curl result code and total duration;
• whether any destination TLS bytes were sent;
• whether a direct connection was attempted.

Never log usernames, passwords, bearer tokens, raw authorization values, cookies, or full session identifiers. Tokenize gateway and exit identifiers when raw addresses are unnecessary.

Pass and fail conditions

The 2xx case passes only if the destination TLS and application checks succeed through the intended proxy route. The 407 case passes when curl performs the permitted proxy-auth flow, respects the retry cap, and establishes the tunnel with the correct credential scope.

The 401 case passes when curl fails CONNECT without acting on WWW-Authenticate, without sending destination credentials, without reaching destination TLS, and without silently falling back to a direct path. A generic failure code alone is not enough; verify the absence of an authentication retry.

The remaining non-2xx case should fail once with an attributable result. Repeatedly rotating exits after the same deterministic fixture response is a retry-policy failure.

Roll out without confusing client and network health

Start with a small canary cohort using the same proxy gateways, destinations and workload mix as the control. Compare:

• valid-result rate on first attempt;
• CONNECT status distribution;
• proxy-auth challenge rounds;
• credential-scope violations, expected to remain zero;
• direct-fallback attempts, expected to remain zero;
• p50 and p95 tunnel establishment time;
• retry volume per completed job.

If 401 failures increase after the client change, do not automatically blame exit quality. The stricter client may be exposing a gateway, captive intermediary, or test fixture that returns origin-style authentication at the proxy boundary. Preserve the sanitized response and investigate the component that generated it.

Pre-deployment checklist

• Confirm whether the deployed binary contains the merged change.
• Separate proxy and destination credentials in configuration and logs.
• Test 2xx, 407, 401 and another non-2xx response.
• Verify that 401 does not trigger an authentication retry.
• Verify that failed CONNECT never falls back to a direct route.
• Cap retries and prevent automatic exit penalties for deterministic client-policy failures.
• Redact every credential and high-cardinality session value.
• Compare a canary with the current production client before broad rollout.

FAQ

Does this mean a proxy must never return 401?

For proxy authentication during CONNECT, the defined status is 407. A 401 represents origin authentication semantics and should not be used to drive proxy credential negotiation.

Is the fix already in curl 8.22.0?

No claim should be made from the development release notes alone. The change was merged after 8.22.0 and is listed for the next release. Check the exact binary and vendor backports you deploy.

Should a 401 rotate the residential proxy exit?

Not automatically. First classify the response as a tunnel-boundary failure and determine which component generated it. Rotating exits can hide a deterministic gateway or client-policy problem.

Can logs include the authentication headers for debugging?

Store header names and sanitized method labels only. Do not retain credentials, tokens or raw challenge material unless an approved security process explicitly requires it.

Compliance note

Use this procedure only with systems and proxy services you are authorized to test. Respect destination terms, access controls, rate limits, privacy obligations and data-minimization rules. The goal is correct authentication scoping and reliable failure handling, not bypassing a rejection.