The proxy requires a username and password (HTTP 407)
The dialog asking for a username and password comes from your proxy, not from the website. Until you enter the credentials, the request never leaves the proxy and the page never loads. Below are six steps to close that dialog for good, plus what to do when you get an error code instead of a prompt.
What does "proxy authentication required" mean?
The proxy answered with HTTP 407 and a Proxy-Authenticate header naming the scheme it expects. Your browser showed you the dialog and is waiting to repeat the request with a Proxy-Authorization header. The website has not seen your request at this point.
The difference from 401 matters when you diagnose: 401 comes from the site itself, 407 from the proxy. One rule from the specification helps you tell them apart: RFC 9110 §11.7.1 requires a proxy to send a Proxy-Authenticate header in every 407 it generates. If that header is missing, the answer came from a filter or a misconfigured server rather than a working proxy, and no password will fix it.
Difficulty, time and what you need
Difficulty is low in a browser and moderate once command-line tools are involved. Time: 2 to 5 minutes in a browser, 10 to 15 minutes if you also have to fix curl, pip, npm or git.
Have these ready before you start:
- The proxy host and port, exactly as configured.
- The username and password from whoever issued the proxy. At Proxys.io they sit in your dashboard next to the IP and port.
- Access to the machine's proxy settings. Chrome and Edge read the system configuration, Firefox keeps its own. Where those fields live is covered in our Windows 11 step-by-step instructions and, on a phone, in setting up a proxy on an iPhone or iPad.
- A terminal, if you need step 5.
Two cases this guide will not solve. First: the dialog appears although you never configured a proxy and cannot find one in your settings, because a VPN extension, a security product or a device policy injected it. The fix there is removing that software. Second: the site itself is asking for credentials, not the proxy; that is a 401, and proxy credentials do not belong there.
How to fix the proxy username and password prompt
Step 1. Identify who is asking before you type anything
Read the first words in the dialog. If it starts with The proxy, the credentials belong to the proxy. If it names a domain with no mention of a proxy, the website is asking. In Firefox, a moz-proxy:// prefix before the address marks a proxy prompt.
What should happen: you can state who is asking (a proxy IP and port, or a site domain) and which credential pair matches it.
A proxy password typed into a website prompt goes to the wrong host. If Chrome prints Your connection to this site is not private under the dialog text, stop and check the address before pressing the button.
Step 2. Enter the credentials your provider issued
Type the username and password and press Sign in. Copy them from the dashboard instead of retyping, because proxy passwords are usually generated strings where l, 1 and I are easy to confuse.
What should happen: the dialog closes and the page loads. If the same dialog reappears immediately with empty fields, the proxy rejected the pair and sent a second 407.
A trailing space often gets copied along with the password. Most proxies treat it as part of the credential and reject it silently.
Step 3. Save the credentials so the prompt stops returning
Let the browser's password manager store the pair when it offers. If you configure the proxy with an extension, the extension holds the credentials and the dialog never appears at all. That is how ProxyControl works, alongside the other ways to set up a proxy in Chrome.
What should happen: you restart the browser, open a page, and the dialog does not appear.
The system proxy configuration will not hold the password: on Windows, netsh winhttp set proxy accepts only the address and a bypass list, with no field for a login. That is why an authenticated proxy goes into the browser or an extension instead.
Step 4. Encode special characters if the password keeps being rejected
A correct password fails when it contains characters that have a reserved meaning inside a URL. If you pass the proxy as http://user:pass@host:port, replace @ with %40, : with %3a and a literal % with %25 inside the password.
What should happen: the request goes through with the encoded string where the raw one failed.
The -U user:pass flag in curl does not escape this, because the same decoding applies there. And do not confuse --proxy-pass with the proxy password: it is the passphrase for a client certificate key, while the password goes in -U or --proxy-user.
Step 5. Verify the fix from the command line before blaming the browser
Run one request with verbose output:
curl -v -x http://user:pass@proxy.example.com:8080 https://example.com
What should happen: a 200 and the page body. If the credentials are rejected, the refusal is visible in the output:
> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> User-Agent: curl/8.5.0
>
< HTTP/1.1 407 Proxy Authentication Required
< Proxy-Authenticate: Basic realm="Corporate proxy"
* CONNECT tunnel failed, response 407
Read the Proxy-Authenticate line, which names the scheme the proxy wants: Basic, Digest, NTLM or Negotiate. When it says Negotiate and curl is sending Basic, no password will ever work; add --proxy-anyauth.
Match the exit code against your curl version, not against old tables. On a failed CONNECT, curl returned 56 up to and including 8.19.0, while since 8.20.0, released 29 April 2026, the same failure returns 7. For a plain http:// request there is no tunnel at all: curl prints the 407 body and exits with zero unless you pass -f.
Step 6. Switch to IP authentication if the prompt keeps coming back
Some tools cannot store proxy credentials, and changing the authentication method costs less than fighting the dialog in each of them. Bind the proxy to your IP in the provider's dashboard and drop the username and password.
What should happen: the proxy accepts requests with no Proxy-Authorization header, and the dialog disappears from every application at once, including those with no credential field.
This assumes a static address. A dynamic home IP changes the next time the router reconnects, and access goes with it.
What to do when Chrome shows an error instead of the prompt
The browser does not always ask for a password; on some failures it returns a code straight away. What each one means:
Code | What to do |
|---|---|
ERR_PROXY_AUTH_REQUESTED | The proxy wants credentials, go back to step 2 |
ERR_PROXY_AUTH_UNSUPPORTED | The proxy requires a scheme Chrome cannot use; no password helps, you need a different proxy |
ERR_PROXY_CONNECTION_FAILED | The proxy was never reached: check the host and port, authentication is not involved |
ERR_TUNNEL_CONNECTION_FAILED | The proxy answered but the tunnel failed, often wrong credentials or a plan-level block |
ERR_UNEXPECTED_PROXY_AUTH | A 407 arrived on a request that bypassed the proxy: check whether an extension interferes |
ERR_TOO_MANY_RETRIES | The proxy keeps demanding fresh credentials in a loop; clear the saved password and enter it again |
Chrome demotes a proxy for five minutes after it fails once. If the credentials are already fixed but requests still go the wrong way, reset that list with the Clear bad proxies button on chrome://net-internals/#proxy.
407 in curl, Python and git
In curl the credentials go in the --proxy-user flag or directly in the -x string. Environment variables are read in either case except http_proxy, which curl honours in lower case only, so HTTP_PROXY does nothing for http requests.
In Python the error text misleads: requests raises a ProxyError reading Unable to connect to proxy, while the real cause is a 407. The string Tunnel connection failed: 407 Proxy Authentication Required sits inside it, in the __cause__ attribute. Credentials go straight into the proxies dict: {"https": "http://user:pass@host:port"}.
In git you can keep the password out of the config. Put the username with no password in http.proxy, and git will ask for it through the standard credential helper, the same one it uses for repositories. The scheme is set by http.proxyAuthMethod, which only takes effect when the proxy string contains a username.
If you are on SOCKS5
Chrome does not support username and password authentication for SOCKS5, neither in settings nor through extensions. It connects to such a proxy without credentials, the server rejects it, and no password dialog appears at all, you simply see a connection that does not work.
The way out is an HTTP or HTTPS proxy for the browser, leaving SOCKS5 to tools that can pass credentials: curl, Firefox with an extension, libraries built on PySocks. Proxys.io residential and mobile proxies run over both HTTP(s) and SOCKS, so switching protocol is a settings change rather than a new order.
One last thing that saves a support ticket: a password rejected in a browser but accepted in curl almost always means an encoding error in a config file, not a wrong password.