Skip to content

407 Proxy Authentication Required

The proxy between the client and the destination requires credentials before it will forward the request.

Status

HTTP/1.1 407 Proxy Authentication Required

Details

  • Category: 4xx
  • Status: Standard. Registered with IANA and defined by a current standards-track RFC.
  • Specification: RFC 9110 §15.5.8
  • Cacheable: Not cacheable
  • Response body: Allowed
  • Retry: Retry only after changing the request

407 is 401's counterpart for intermediaries. It comes from the proxy itself, not from the site being requested, and it means the request never reached its destination. The response must carry a Proxy-Authenticate header naming the scheme, and the client answers with Proxy-Authorization rather than Authorization.

In proxy-based automation it is the single most common configuration error: credentials in the wrong header, credentials that were never sent because the library only handles Authorization, or a URL-embedded username and password containing characters that need percent-encoding.

Note: 407 comes from the proxy, not from the site you requested, and the credentials go in Proxy-Authorization rather than Authorization. If you see 401 and 407 together, fix the 407 first: the request never reached the site.

Headers

  • Proxy-Authenticate: Required on the response. Names the scheme, usually Basic.
  • Proxy-Authorization: Sent by the client in reply. Distinct from Authorization, which is for the origin server.

Common causes

  • No proxy credentials were supplied.
  • A wrong username or password, or credentials for a different proxy endpoint.
  • Special characters in the password that were not percent-encoded inside a proxy URL.
  • A client library that sends Authorization instead of Proxy-Authorization, or drops proxy credentials after a redirect.
  • IP-based access to the proxy expected but the request came from an unapproved address.

How to fix it

As the client

  • Send credentials in Proxy-Authorization, or let the client build them: curl -x http://user:pass@proxy.example.com:8080.
  • Percent-encode reserved characters in the password when embedding it in a URL. An @ or : inside the password breaks the parse.
  • In Python requests, put the credentials in the proxies dict URL rather than in a header.
  • In Playwright and Puppeteer, pass username and password through the launch proxy option. Header injection does not work for CONNECT tunnels.
  • Confirm the port. Proxy endpoints often expose different ports for different pools, and the wrong port authenticates against a different service.

As the server

  • Return Proxy-Authenticate with every 407 so clients know which scheme to use.
  • Log the failing username so operators can tell a typo from a revoked credential.

Examples

Authenticating with a proxy

A request sent through a proxy without credentials:

HTTP request

GET http://example.com/ HTTP/1.1
Host: example.com

The proxy refuses it and names the scheme in Proxy-Authenticate:

HTTP response

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

The client repeats the request with Proxy-Authorization, which is a different header from the Authorization used for the origin server:

HTTP request

GET http://example.com/ HTTP/1.1
Host: example.com
Proxy-Authorization: Basic dXNlcjpwYXNz

The proxy now forwards the request and the origin's response comes back:

HTTP response

HTTP/1.1 200 OK

Notes for proxy users

Stat Proxies authenticates proxy connections with username and password over HTTP and HTTPS, so a 407 always points at the credential pair or how the client is passing it. Check the credentials in the dashboard, then reproduce with curl before blaming the target site: if curl through the proxy succeeds, the problem is in how your library forwards proxy credentials.

Specifications

See also