HTTP 407 Proxy Authentication Required: What It Looks Like in Each Tool and How to Fix It

A 407 is the proxy talking, not the website. It means the proxy received your request, could not match it to an account, and refused to pass it on. The site you were trying to reach never saw anything.

That makes it a narrow problem with a short list of causes. To make the list concrete, on 30 September 2026 we ran the common tools into a proxy that answers 407 to everything except one correct login, and recorded exactly what each tool prints.

407, 401 and 403 are three different conversations

If you see a 401 or 403, the proxy worked. If you see a 407, nothing after the proxy happened yet. The proxy also tells the client how it wants to be answered, in a Proxy-Authenticate header. For almost every commercial proxy that is Basic, meaning a username and password.

What a 407 looks like in each tool

Two of these are worth a second look. git and pip do not say "proxy" until you read to the end of the line, so the error is often blamed on GitHub or PyPI. And Chrome in automation never shows the text 407 at all. Those two net:: errors are what a 407 becomes.

Causes, from most to least likely

1. The tool never sent the credentials

You wrote the username and password in the right place, and the tool did not use them. Chrome is the usual example: its --proxy-server flag takes a host and port only. In our test, Chrome started with credentials inside that flag refused the proxy altogether and failed with net::ERR_NO_SUPPORTED_PROXIES, and Chrome started through Playwright without credentials sent the proxy a request with no Proxy-Authorization header at all. Selenium's proxy capability has the same limit.

Fix: give the credentials through the tool's own fields. In Playwright that is the username and password keys of the proxy setting, which worked in our test with the same password. In Puppeteer it is page.authenticate. In Selenium there is no native field; the options are in authentication and IP whitelisting.

2. A special character in the password broke the address

Our test password was p@ss#word. Pasted into a proxy address as is, curl did not even reach the proxy:

curl: (5) Could not resolve proxy: ss

curl read the first @ as the end of the credentials and tried to connect to a proxy called ss. Any of @, #, :, /, ? and % in a password does this in a URL.

Fix: percent-encode the password inside the address, or pass it separately. Both worked in our test:

curl -x http://user:p%40ss%23word@proxy.example.com:10000 https://api.ipify.org
curl -x http://proxy.example.com:10000 --proxy-user 'user:p@ss#word' https://api.ipify.org

The encoded form is the one for Python requests, git, pip and every other tool that takes the whole address as one string: @ becomes %40, # becomes %23, : becomes %3A, / becomes %2F, % becomes %25.

3. The credentials are wrong

Expired, rotated by the provider, copied with a trailing space, or from a different package. The proxy log shows a Proxy-Authorization header that decodes to something that does not match.

Fix: copy the login and password fresh from the dashboard, and test with curl before touching anything else:

curl -x http://proxy.example.com:10000 --proxy-user 'login:password' https://api.ipify.org

If that prints an address, the credentials are fine and the problem is in the tool. If it prints the 407 line, the problem is the credentials.

4. The login string is malformed

On gateways that carry targeting in the username, ours included, a typo in a suffix is a wrong username: a space in a city name instead of a hyphen, a lower-case country code, an unsupported session lifetime. Strip the login back to the bare account, confirm it works, then add suffixes one at a time. The list of what our gateway accepts is in the 407 reference.

5. The proxy expects your address, not a password

Some proxies are configured to allow specific source addresses instead of, or as well as, a login. If you were whitelisted from an office and connected from home, or your server's outbound address changed, the proxy answers 407 to a request that carries no usable credentials. Fix: add the new address in the provider's dashboard, or switch that connection to a login.

6. You are behind a proxy you did not choose

This is the "error 407 in Chrome" case for people who never bought a proxy. Your machine or network routes traffic through a proxy that requires a login: a company proxy on a work laptop, a proxy left behind by VPN or security software, or one set by malware.

Fix: find the setting. On Windows it is under Settings, Network and internet, Proxy; on a Mac, in the network service's details under Proxies; on Linux and in terminals, the http_proxy and https_proxy environment variables:

env | grep -i proxy

Chrome, git, pip and most tools follow these. If a proxy is set that you do not recognise, remove it. If it is your company's, it usually wants your Windows login, and command-line tools often cannot answer that kind of challenge; see the next section.

7. The proxy wants a different kind of authentication

Corporate proxies frequently require NTLM or Kerberos, which they announce as Proxy-Authenticate: NTLM or Negotiate. Browsers on a domain-joined machine handle that silently. curl, pip and most libraries do not, and they report the same 407. Fix: ask IT for a Basic-authentication endpoint or a bypass, or run a local relay that speaks NTLM on your behalf; Cntlm and Px are the common ones.

The five-minute fix routine

1. Prove the credentials with curl using --proxy-user, which needs no encoding. If it fails, the problem is on the proxy side: credentials, login string or whitelist.
2. If curl works and your tool does not, the tool is dropping or mangling the credentials. Check for special characters, and check whether the tool takes credentials in the address or in separate fields.
3. Check for a second proxy. Run env | grep -i proxy and look at the system proxy settings. Two proxies in the chain means one of them is getting no credentials.
4. Read the challenge. curl -v prints the Proxy-Authenticate header. If it says anything other than Basic, you have cause 7.

Setting proxy credentials correctly, tool by tool

# curl
curl -x http://proxy.example.com:10000 --proxy-user 'login:password' https://example.com

# Python requests and httpx: one string, so encode the password
proxies = {"http": "http://login:p%40ss@proxy.example.com:10000",
           "https": "http://login:p%40ss@proxy.example.com:10000"}

# git
git config --global http.proxy http://login:p%40ss@proxy.example.com:10000

# pip
pip install --proxy http://login:p%40ss@proxy.example.com:10000 package

# environment variables, read by most tools
export https_proxy=http://login:p%40ss@proxy.example.com:10000

# Playwright: separate fields, no encoding
proxy={"server": "http://proxy.example.com:10000", "username": "login", "password": "p@ss"}

FAQ

What does 407 Proxy Authentication Required mean?

The proxy between you and the website would not accept your proxy login, so it did not forward the request. The website was never contacted.

How is 407 different from 401?

A 401 comes from the website and means the site wants you to log in. A 407 comes from the proxy. If you see 401, the proxy did its job.

How do I fix error 407 in Chrome?

Chrome uses the system proxy. If you set a proxy yourself, enter its login when Chrome asks. If you did not, open your system proxy settings and remove the proxy that is there. In automation, Chrome ignores credentials placed in the proxy address; pass them through the tool's own fields.

Why do I get 407 with the correct password?

Most often because a special character in the password broke the address, or because the tool dropped the credentials entirely. Test the same login with curl --proxy-user, which does neither.

Can a 407 be caused by malware?

Yes. Software that sets a system proxy, including some adware, leaves every browser asking for a proxy login. If you see 407 in every program and never configured a proxy, check the system proxy settings and remove what is there.