Proxy-Authenticate HTTP Header — Reference

What it does

Proxy-Authenticate is sent by a proxy server to tell the client it needs credentials to pass through the proxy. It's the proxy equivalent of WWW-Authenticate — same concept, different actor. Where WWW-Authenticate challenges on behalf of the origin server (401 Unauthorized), Proxy-Authenticate challenges on behalf of an intermediate proxy (407 Proxy Authentication Required).

Syntax

Proxy-Authenticate: <scheme> realm="<realm>"[, <param>="<value>"]

Identical syntax to WWW-Authenticate:

Proxy-Authenticate: Basic realm="Corporate Proxy"
Proxy-Authenticate: Bearer realm="VPN Gateway"
Proxy-Authenticate: Digest realm="proxy.example.com", nonce="abc123"

The proxy authentication flow

Client                    Proxy                    Origin
  |                         |                         |
  |  GET https://example.com|                         |
  |------------------------>|                         |
  |                         |                         |
  |  407 Proxy Auth Required|                         |
  |  Proxy-Authenticate:    |                         |
  |    Basic realm="Corp"   |                         |
  |<------------------------|                         |
  |                         |                         |
  |  GET https://example.com|                         |
  |  Proxy-Authorization:   |                         |
  |    Basic <credentials>  |                         |
  |------------------------>|                         |
  |                         |  GET https://example.com|
  |                         |------------------------>|
  |                         |  200 OK                 |
  |                         |<------------------------|
  |  200 OK                 |                         |
  |<------------------------|                         |

The key difference from origin auth: the client responds to Proxy-Authenticate with Proxy-Authorization (not Authorization). The two are kept separate so a request can carry both — authenticating with the proxy via Proxy-Authorization and authenticating with the origin via Authorization simultaneously.

Proxy-Authenticate vs WWW-Authenticate

	`WWW-Authenticate`	`Proxy-Authenticate`
Sent by	Origin server	Proxy server
Status code	`401 Unauthorized`	`407 Proxy Authentication Required`
Client responds with	`Authorization`	`Proxy-Authorization`
Scope	End resource access	Proxy passage

When you encounter this in practice

Corporate networks. Many enterprise environments route internet traffic through an authenticating HTTP proxy. Employees' machines are configured to authenticate with it automatically, but developer tools (curl, Docker, package managers) sometimes need explicit proxy auth configuration.

VPN/gateway proxies. Some VPN setups use HTTP proxy authentication as part of their access control.

MITM inspection proxies. SSL inspection proxies (common in enterprise security appliances) often require authentication before they'll forward traffic.

Configuring proxy auth in common tools

# curl
curl -x http://proxy.example.com:8080 --proxy-user user:password https://example.com

# environment variables (used by curl, wget, many CLIs)
export http_proxy=http://user:[email protected]:8080
export https_proxy=http://user:[email protected]:8080

Common mistakes and gotchas

Confusing 407 with 401. If you're getting 407 instead of 401, the authentication challenge is from a proxy, not the origin server. The fix is Proxy-Authorization, not Authorization. Many developers are confused by this because 407 is rarely encountered in direct internet access scenarios.

Proxy auth leaking over HTTPS tunnels. For HTTPS requests through a proxy, the client first sends a CONNECT request to establish a tunnel. The 407 challenge and Proxy-Authorization happen at the CONNECT stage — before the TLS tunnel is established. This means proxy credentials are sent in plain text unless the proxy connection itself is over TLS.

Real-world examples

Proxy challenge:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Corporate Internet Gateway"
Content-Length: 0

Client retry with credentials:

GET https://api.github.com/repos HTTP/1.1
Host: api.github.com
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
Authorization: Bearer ghp_mytoken123

Both proxy auth and origin auth in the same request — they coexist cleanly.

FAQ

Is Proxy-Authenticate common on the public internet?

No. Most public internet requests don't pass through authenticating proxies. You'll mainly encounter 407/Proxy-Authenticate in enterprise environments, development tunnels, or specialised network setups. For most web developers, it's a rarely seen header.

Can a request have both Authorization and Proxy-Authorization?

Yes, and this is exactly why they're separate headers. A single request can authenticate with an intermediate proxy via Proxy-Authorization and with the origin server via Authorization independently. The proxy processes and strips Proxy-Authorization before forwarding; the origin only sees Authorization.

Fun fact

HTTP proxy authentication was designed into HTTP/1.1 from the beginning (RFC 2616, 1999) because the web was originally envisioned as heavily proxy-mediated — enterprise caches, national internet gateways, and ISP-level proxies were expected to be standard internet infrastructure. The rise of HTTPS largely bypassed transparent proxying (you can't cache what you can't read), so proxy authentication became a niche feature mostly encountered in enterprise environments that still route HTTP traffic through inspection appliances.

Proxy-Authenticate auth response