Proxy-Authenticate

When a proxy server requires credentials before forwarding a request, the Proxy-Authenticate response header indicates which Authentication scheme to use.

Table of Contents

Usage

When a client sends a request through a proxy server requiring credentials, the proxy responds with a 407 status code and includes the Proxy-Authenticate header. This header tells the client which authentication scheme to use and provides any parameters needed to construct the credentials.

After receiving the challenge, the client resubmits the request with a Proxy-Authorization header containing the appropriate credentials. The proxy validates the credentials and, on success, forwards the request to the destination server.

The Proxy-Authenticate header operates at the proxy level. The equivalent header for origin server authentication is WWW-Authenticate, which triggers a 401 response instead of a 407.

Multiple Proxy-Authenticate headers in a single response indicate the proxy accepts more than one scheme. The client selects the strongest scheme both sides support.

Directives

scheme

The scheme value identifies the authentication method. Common values are Basic, Digest, Bearer, and Negotiate. The full list of registered schemes is maintained by IANA.

realm

The realm parameter is a string describing the protection space. The authentication framework treats realm as optional, while schemes like Basic and Digest require it in their challenges. Clients typically display the realm value in the credential prompt. When omitted, the client defaults to showing the proxy hostname.

Scheme-specific parameters

Each authentication scheme defines additional parameters. The Digest scheme includes nonce, qop, algorithm, and opaque. The Bearer scheme includes scope and error. These parameters appear after the scheme name in the header value.

Example

A proxy requiring Basic authentication returns a challenge with a descriptive realm. The realm value tells the user which credentials are expected.

Proxy-Authenticate: Basic realm="Corporate Proxy"

A proxy supporting the Digest scheme includes a server-generated nonce to prevent replay attacks.

Proxy-Authenticate: Digest realm="proxy@example.re", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", qop="auth"

A proxy offering multiple authentication schemes lists each one on a separate line. The client picks the strongest supported option.

Proxy-Authenticate: Negotiate
Proxy-Authenticate: Basic realm="Internal Network"

One hop, not one chain

Proxy-Authenticate applies to the next outbound client alone, which separates the header from WWW-Authenticate more sharply than the 407 number suggests. Only the client choosing a proxy holds credentials for the proxy, so the challenge stops at the first hop instead of travelling the response chain.

Corporate networks blur the picture without breaking the rule. Office and regional proxies inside one administrative domain commonly present identical challenges, and credentials generated once pass through the hierarchy until consumed, which looks like forwarding while remaining per-hop consumption.

Scheme choice follows the network rather than the web. Corporate proxies lean on Negotiate and NTLM, and browsers treat proxies more permissively than origins here: Chrome answers integrated authentication challenges from any proxy automatically, while origin servers need explicit allowlisting. Ordering matters for compatibility, since clients failing to parse an unknown scheme are common enough for the specification to advise listing widely supported schemes such as basic first.

A 407 carrying no Proxy-Authenticate leaves clients with nothing to answer, the same dead end a 401 without WWW-Authenticate produces at the origin.

See also

Last updated: August 17, 2026