Diagnose an NTLM Proxy Login in curl

NTLM proxy authentication involves a handshake, not just attaching a username once. Before changing an account password, confirm that the proxy actually offers NTLM and that the curl binary supports it.

curl --version

Inspect the feature list from the binary that runs your request. Another installed curl, container image, or operating-system build can have different authentication support.

Use a proxy-specific method selection

curl --proxy http://proxy.example:3128 --proxy-ntlm --proxy-user 'EXAMPLE\alice' --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/

The endpoint, domain, and username are examples. Use the format supplied by your administrator. With no password included in the argument, curl can prompt instead of leaving the secret in the displayed command.

An initial authentication challenge can be part of negotiation. Distinguish that from a completed handshake being rejected. Do not use an origin NTLM option to answer a proxy challenge.

Keep connection behavior in the diagnosis

NTLM has connection-scoped state. The handshake must be carried through the expected connection path; repeatedly replacing connections between its stages can prevent completion.

For an application using libcurl, let the library manage its authentication and connection reuse. Do not build a generic pool that treats connections authenticated for different identities as interchangeable. For a multi-hop or intermediary service, check whether it preserves the required connection arrangement.

If support and method selection are correct, investigate account format, domain policy, and the server's sanitized authentication logs. A timeout before any challenge is still a reachability problem, not evidence that an NTLM password was wrong.

Verbose traces can contain authentication tokens and internal names. Use them locally and redact them before sharing; a raw token exchange is unnecessary in a public error report.