Use the Proxy Hostname for curl Negotiate Authentication
Keep the proxy's registered service identity intact when diagnosing a Negotiate login, rather than assuming its IP address is an equivalent name.
Use the proxy name supplied for the Negotiate deployment. A TCP connection to its IP does not establish that the same authentication identity will be requested.
curl --proxy http://proxy.example:3128 --proxy-negotiate --proxy-user : --noproxy '' --connect-timeout 5 --max-time 20 https://example.com/Replace the proxy hostname with the approved service name. This selects proxy Negotiate using the platform's available credential arrangement; it neither creates a domain login nor obtains tickets from an unavailable authentication service.
For a deployment expecting HTTP/proxy.example, using an IP or another alias can change the requested service identity. Some environments explicitly support other naming arrangements, so the rule is to preserve the configured identity rather than declare IP authentication universally impossible.
Check the actual curl binary and account environment. GSSAPI or SSPI support depends on the platform/build. If a deployment requires a particular service component, use curl's proxy service-name option according to its registered configuration; guessing names can move the failure rather than fix it.
Negotiate is itself a mechanism-negotiation label. Its presence alone does not establish which underlying mechanism was selected. Use authorized client/server diagnostics when that distinction matters, and keep tickets and tokens out of shared reports.