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.