Proxy-Authorization auth request
Carries credentials to authenticate with an intermediate proxy — the client's response to a 407 Proxy Authentication Required challenge.
What it does
Proxy-Authorization carries credentials for authenticating with an intermediate proxy server. It's the client's response to a 407 Proxy Authentication Required challenge — the proxy equivalent of Authorization, which authenticates with the origin server.
The header is processed and consumed by the proxy. It never reaches the origin server — the proxy strips it before forwarding the request.
Syntax
Proxy-Authorization: <scheme> <credentials>
Identical syntax to Authorization:
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
Proxy-Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
How it differs from Authorization
Authorization |
Proxy-Authorization |
|
|---|---|---|
| Authenticates with | Origin server | Intermediate proxy |
| Triggered by | 401 Unauthorized + WWW-Authenticate |
407 Proxy Auth Required + Proxy-Authenticate |
| Reaches origin | Yes | No — stripped by proxy |
| Can coexist | Yes | Yes — both can be on the same request |
A single request can carry both headers: Proxy-Authorization for the proxy and Authorization for the origin. The proxy reads and removes Proxy-Authorization, then forwards the request with Authorization intact.
Configuring proxy auth in common tools
curl:
curl -x http://proxy.corp.example.com:8080 \
--proxy-user "username:password" \
https://api.github.com
Environment variables (curl, wget, pip, npm, Docker, etc.):
export HTTP_PROXY=http://username:[email protected]:8080
export HTTPS_PROXY=http://username:[email protected]:8080
export NO_PROXY=localhost,127.0.0.1,.corp.example.com
Git:
git config --global http.proxy http://username:[email protected]:8080
npm:
npm config set proxy http://username:[email protected]:8080
npm config set https-proxy http://username:[email protected]:8080
Security consideration: CONNECT tunnels
For HTTPS requests through an HTTP proxy, the browser first sends a CONNECT request to establish a TCP tunnel:
CONNECT api.github.com:443 HTTP/1.1
Host: api.github.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
The proxy authenticates at this CONNECT stage — before the TLS tunnel is established. This means proxy credentials travel in plain text if the client-to-proxy connection is not itself TLS-secured. In corporate environments, the client-to-proxy connection is usually HTTP (unencrypted) — proxy credentials are visible on the local network.
Common mistakes and gotchas
Sending Authorization instead of Proxy-Authorization. If you're getting 407 and your fix is to send Authorization, it won't work — the proxy is looking for Proxy-Authorization, not Authorization. These are different headers with different purposes.
Credentials in environment variables in logs. HTTP_PROXY=http://user:password@proxy... in environment variables can leak in process listings, log files, or crash reports. Use credential stores or config files where possible.
Forgetting NO_PROXY. Without NO_PROXY, all traffic including local development servers gets routed through the proxy. Always set NO_PROXY=localhost,127.0.0.1 at minimum.
Real-world example
Full proxy auth flow for an HTTPS request:
CONNECT api.github.com:443 HTTP/1.1
Host: api.github.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
HTTP/1.1 200 Connection Established
[TLS handshake with api.github.com]
GET /repos/user/repo HTTP/1.1
Host: api.github.com
Authorization: Bearer ghp_mytoken123
HTTP/1.1 200 OK
The proxy sees Proxy-Authorization on the CONNECT request. After establishing the tunnel, it only sees encrypted traffic — Authorization for the GitHub API is never visible to the proxy.
FAQ
When would I actually encounter a 407?
Almost exclusively in enterprise/corporate environments where all internet traffic is routed through an authenticating proxy. Consumer internet connections don't use authenticating proxies. If you're developing on a corporate network and your HTTP clients can't reach the internet, a 407 is the likely culprit.
Is Proxy-Authorization sent automatically by browsers?
Yes — modern browsers handle proxy authentication automatically. If a proxy is configured in system network settings and returns a 407, the browser prompts for credentials (or uses stored ones) and retries with Proxy-Authorization automatically. Developer tools like curl and library code require manual configuration.
Fun fact
Corporate HTTP proxies that require Proxy-Authorization were a significant pain point during the early cloud computing era — developers trying to use cloud CLIs, Docker, and package managers from corporate networks would hit 407 errors with no clear explanation. The proliferation of HTTPS (which proxies can't inspect without MITM certificates) and zero-trust network architectures has made traditional authenticating HTTP proxies less common, but they're still very much alive in large enterprises.