What's the difference between 407 and 401?

They look identical and mean different things about *who* is asking for credentials. RFC 9110 §15.5.8 defines 407 as 'similar to 401, but it indicates that the client needs to authenticate itself in order to use a proxy.' A 401 comes from the origin server and uses the WWW-Authenticate and Authorization headers. A 407 comes from a proxy sitting between you and the origin, and uses Proxy-Authenticate (the challenge) and Proxy-Authorization (your answer). If you keep sending origin credentials to fix a 407, nothing happens — the proxy in front never sees them. Read which header carries the challenge and you know which hop is rejecting you.

Why does the same request work with curl but fail in my app?

Almost always because curl is picking up proxy settings your app isn't. A 407 means a proxy demanded credentials and your app didn't supply them. curl reads http_proxy/https_proxy environment variables (often including embedded user:pass), while your HTTP client library may ignore them or need the proxy configured explicitly. The credentials aren't wrong — they're not being attached to the request at all. Check how each tool discovers its proxy and whether the Proxy-Authorization header actually gets sent.

The proxy auth is hop-by-hop — what does that mean for me?

Proxy-Authorization is consumed by the first proxy it reaches and is not forwarded onward, unlike Authorization, which travels end-to-end to the origin. In a chain of proxies, each hop that requires auth issues its own 407 and expects its own Proxy-Authorization. That's why a single set of proxy credentials can still hit a 407 deeper in the chain, and why you can't 'pass through' proxy credentials the way you pass origin credentials. Each proxy hop is a separate negotiation.

Views: 137

407 Proxy Authentication Required: Fix Proxy Auth

407 Proxy Authentication Required means a proxy rejected your credentials, not the origin. Tell it from a 401 in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A request returns 407 Proxy Authentication Required. It never reached the site you were trying to load. A proxy sitting between you and the origin — a corporate gateway, a scraping proxy, a caching appliance — refused the request because you didn’t authenticate to the proxy. The origin server is irrelevant here; you’re stuck at the doorman, not the destination.

Symptoms

Your client (browser, curl, a scraper, a CI job) reports 407 Proxy Authentication Required.
The response carries a Proxy-Authenticate header naming a scheme — Basic, Digest, NTLM, or Negotiate.
It appears only on a network with a proxy (an office, a VPN, a data-center egress) and vanishes on an unproxied network.
Everything worked until proxy credentials expired, rotated, or a proxy URL lost its embedded user:pass.

What 407 Actually Means

RFC 9110 (§15.5.8) defines 407 as “similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy for this request.” That one word — proxy — is the entire diagnosis. The request got as far as an intermediary and was turned away for lack of proxy credentials. The origin never saw it.

The header pair is what separates 407 from its twin. A 407 response MUST include a Proxy-Authenticate header (RFC 9110 §11.7.1) carrying the challenge, and the client answers with a Proxy-Authorization header (§11.7.2). Compare that to 401, which uses WWW-Authenticate and Authorization. Same handshake, different actors: 401 is the origin asking who you are; 407 is the proxy asking. Reading which header carries the challenge tells you immediately which hop rejected you — and stops you from wasting an afternoon adding origin credentials that the proxy in front will never even forward.

That forwarding detail matters more than it looks. Proxy authentication is hop-by-hop: Proxy-Authorization is consumed by the nearest proxy and not passed along, whereas Authorization is end-to-end and travels to the origin. In a chain of proxies, each hop that wants auth throws its own 407. One credential does not “flow through” the chain.

Top 3 Causes

Missing or wrong proxy credentials - The client isn’t sending a Proxy-Authorization header, or it’s sending the wrong username/password. In scrapers and CI this is the classic case: the proxy URL is http://proxy.example:8080 with no user:pass, or the credentials were rotated and never updated. This is the overwhelming majority of real 407s.
The client isn’t finding the proxy config - The proxy is set in an environment variable or system setting that one tool reads and another ignores. curl honors http_proxy/https_proxy; a library may not, or may need the proxy passed explicitly. The request goes out with no proxy auth attached and the proxy bounces it.
An unsupported or mismatched auth scheme - The proxy demands NTLM or Negotiate (common on corporate Windows networks) but the client only speaks Basic. The credentials exist; the client can’t perform the challenge the Proxy-Authenticate header is asking for.

Diagnose with DechoNet

HTTP Check requests the target URL from our servers, which don’t sit behind your corporate or scraping proxy. If HTTP Check returns a normal 200 (or the site’s real status) while you get 407, that confirms the origin is healthy and the 407 is being generated by your proxy hop — isolating the problem to your side of the connection, not the destination.

Resolution Checklist

Confirm it’s a proxy problem, not an origin one: is it a 407 with a Proxy-Authenticate header (proxy) or a 401 with WWW-Authenticate (origin)? Fix the right hop.
Read the scheme in Proxy-Authenticate. Basic/Digest are simple user:pass; NTLM/Negotiate need a client that can do Windows-integrated auth. Match your client to the scheme.
Verify credentials are actually attached. With curl: curl -v -x http://user:pass@proxy:8080 https://YOUR_TARGET and look for the Proxy-Authorization header going out. If it’s absent, the client never picked up the credentials.
If special characters are in the password, URL-encode them in the proxy URL (@, :, / will break parsing otherwise).
Cross-check with HTTP Check. If our direct request to the origin succeeds and yours 407s, the fault is your proxy hop, not the site — chase the proxy config, not the server.
For a proxy chain, remember each hop authenticates separately. A 407 after the first proxy means a later proxy wants its own Proxy-Authorization.

When to Escalate

If credentials are confirmed correct and attached but the proxy still returns 407, escalate to whoever runs the proxy — the account may be disabled, IP-locked, or the auth backend (LDAP/AD) may be down.
On a corporate network requiring NTLM/Negotiate, escalate to IT or use a local auth-forwarding proxy (e.g. Cntlm) rather than trying to hand-roll the challenge in every client.
If a scraping or egress proxy 407s intermittently, escalate to the provider — it’s often rate-based credential throttling or a rotated pool, not your configuration.