407 Proxy Authentication Required 4xx
The client must authenticate with a proxy server before the request can proceed.
What does 407 mean?
A 407 Proxy Authentication Required response means an intermediary proxy server — not the destination server itself — requires authentication before it will forward the request onward. It's essentially 401's counterpart for proxies: where 401 says "the destination server doesn't know who you are," 407 says "the proxy in front of the destination doesn't know who you are, and won't even pass your request along until you authenticate with it."
This code is far less commonly encountered than 401 in everyday web use, since most consumer internet connections don't route through authenticating proxies. It's much more relevant in corporate/enterprise network environments, where outbound traffic is often routed through a proxy server that requires credentials.
How a 407 behaves
- It requires a
Proxy-Authenticateheader, analogous to 401'sWWW-Authenticateheader — specifying what authentication scheme the proxy expects - The client should respond with a
Proxy-Authorizationheader containing credentials for the proxy, as distinct from anAuthorizationheader (which would be for the destination server) - It's not cacheable — proxy authentication is connection/session-specific
- The destination server is never reached — a 407 comes entirely from the proxy; the actual server the client was trying to reach has no awareness the request was even attempted
Common causes
If you're building/operating infrastructure:
- You're operating a proxy server that requires authenticated access (common in corporate network setups, controlling and monitoring outbound internet access)
- An application or script running in an environment with a corporate proxy isn't configured with the proxy credentials it needs
If you're calling an API:
- Your environment (often a corporate network, CI/CD runner, or containerized environment) routes outbound HTTP requests through an authenticating proxy, and your HTTP client isn't configured with the proxy's credentials
- Proxy credentials were valid previously but have expired or been rotated
If you're a website visitor:
- You're on a corporate or institutional network that requires proxy authentication for internet access — typically, your browser would prompt for proxy credentials (separate from any website login) before you can browse at all
- A misconfigured proxy setting in your browser/OS is pointing at a proxy server that requires credentials you haven't provided
How to fix it
As an API/website builder:
- This status code is rarely something you return as an application developer — it's generated by proxy infrastructure, not typical application code. If you're building/operating proxy infrastructure, ensure
Proxy-Authenticateheaders correctly specify the expected authentication scheme
As an API consumer:
- Configure your HTTP client with the correct proxy credentials — most HTTP libraries support specifying proxy authentication separately from destination-server authentication (e.g., via a
Proxy-Authorizationheader or dedicated proxy-credential configuration options) - If running in a corporate/CI environment, check whether proxy environment variables (
HTTP_PROXY,HTTPS_PROXY, and their authenticated forms) are correctly set and current - If credentials were working before and suddenly aren't, they may have expired or been rotated — check with whoever manages the proxy infrastructure
As a website visitor:
- Your browser or OS should prompt for proxy credentials if needed — if it's not prompting and you're seeing a 407, your proxy configuration may be incorrect or pointing at the wrong server
- Contact your network administrator (IT department) — proxy configuration is typically managed centrally on corporate networks, not something individual users configure themselves
401 vs 407
| 401 Unauthorized | 407 Proxy Authentication Required | |
|---|---|---|
| Who requires authentication | The destination server | An intermediary proxy server |
| Required header | WWW-Authenticate |
Proxy-Authenticate |
| Client responds with | Authorization header |
Proxy-Authorization header |
| Does the destination server see the request? | Yes (and it's rejecting it) | No — the proxy blocks it before forwarding |
The mechanics are nearly identical — 407 is essentially 401's logic applied one layer earlier in the request path, at the proxy rather than the final destination.
Real-world examples
Corporate networks commonly route all outbound HTTP/HTTPS traffic through an authenticating proxy as part of security and monitoring policy — employees' browsers and applications are configured (often automatically via network policy) with proxy credentials, and 407 surfaces when this configuration is missing, incorrect, or expired. Developers occasionally encounter 407 unexpectedly when running scripts, package managers (npm, pip, composer), or CI/CD pipelines in corporate-network environments where these tools aren't aware of the proxy configuration that browsers handle transparently.
SEO implications
407 has no direct relevance to public-facing website SEO — it's specific to client-side proxy configurations and doesn't apply to how search engine crawlers (which don't typically go through end-user proxies) access publicly hosted content.
FAQ
What's the difference between 401 and 407?
401 means the destination server you're trying to reach requires authentication. 407 means an intermediary proxy — sitting between you and the destination — requires authentication first, before your request even reaches the destination server.
Why am I getting 407 errors when running command-line tools but not in my browser?
Browsers on corporate networks are often pre-configured (via system or network policy) with proxy credentials, handling authentication transparently. Command-line tools (curl, npm, pip, git) often need proxy configuration set explicitly via environment variables or config files, which may not be set up even though your browser works fine.
How do I provide proxy credentials to an HTTP client?
Most HTTP client libraries and command-line tools support a Proxy-Authorization header or dedicated proxy-credential configuration (often via environment variables like HTTP_PROXY=http://username:password@proxyhost:port). The exact mechanism varies by tool/library — check its documentation for proxy authentication configuration specifically.
Is 407 common for typical home internet users?
No — 407 is almost exclusively encountered in environments that route traffic through authenticating proxies, which is typical of corporate, institutional, or certain restricted network environments, not standard home internet connections.
Can a 407 be cached or does it need to be re-handled every time?
Proxy authentication is generally handled at the connection or session level rather than cached per-request — once a client successfully authenticates with a proxy, subsequent requests through the same configured connection typically don't trigger 407 again, until credentials expire or the connection/session resets.
Fun fact
407 is one of the least-encountered status codes by the general public despite being part of the original HTTP/1.1 specification — its entire existence depends on a network topology (client → authenticating proxy → destination server) that the vast majority of internet users never directly interact with, making it almost exclusively a "behind the corporate firewall" status code.