Why Chrome Keeps Asking for a Proxy Username and Password

In short: Chrome shows its proxy sign-in dialog when a proxy answers with status 407, Proxy Authentication Required. Chrome takes no credentials from its proxy settings or launch flags, so you type them into the dialog or an extension supplies them. A dialog that returns after you sign in most often means the proxy rejected what you sent. A SOCKS5 proxy that needs a password cannot work in Chrome, which implements no SOCKS5 authentication.

Chrome keeps asking for a proxy username and password when the proxy demands a sign-in that Chrome has no other way to answer. Four situations lie behind the trouble, and three of them have a fix inside Chrome. The fourth, a SOCKS5 proxy with a password, needs a change on the proxy’s side or another browser.

What does the proxy sign-in dialog mean?

The proxy refused to forward your request until you sign in. In HTTP terms it answered with status 407, Proxy Authentication Required, which RFC 9110 describes as meaning “the client needs to authenticate itself in order to use a proxy for this request”. The proxy names the sign-in methods it accepts, and the browser may repeat the request with credentials.

Chrome collects them in a dialog titled “Sign in”. Its text, in Chromium’s dialog strings, is “The proxy $1 requires a username and password.”, with the proxy’s address in place of $1. For HTTP proxies Chrome supports the Basic, Digest, Negotiate and NTLM methods, listed in Chromium’s proxy notes.

Why does Chrome keep asking for the proxy password?

Most often the proxy rejected the credentials and answered with a fresh 407, so Chrome asks again. A wrong password, a username copied with a trailing space, or an account the provider has suspended all look the same from the browser’s side.

The dialog also returns when the password sits somewhere Chrome does not read, such as the proxy settings, and when an extension that stores it has not been given permission to answer. A SOCKS5 proxy with a password behaves differently: Chrome shows no dialog for it, and the connection fails. The “Find your case” table lists all four situations with what to do about each.

Why is the password in the proxy settings ignored?

Chrome does not read credentials written into proxy settings. Many systems let you enter a username and password there, or write them into the address as user:password@host:port, and Chromium’s proxy notes are explicit: “Chrome does not implement this, and will not use any credentials embedded in the proxy settings.” Authentication goes through the usual sign-in flow, and for most people that flow is the dialog.

A proxy set with the --proxy-server launch flag is one more way of entering manual settings, so a password written into the flag has no effect either.

How can an extension answer the dialog for you?

Chrome lets an extension reply to a proxy’s sign-in request before the dialog appears. The webRequest API raises an onAuthRequired event whose isProxy flag is true when a proxy is asking, and an extension with the webRequestAuthProvider permission can reply with the username and password.

Our free ProxyJam Connector uses this event. You store a username and password in each proxy profile, and the extension answers for the saved proxy whose host and port match the one asking.

• On Chrome it answers once you grant network access on its Settings page; until then the browser’s own dialog appears as usual.
• When the proxy rejects the credentials twice for the same request, Connector stops retrying and its toolbar badge shows AUTH.
• It answers for HTTP and HTTPS proxies. A SOCKS5 profile with a username and password gets a warning, since Chrome cannot use them.

Can Chrome use a SOCKS5 proxy with a password?

No. Chromium’s proxy notes state that “No authentication methods are supported for SOCKSv5 in Chrome (although some do exist for the protocol)”, and none for SOCKS4. Chrome’s SOCKS5 client offers the proxy only the method that needs no credentials, so a proxy that insists on a password refuses the connection. The extension API has no event for a SOCKS sign-in that an extension could answer.

What works:

1. Register your address with the provider. Some proxy providers can admit connections from a list of IP addresses you give them, with no password.
2. Use the provider’s HTTP endpoint. If the same proxy also accepts HTTP connections, Chrome can sign in to it through the dialog or an extension.
3. Use Firefox for that proxy. Firefox’s extension API passes a username and password for SOCKS proxies (MDN’s ProxyInfo reference). Connector’s Firefox build uses it, and it installs from Firefox Add-ons.

Where do you go from here?

If you switch between several proxies that need passwords, an extension that stores each one’s credentials answers for them on HTTP and HTTPS, and the extension page lists what Connector does on Chrome. To send only some sites through such a proxy, see sending only some sites through a proxy. The extension rules that changed for every switcher are in what Manifest V3 changed for proxy extensions.

If you are choosing proxies for Connector, read what an ISP proxy is: ProxyJam sells static residential (ISP) proxies on the ISP proxies page, with prices on the pricing page.