Chrome cannot authenticate to a SOCKS5 proxy, which is why we run a relay

The SOCKS5 protocol negotiates an authentication method before it does anything else. The client offers a list, the server picks one, and username-and-password is method 0x02. Chromium does not offer it. It opens the connection offering no method the server accepts, the server closes it, and what surfaces in the browser is a generic proxy connection failure with no mention of authentication anywhere.

From the operator's chair, three plausible explanations all fit the evidence: the proxy is down, the credentials are wrong, or the subscription lapsed. The actual explanation - that the browser was never able to send them - is the only one that never comes to mind, because software that quietly ignores the credentials you gave it is not the first hypothesis anybody reaches for.

This is a limitation and not a bug report. It has been the state of Chromium's network stack for years, it is the same on every Chromium-derived build, and no flag turns it on.

This is also why the workaround is so widely circulated and so bad: HTTP proxies do support credentials in the argument, so a lot of advice quietly switches you to HTTP. That works, and it puts a password on a command line.

On Windows, a process's command line is readable by other processes on the machine. It appears in process listings, in crash telemetry, in logs that capture how a program was started, and in any diagnostic that dumps the environment.

So the HTTP workaround trades a protocol limitation for a credential exposure, and it does it in a way that never announces itself either. The password works. Everything functions. The exposure is invisible until somebody looks at a process listing.

Ward passes no credentials to any browser it launches, on any protocol. That is not a policy applied by discipline; it is structural, because of what sits in between.

Ward starts a small forwarding proxy on 127.0.0.1 for each running profile, on an ephemeral port, and points the browser at that. The relay holds the upstream credentials and speaks whichever protocol the upstream actually wants - HTTP, HTTPS, SOCKS4, SOCKS4a or SOCKS5, with authentication where the upstream requires it.

The browser sees a local, unauthenticated proxy. The credentials never appear on a command line, never enter the browser process, and are never written anywhere a page could reach.

That solves the protocol problem and the exposure problem with one component, and it buys three further things that were not the original motivation:

1. A place to probe from. Before a profile launches, the relay dials the upstream and reads back the address the traffic exits from. If that fails, the launch refuses. The failure it prevents is a window that quietly browses from the operator's own address while the profile list says it is exiting from another country - the worst thing this product could do, and completely invisible from inside the application.
2. A place to derive the timezone from. The exit address is what the profile's timezone is generated against, so a profile cannot report a timezone that contradicts the address it is arriving from.
3. A lifetime that matches the browser's. One relay per running profile, dying with it. Shutdown order is fixed in one place: the automation API first, then the browsers, then the relays, then the database.

An extra hop on loopback, which is not measurable against the round trip to a residential exit node in another country. One more process-local listener per running profile. And a component that has to be correct, because everything a profile does goes through it.

That last one is the real cost, and it is why the relay is the part of this codebase with the least clever code in it.

And one thing this post is not claiming. The relay's refusal behaviour is proven: point a profile at a dead port and the launch is refused, and eleven different ways of breaking an upstream have been shown not to produce a fallback to a direct connection. A successful exit through a paid, credentialed endpoint has not been run on the machine this was written on - that needs a subscription this project does not have yet. The protocol limitation above is why the relay exists; it is not a report of a session that went through one.

Ask what the browser is pointed at. There are only two honest answers: a local relay, or the upstream proxy directly. If it is the upstream directly and the upstream needs credentials, then either they are on a command line where other processes can read them, or the tool is using HTTP where you asked for SOCKS5, or it is doing something it has not told you about.

And ask what happens when the proxy does not answer. A tool that opens the browser anyway has decided, on your behalf, that a session from your own address is better than no session. It is not, and you should be the one making that call.