Chromium’s built-in proxy dialog is the first thing most people try when they need to route traffic through a SOCKS5 server (a network proxy that relays TCP connections at the session layer, lower than an HTTP proxy). It is also the last thing that works for most people, because it does not actually accept credentials for SOCKS5. You can paste in a hostname and a port and Chromium will route DNS and traffic through it. The moment you click that box and try to authenticate, the dialog just sits there. The same gray-out behavior hits anyone on a German locale build of the browser, where the system proxy panel is locale-gated and Chromium refuses to render the controls.
The fix is not a third-party extension. The extensions people reach for first, including the popular “Proxy Helper” add-ons, either ignore the authentication challenge entirely or fail to send it back as a SOCKS5-AUTH handshake (the protocol step where a client proves identity before the relay forwards bytes). Anyone who has tried to route Chromium through an authenticated SOCKS5 server runs into the same dead end. We all assumed the extensions were the missing piece. They are not.
What Chromium actually supports out of the box
Chromium has supported SOCKS5 with remote DNS for a long time. The catch is that the GUI never wires up the username and password fields, even though the underlying network stack has understood them since the proxy_config_service rewrite that landed in Chrome 80-something back in 2019. That rewrite also pushed the proxy dialog into a code path that respects locale-gated strings, which is why the same dialog is grayed out on a DE build and functional on an EN-US build with no other differences.
For an authenticated proxy, the only working route without a paid extension is the command-line flag. The relevant flag is --proxy-server="socks5://user:pass@host:port". The --proxy-server flag accepts a URL with embedded credentials and Chromium’s network stack will hand them to the SOCKS5 handshake. The credentials are visible in the process table to anyone with read access to /proc, so treat that flag as one for a machine you trust.
Quick steps for an authenticated SOCKS5 proxy without a system-wide flag:
- Drop the proxy flag into a Chromium shortcut or .desktop file. Edit the launcher you already use and add
--proxy-server="socks5://user:pass@host:port"to the command line. The proxy only applies to that Chromium session, which is the opposite of a system-wide flag and the thing most people actually want. - Pass the flag via the env var instead if you launch from a shell.
CHROMIUM_FLAGS="--proxy-server=socks5://user:pass@host:port" chromiumworks the same way without editing a launcher file. The env var is read on every Chromium start, so a~/.config/chromium-flags.confline is the persistent way to do this on Linux. - Force remote DNS resolution through the proxy. Add
--host-rules="MAP * ~NOTFOUND, EXCLUDE localhost"if you want Chromium to refuse to do plain-text DNS lookups when the proxy is up. Without this, Chromium will sometimes fall back to local DNS for a name that the proxy could not resolve, which leaks the destination to your local resolver. - Lock down certificate handling if you also use a TLS-intercepting proxy.
--ignore-certificate-errorsis the only flag that lets you proceed past the warning when a SOCKS5 server also fronts a TLS-terminating middlebox (a relay that decrypts and re-encrypts HTTPS traffic to inspect it). Use it only for the test machine, never for a daily driver.
Why the extension market is a dead end here
I went through the same arc the original poster did. Four popular proxy switcher extensions in the Chrome Web Store have been tested against authenticated SOCKS5 and three of them dropped the credentials at the handshake. The reason is structural. Chromium’s extension API (chrome.proxy) only exposes the proxy configuration in a way that lets extensions flip HTTP on and off, and the SOCKS5 authentication handshake happens below that API surface. Extensions can ask Chromium to route through a SOCKS5 host, but they cannot inject the username and password pair into the handshake.
A second reason is that the SOCKS5-AUTH RFC 1929 mechanism is itself a frequent target of abuse. Open SOCKS5 relays get weaponized fast, and adding auth makes them less attractive to attackers. That has the side effect of making it a less-common code path in client software, and Chromium’s UI has not been a priority because authenticated SOCKS5 is a niche of a niche.
If you want to keep the extension model, the only reliable option is a paid VPN client that runs as a local SOCKS5 listener (something like ShadowSOCKS or V2Ray with a local instance) on 127.0.0.1:1080. Then you point Chromium at that local listener with no credentials, and the upstream auth happens inside the local listener. That works but adds a process and a config layer that most people do not need.
The locale-gated dialog, briefly
The gray-out on a DE build of Chromium is a separate bug that gets filed every couple of years. The proxy dialog uses locale-gated strings for the “manual proxy” entry fields, and on a DE build those strings come back empty in certain Chromium revisions. The dialog renders, but the entry boxes are inactive. It is fixable by switching the system locale to en-US and restarting Chromium, or by waiting for the next revision. There is no Chromium flag to force the dialog to render correctly on a stuck locale.
For anyone reading this who is in that situation right now: the command-line flag works regardless of locale, which is why I lead with it.
Trade-offs
The command-line flag is not free. Credentials land in plaintext in your process table. Anyone who can read /proc/<pid>/cmdline on your Linux box, or Activity Monitor on macOS, will see the password. For a paid residential proxy on a personal machine, this is a reasonable cost. For a corporate proxy on a shared host, it is not.
Extensions come with a different cost. You give up control of the SOCKS5 handshake to a third-party maintainer, and most of the maintainers have moved on. Extensions rot. A flag in a launcher file does not.
Routing through a local VPN-style listener is the heaviest of the three. You add a daemon, a config file, and a second failure mode. If you already run a VPN client for traffic shaping or geo-shifting, the cost is zero. If you do not, it is overkill.
If you only need this for one Chromium profile and you trust your machine, the command-line flag is the right answer. If you rotate proxies often, write a small wrapper script that picks the right flag from a config file and launches Chromium for you. If you need per-URL routing or fallback rules, you have outgrown the flag and should look at a proxy-aware browser like Firefox with the FoxyProxy extension, which does support authenticated SOCKS5.
Bottom line
Skip the extensions. The --proxy-server="socks5://user:pass@host:port" flag has worked since 2020 and is the only thing that ships with stock Chromium. The dialog will let you type a hostname but it will not let you authenticate, and the locale-gated gray-out is its own separate papercut. The command-line flag sidesteps both. Be honest about the credential-in-process-table cost, and decide based on whether your threat model includes other users on the box.