HTTP 407 Proxy Authentication Required – Free, Online, Private

What HTTP 407 means

407 is 401 for a proxy. The proxy, not the origin, is demanding authentication. The challenge is in Proxy-Authenticate, not WWW-Authenticate. The origin may be healthy. Until the client authenticates to the proxy, the request will not go further. Browsers show a proxy login. API clients need proxy configuration.

407 Proxy Authentication Required belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 407

When you see HTTP 407 Proxy Authentication Required, stop on that exact status line. 407 Proxy Authentication Required means a proxy wants credentials before it will forward the request. The trace that usually produces it: A corporate forward proxy challenged the client. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

A proxy returns 407 when it requires credentials for the hop. Origins should not impersonate this status. If your application needs a login, use 401. If a corporate proxy is between the user and you, you will see 407 in the client and nothing in your access log, because the request never arrived.

How to fix HTTP 407

To fix HTTP 407, change the condition that made the server choose Proxy Authentication Required. Collect proxy credentials and retry the same request through the proxy. Do not send those credentials to the origin as Authorization. If you have no proxy, a 407 means something in the path is not what you think it is. Retry once you have proxy credentials. Retrying without them repeats the challenge. If the log line is a different code, leave this page. The mix-up people make with 407 is this one: 401 is the origin's challenge, with WWW-Authenticate. 407 is the proxy's challenge, with Proxy-Authenticate. 305 was the deprecated 'use this proxy' status.

• The client sent Proxy-Authorization for the wrong realm.
• A library treated 407 as 401 and attached the secret to the origin instead of the proxy.
• The proxy credentials expired and every request started failing at once.

An access log that only stores 407 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 407 Proxy Authentication RequiredHTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="corp"

Proxy-Authenticate names the scheme and realm. The client retries through the same proxy with Proxy-Authorization. Those credentials are for the proxy. They are not an API key for the origin. Mixing them up leaks the proxy password to the origin.

What the client should do

Collect proxy credentials and retry the same request through the proxy. Do not send those credentials to the origin as Authorization. If you have no proxy, a 407 means something in the path is not what you think it is.

Do not cache 407 as the origin response. It is a property of the proxy hop.

Retry once you have proxy credentials. Retrying without them repeats the challenge.

Codes people confuse with HTTP 407

401 is the origin's challenge, with WWW-Authenticate. 407 is the proxy's challenge, with Proxy-Authenticate. 305 was the deprecated 'use this proxy' status.