SOCKS5 works everywhere except your browser

The ticket usually arrives with the error pasted verbatim: ERR_SOCKS_CONNECTION_FAILED. Someone has set a proxy extension to SOCKS5, entered their username and password, loaded a page, and been refused instantly. The detail they always add is the strange one — it doesn’t even ask me for credentials.

That last part is the whole answer. The login prompt never appears because the browser was never going to send credentials in the first place. Chromium-based browsers — Chrome, Brave, Edge, Opera, and everything else built on the same engine — cannot authenticate a SOCKS5 proxy. There is no setting to enable, no extension that fixes it, and no combination of fields that will make it work.

It is worth being precise about this, because the failure looks exactly like a broken proxy and sends people hunting in the wrong place for hours.

What the browser actually does with your credentials

When you configure an authenticated proxy in a browser extension, the extension stores a username and password and hands the browser a proxy configuration. For an HTTP proxy, the browser has a well-trodden path for this: it opens the connection, receives a 407 Proxy Authentication Required, and answers with a Proxy-Authorization header. That exchange is old, standard, and universally implemented.

SOCKS5 has an authentication step too — it is defined in the protocol, and plenty of software implements it. Chromium is not among them. The browser’s proxy layer negotiates SOCKS5 with the “no authentication” method only. When the proxy replies that credentials are required, the browser has nothing to offer and the connection is closed before any request is made.

So the credentials sitting in your extension’s SOCKS5 fields are inert. The extension will happily store them and show them back to you, which is why this is so convincing a dead end — everything looks configured. The browser simply never reads them.

This is not an obscure edge case. It has been an open issue against Chromium for years, and the same wall gets hit by anything driving a Chromium browser: Selenium, Puppeteer and Playwright users run into an identical failure whenever they point a Chrome instance at an authenticated SOCKS5 endpoint.

Firefox is the exception worth knowing about. It does implement SOCKS5 authentication, though it prompts in ways that surprise people and does not always persist the answer across sessions. If a colleague insists SOCKS5 works fine in their browser, this is usually why.

Fix one: use HTTP on the same host and port

The fastest fix is to stop asking the browser to do something it cannot do.

Our endpoints accept both HTTP and SOCKS5 on the same host and the same port. There is no separate SOCKS port to look up and nothing to re-provision. In your proxy extension, change the scheme from SOCKS5 to HTTP, leave the server and port exactly as they are, and enter the same username and password.

The browser now has a mechanism it understands. It will authenticate on the first 407 and carry on. Traffic is tunnelled the same way it would have been over SOCKS5, so you are not giving anything up by switching — this is a difference in how the browser announces itself to the proxy, not a difference in what the proxy does with the connection afterwards. We went through the wider trade-off in SOCKS5 or HTTP: which proxy protocol to use, and when, and the short version is that for browser work HTTP is simply the correct default.

Fix two: authenticate by IP instead

The second option removes credentials from the equation entirely.

Add the public IP of the machine running the browser to the whitelist in your dashboard. Once an address is whitelisted, connections from it are recognised without a username and password — which means SOCKS5 now works in the browser, because there is no authentication step left to fail.

This is the right choice when the browser runs somewhere with a stable address: a server, a VPS, an office line. It is the wrong choice on a laptop moving between networks or on a home connection whose address changes, because every change means updating the whitelist before anything works again. Whitelisting or username and password covers when each model earns its keep.

One caution worth stating plainly: a whitelisted address authenticates anything sending traffic from it. On a shared or office network, that is a decision about the network, not just about your browser.

What does support authenticated SOCKS5

Nothing about the failure above suggests SOCKS5 is a second-class option. Outside of browsers it is well supported and often the better pick:

• curl — --proxy socks5h://user:pass@host:port, authentication included.
• Python — requests with PySocks, httpx, and aiohttp via connectors all handle SOCKS5 credentials.
• Proxifier, Shadowsocks-style clients, and most VPN-adjacent tooling — built for exactly this.
• SSH tunnels, database clients, mail clients, torrent clients — routinely authenticate over SOCKS5.

The dividing line is not “modern versus legacy” or “good versus bad software.” It is that browsers made a specific decision about their proxy stack a long time ago, and everything downstream of that decision inherits it.

If your work is in a scraping library or a command-line tool, use whichever protocol your tool prefers and stop thinking about it. If your work happens inside a Chromium browser, use HTTP or whitelist the address.

The thirty-second test

Before changing anything in the browser, confirm from a terminal that the account and credentials are sound. Run the same request twice, once over each protocol:

# SOCKS5 — works from a terminal, credentials and all
curl -x "socks5h://USERNAME:[email protected]:10000" \
     -s -o /dev/null -w "socks5: %{http_code}\n" https://api.ipify.org

# HTTP — same host, same port, same credentials
curl -x "http://USERNAME:[email protected]:10000" \
     -s -o /dev/null -w "http:   %{http_code}\n" https://api.ipify.org

Two 200s tell you the account, the password and the port are all correct, and that both protocols are live on the same endpoint. If those pass and the browser still refuses, the browser is the variable — not the proxy. Switch the extension to HTTP, or whitelist the address, and the error goes away.

If either line returns 407, the password is wrong rather than the protocol. Proxy credentials are shown on your plan page in the dashboard, and the password is not your account login.

The part worth remembering

ERR_SOCKS_CONNECTION_FAILED with no credential prompt is a specific, diagnosable thing: the browser reached the proxy, was asked to authenticate, and had no way to comply. It is not a burned IP, not a blocked port, not a plan problem, and not something a different proxy provider would solve.

Two configurations work in a Chromium browser — HTTP with credentials, or SOCKS5 with a whitelisted address. Both are one change away, and both keep you on the same host and port you already have. Every plan we run accepts HTTP and SOCKS5 on that same endpoint, from Budget Unlimited upward, so this is a settings change rather than anything you need to buy your way out of.