The program will not take a proxy login and password: which clients cannot send them, and what to do
There is a class of failures where the password is right and the proxy is alive, yet nothing connects: the client physically cannot send credentials. From the proxy's side that looks exactly like a wrong password, which is why people spend weeks changing the password when what needs changing is the authentication method.
Chrome and Chromium: yes over HTTP, never over SOCKS5
This is written down in Chromium's own documentation. On HTTP proxies: “HTTP proxies in Chrome support the same HTTP authentiation schemes as for target servers: Basic, Digest, Negotiate, NTLM” — the typo is in the original. On SOCKS5, the same document says outright: “No authentication methods are supported for SOCKSv5 in Chrome (although some do exist for the protocol).”
So it is neither your connection string nor the proxy: the support is absent from the browser. Asked on the chromium-dev list how to connect to SOCKS5 with authentication, a networking maintainer answered in one line: “This is not supported.”
Who else cannot send a password
- Electron applications: the docs on --proxy-server state “The proxy URL does not support username and password authentication”.
- Android's system proxy: the ProxyInfo class exposes only host, port and an exclusion list — there is no credential field in the API at all, and no protocol choice either.
- netsh winhttp on Windows: the set proxy syntax takes only a server address and a bypass list; no credential parameter exists.
- The manual proxy screen in Windows Settings: there is no password field on it.
And the ones that handle it fine: Firefox (it prompts for the login and password itself), curl (--proxy-user), iOS (the Wi-Fi settings expose an Authentication toggle with username and password), and macOS, where credentials are first-class arguments of the networksetup command.
# macOS: login and password are ordinary arguments
networksetup -setsocksfirewallproxy Wi-Fi GATEWAY PORT on LOGIN PASSWORD
# Windows: there is no credential parameter here at all
netsh winhttp set proxy proxy-server="GATEWAY:PORT"Why it works in Firefox and not in Chromium
Firefox implements SOCKS5 username and password authentication; Chromium does not. That is the source of the most common puzzle in antidetect browsers: the same proxy string works in one tool and not in another. The cause is not the tool but its engine — Chromium-based browsers have to build their own layer over the proxy for authenticated SOCKS5 to work at all, while Firefox-based ones get it from the engine.
The check: proxy or client
Before changing settings, separate the two. curl can pass credentials independently of the address, so its answer speaks only about the proxy.
# socks5h, not socks5: the h means the proxy resolves names —
# which is what a browser does, so the DNS path matches production.
curl -x socks5h://GATEWAY:PORT -U LOGIN:PASSWORD https://example.com -o /dev/null -w '%{http_code}\n'
# The same credentials on the HTTP port:
curl -x http://GATEWAY:PORT -U LOGIN:PASSWORD https://example.com -o /dev/null -w '%{http_code}\n'
# 200 on both -> proxy and credentials are fine, the client is the problem.
# 407 -> the credentials are the problem, the client is irrelevant.The fix: authenticate by IP
If a client cannot send a password, stop requiring one. With address-based authentication the machine's IP goes on a whitelist and the proxy recognises the client by the connection itself — only host and port remain in the settings, and the password field stays empty. This is not a workaround but the second supported authentication method.
Both methods are active at once here, so nothing has to be switched and no support ticket is needed: a server runs on the whitelist while scripts on a laptop keep using login and password.
When a whitelist is the wrong choice
- A home address from an ISP changes — the whitelist then needs updating, and the job will stop at the least convenient moment. For those cases the address is updated with an API request.
- A shared or NAT'd network: other people sit behind the same external address, and a whitelist opens access to all of them. Here you want a login and password, and a client that can send them.
About the local relay
The workaround forums recommend: run a local proxy without authentication that upstreams to ours with credentials. It works, but it is an extra hop and a second point of failure — when something breaks you now debug two places instead of one. With a whitelist available there is usually no reason for it.
Both authentication methods at once
Login with password and IP whitelist run in parallel on every plan — there is nothing to choose between. Rotating IPv6 from 650 ₽ for 50 threads, static IPv4 from 300 ₽.
View pricingProxies for this job
Check it with our tools
Read next
- Proxy authentication by IP or by login: when to use whichThe two schemes solve different problems. Where a whitelist is the only option, where a password is safer, and why keeping both beats choosing.
- One gateway instead of a proxy list: configuring software that expects a listScrapers measure scale by proxy count, and a rotating gateway is one line. Program by program: which mode to switch, where to duplicate the line, and where the honest answer is to buy a list.
- 403 through a proxy: the site refused, the proxy refused, or the address is not the problemA 403 can come from the proxy or from the target site, and they cannot always be told apart. Where to find the Cloudflare code, which codes no address change will fix, and why proxy headers are a poor test.