How to Fix 407 Proxy Authentication Required

You send a request through a proxy that was working an hour ago, and instead of the page you asked for, curl prints one line: HTTP/1.1 407 Proxy Authentication Required. No data, no target site, nothing. The request did not fail at the website. It never got that far. The proxy stopped it at the door and asked for ID.

That is the entire meaning of a 407, and it is why the fix is almost never where people first look. A 407 is not the target refusing you, and it is not a network problem. It is the proxy in the middle saying it does not know who you are yet. Get the credentials right, in the right place, and the error disappears. Here is how to do that, and how to tell which of the handful of causes you actually have.

What does a 407 Proxy Authentication Required error mean?

A 407 Proxy Authentication Required error means the proxy needs credentials to forward your request, and you either sent none or sent ones it could not accept. It comes from the proxy itself, not the website you were trying to reach, so your request never made it to the target. The proxy is holding the door shut until you authenticate.

407 vs 403 vs 401: who is actually rejecting you

The fastest way to fix a 407 is to see that it is not like the rejection errors that come from websites. Three status codes get confused constantly, and they come from two different places:

A 401 and a 403 come from the destination. Your request reached it, and the site made a decision. A 407 is different in kind: it comes from the proxy sitting between you and the destination, and it fires before the target sees a single byte of your request. (If you are actually chasing a 403, we cover that one in how to fix 403 Forbidden through a proxy.)

Two signals confirm you are looking at a real 407 and not something mislabeled:

• The status line contains the word Proxy.
• The response carries a Proxy-Authenticate header, not WWW-Authenticate.

If those are present, stop editing the target URL, stop rewriting request headers, stop trying to log into the site. None of it touches the proxy layer, and the proxy layer is the whole problem.

What actually triggers a 407

There are only four root causes, and every fix below maps to one of them:

Work down them in order. The first two cover most cases, the third catches the surprises, and the fourth is the one people stare at for an hour.

Fix 1: Put the credentials on the proxy, not the target

The most common 407 is the simplest: the proxy needs a username and password and did not get one. With curl, there are two correct ways to supply them.

Inline in the proxy URL:

curl -x http://user:[email protected]:8080 https://httpbin.org/ip

Or with the -U / --proxy-user flag, which keeps the credentials out of the URL:

curl -x http://203.0.113.7:8080 -U user:pass https://httpbin.org/ip

Both authenticate to the proxy. The mistake that produces a stubborn 407 here is putting the credentials on the wrong URL, for example curl -u user:pass -x http://203.0.113.7:8080 .... Lowercase -u sends credentials to the target site, not the proxy, so the proxy never sees a Proxy-Authorization header. For the proxy you need uppercase -U, or the inline form on the proxy address itself. Mix those two up and you can have perfectly valid credentials and still get a 407 every single time, because the proxy never saw them.

Fix 2: URL-encode special characters in the password

This is the 407 that wastes the most time, because the credentials are correct and the error still fires. The cause is a special character in the password colliding with URL syntax.

Look at a password like p@ss:word. Dropped straight into the proxy URL, it becomes a parsing puzzle:

# Risky: the @ and : in the password collide with URL syntax
curl -x http://user:p@ss:[email protected]:8080 https://httpbin.org/ip

curl uses @ to mark where the credentials end and the host begins, and : to separate fields. With those same characters sitting inside the password, curl splits the string in the wrong place: it reads a different username and password than you meant, or it loses the host entirely. Either way the proxy never receives your real credentials, so it answers with a 407 (or curl fails to connect at all).

The fix is to percent-encode any reserved character in the username or password:

So p@ss:word becomes p%40ss%3Aword:

curl -x http://user:p%40ss%[email protected]:8080 https://httpbin.org/ip

The cleaner option is to skip URL parsing altogether and use -U, which splits on the first colon only and treats everything after it as the literal password:

curl -x http://203.0.113.7:8080 -U 'user:p@ss:word' https://httpbin.org/ip

Here the @ and the second : need no encoding at all. If your password is full of symbols, -U in single quotes is the quiet way to end this whole category of 407. The cURL proxy guide goes deeper on why inline credentials bite in scripts.

Fix 3: On IP authentication, whitelist your current IP

Not every provider uses a username and password. Many identify you by your IP address instead: you add your IP to an allowlist in the dashboard, and any request from that address is trusted, with no credentials attached. It is convenient right up until your IP changes.

Your IP changes more often than you think: a home connection with a dynamic address, a VPN toggled on, a laptop moved to a new network, a cloud server whose egress IP differs from your workstation. The moment a request leaves from an address that is not on the list, the proxy does not recognize you, and you get a 407, even though you never had a password to get wrong.

The fix is two steps. Find the IP you are actually leaving from:

curl -s https://httpbin.org/ip

Then add that exact address to the IP allowlist in your provider's dashboard. One more thing that trips people up: on IP authentication you send no user:pass at all. Bolting credentials onto an IP-auth proxy can itself cause a 407 on some gateways, so pick one method and match what your account is set to.

Fix 4: Confirm the scheme the proxy expects

Nearly all proxies use HTTP Basic for the credential handshake, and curl does the right thing automatically. On the rare gateway that expects something else, or when you just want to see what the proxy is asking for, curl -v shows the challenge:

curl -v -x http://203.0.113.7:8080 https://httpbin.org/ip 2>&1 | grep -i proxy-authenticate

The Proxy-Authenticate line the proxy returns names the scheme it wants (Basic, Digest, and so on). If it asks for anything other than Basic and your client is sending Basic, that mismatch is your 407. Match the scheme, and check the provider's docs for whether they expect the credential in the proxy URL, in a header, or as a dashboard allowlist.

Fix 5: Prove it with curl before you touch your code

When a 407 shows up inside a Python or Node script, the instinct is to debug the script. Do the opposite first: reproduce it in one curl line. curl is a clean, dependency-free test of the credentials and the proxy, with none of your application's abstractions in the way.

curl -x http://user:[email protected]:8080 -s https://httpbin.org/ip

If that prints the proxy's exit IP, the credentials and the proxy are both fine, and your bug is in how your library passes proxy auth (a very common one: setting the proxy but forgetting the auth, or encoding the password differently than curl does). If curl also returns 407, the problem is the credentials or the whitelist, and you have just saved yourself an hour of reading the wrong code. If it returns a different curl exit code instead, the curl proxy error guide decodes what each one means.

A 30-second 407 checklist

When the error hits, run these in order:

1. Does the status line say Proxy? If yes, it is the proxy, not the site. Ignore the target entirely.
2. user:pass or IP auth? Check which one your account uses, because the fix is completely different.
3. Reproduce in curl with -U user:pass. Passes? Your code is the bug. Fails? Read on.
4. Special characters in the password? Percent-encode them, or switch to -U.
5. On IP auth? Run curl -s https://httpbin.org/ip to see your real exit IP, then whitelist it.

Five checks, and a 407 goes from a wall to a two-minute fix.

Where to go from here

A 407 is one of the friendlier proxy errors once you see that it names its own cause: the proxy is up, it answered you, it just wants valid credentials. If you would rather not wrestle credentials by hand, our proxy checker confirms a proxy is alive and anonymous in one paste, and the free proxy list and free proxy API return endpoints you can test against without a key or a login. And if you are chasing a different failure, the companion guide on 504 gateway timeouts through a proxy covers the error that looks like a 407 but comes from the opposite end of the connection.