# Chrome SOCKS5 proxy with username and password

> A Chrome SOCKS5 proxy with username and password fails: Chromium has no SOCKS5 sign-in. Use the seller's HTTP port, allowlist your IP, or relay it.

Source: https://mosaicbrowser.com/guides/chrome-socks5-proxy-with-username-and-password

## Chrome SOCKS5 proxy with username and password

Chrome cannot use a SOCKS5 proxy that needs a username and password, because Chromium's own proxy documentation says no authentication methods are supported for SOCKSv5. Use the seller's HTTP endpoint with the same login, allowlist your IP instead, or run a local relay that signs in for Chrome.

![SOCKS5 with a password, which Chrome cannot send](https://mosaicbrowser.com/covers/chrome-socks5-proxy-with-username-and-password.webp)

Can Chrome use a SOCKS5 proxy with a username and password? Chromium's network documentation has one sentence on it, and it settles the question: "No authentication methods are supported for SOCKSv5 in Chrome (although some do exist for the protocol)" ([proxy.md](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md), read 2 November 2026). The method it skips is RFC 1929, the username and password exchange most proxy sellers use for SOCKS5 ([RFC 1929](https://www.rfc-editor.org/rfc/rfc1929)). So a line like `socks5://user:pass@203.0.113.24:1080` cannot work in Chrome, Edge, Brave or anything else built on Chromium, whichever way you hand it over.

## What happens when you try

There are three places to give Chrome a proxy, and each one fails in its own way.

The system proxy settings on macOS and Windows have a username and password next to the SOCKS proxy. Chromium's documentation says Chrome "does not implement this, and will not use any credentials embedded in the proxy settings".

The `--proxy-server` flag takes a scheme, host and port, such as `socks5://203.0.113.24:1080`, and has no field for credentials.

A proxy extension can point a profile at a SOCKS5 server through the `chrome.proxy` API, but its way to supply a password is the `onAuthRequired` event, which fires on HTTP authentication ([chrome.webRequest](https://developer.chrome.com/docs/extensions/reference/api/webRequest)). Chrome never starts a SOCKS5 sign-in, so the event never fires.

In each case Chrome opens the SOCKS5 connection offering no authentication, the gateway insists on a password, and the connection is refused. No sign-in box appears, which is why this looks like a broken proxy rather than a missing feature.

Mosaic is a desktop app

Email yourself the link and open it on your computer.

[How it works: Provider minting](https://mosaicbrowser.com/features/proxy-providers)

## Three ways to use a SOCKS5 proxy with a username and password anyway

### 1. Switch to the seller's HTTP endpoint

Most sellers who offer SOCKS5 also offer HTTP on the same account, often on a different port. Chrome does sign in to HTTP proxies: the documentation lists Basic, Digest, Negotiate and NTLM. When the page first loads, Chrome shows a sign-in box for the proxy, and HTTPS traffic still goes end to end through a `CONNECT` tunnel. For browsing, you lose nothing that matters.

### 2. Allowlist your IP instead of a password

Some sellers let you register the public IP of your computer and then accept connections from it with no credentials. Oxylabs, for one, lists IP whitelisting beside username and password ([Oxylabs session control](https://developers.oxylabs.io/products/proxies/residential-proxies/session-control)). With that set, `socks5://host:port` works in Chrome as written. The catch is that a home connection's IP can change, and every app on that network can then use your proxy traffic.

### 3. Run a relay on your own computer

A small proxy listening on `127.0.0.1` can accept Chrome's connection with no password and make the upstream SOCKS5 connection with the username and password itself. Chrome talks to the local relay; the relay signs in. This is the only route that keeps a SOCKS5-only line exactly as the seller sold it, and it is what Mosaic does for every profile.

## The limit that stays: UDP

Chrome's SOCKS5 support covers "TCP-based URL requests" only, and "cannot be used to relay UDP traffic". WebRTC uses UDP, so a page can open a WebRTC connection that does not go through the proxy at all, whichever of the three routes you take. [How to fix a WebRTC leak in Chrome](https://mosaicbrowser.com/guides/fix-webrtc-leak-in-chrome) covers the policy settings that stop it.

## How Mosaic handles a SOCKS5 line with a password

In Mosaic every profile whose proxy has a username and password gets its own relay on `127.0.0.1`. The engine connects to the relay with no credentials, and the relay performs the SOCKS5 username and password exchange upstream. There is one relay per profile, never shared between two.

1. Open the profile, and under **Connection › Source** choose **Custom**.
2. Paste the line into **Paste a proxy**. It reads `socks5://user:pass@host:port`, `user:pass@host:port`, `host:port:user:pass` and the other common shapes, which are explained in [proxy format: ip, port, username, password](https://mosaicbrowser.com/guides/proxy-format-ip-port-username-password).
3. Start the profile. Mosaic checks the proxy first and refuses to launch behind one that has not answered and tunnelled, with the reason.

![Creating a profile in Mosaic: a checked proxy, and the hardware and locale drawn to match its exit](https://mosaicbrowser.com/shots/profile-editor.png)
*The proxy is a field of the profile*

With a proxy attached, by default the engine runs with WebRTC limited to proxied traffic, so it cannot send UDP around the proxy. HTTP and HTTPS proxies with a password go through the same relay, so no sign-in box ever appears. For a seller's rotating gateway, [rotating vs sticky proxies](https://mosaicbrowser.com/guides/rotating-vs-sticky-proxies) explains which line to paste, and [the proxy providers page](https://mosaicbrowser.com/features/proxy-providers) shows how one line becomes a separate session per profile.

## Sources

1. [Chromium: Proxy support in Chrome (net/docs/proxy.md)](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md), read November 2, 2026
2. [RFC 1929: Username/Password Authentication for SOCKS V5](https://www.rfc-editor.org/rfc/rfc1929), read November 2, 2026
3. [Chrome for Developers: chrome.webRequest](https://developer.chrome.com/docs/extensions/reference/api/webRequest), read November 2, 2026
4. [Oxylabs Developers: Residential proxies session control](https://developers.oxylabs.io/products/proxies/residential-proxies/session-control), read November 2, 2026

## Questions

### Why does socks5://user:pass@host:port not work in Chrome?

Chrome reads the scheme, host and port and has no way to send the username and password on a SOCKS5 connection. A gateway that requires them refuses the connection, and the page fails to load.

### Can a proxy extension add SOCKS5 credentials?

No. Extensions answer sign-in requests through the onAuthRequired event, which fires for HTTP authentication. Chrome never attempts a SOCKS5 sign-in, so there is no request for an extension to answer.

### Do Edge and Brave behave the same way?

Yes. Both are built on Chromium and use its network code, so a SOCKS5 proxy that needs a username and password fails there as it does in Chrome. The HTTP endpoint and the IP allowlist work in all three.

### Is SOCKS5 more private than an HTTP proxy?

Not by itself. In Chrome, both send DNS lookups to the proxy, and HTTPS stays encrypted end to end through either. Chrome's SOCKS5 support also cannot carry UDP, so neither one covers WebRTC on its own.

## Related

[How to use a different proxy for each Chrome profile](https://mosaicbrowser.com/guides/use-a-different-proxy-for-each-chrome-profile): Chrome has no proxy setting per profile. Use a proxy extension in each profile, or launch Chrome with its own data folder and --proxy-server.

[Proxy format: ip:port:username:password explained](https://mosaicbrowser.com/guides/proxy-format-ip-port-username-password): The usual proxy format is ip:port:username:password. The same four values also come as username:password@ip:port, with or without a scheme in front.

[How to fix a WebRTC leak in Chrome](https://mosaicbrowser.com/guides/fix-webrtc-leak-in-chrome): How to fix a WebRTC leak in Chrome: one setting stops WebRTC sending UDP around your proxy, by policy, flag or Google's extension. Measured: 2 to 0.

[Rotating vs sticky proxies: which one an account needs](https://mosaicbrowser.com/guides/rotating-vs-sticky-proxies): Rotating vs sticky proxies: rotating changes the exit IP per connection, sticky keeps one for a session you name. Logged-in accounts need sticky.

[Provider accounts: one gateway line, one exit per profile](https://mosaicbrowser.com/features/proxy-providers): Paste your proxy seller's gateway line once and Mosaic mints a separate session for every profile, so each one browses from its own exit address.

[What happens to QUIC when Chrome has a proxy](https://mosaicbrowser.com/blog/chrome-quic-through-a-proxy): With an HTTP, HTTPS or SOCKS5 proxy set, Chrome reaches sites over TCP tunnels, so a page that gets HTTP/3 direct gets HTTP/2 through the proxy.



[How to check a proxy before you use it](https://mosaicbrowser.com/guides/how-to-check-a-proxy-before-you-use-it): Check that a proxy answers and tunnels, where its exit really is, whether the address is residential or blocklisted, and that the browser stays behind it.

## Run this guide on your own accounts

Every Mosaic profile is a fingerprint, a proxy exit and a cookie jar that agree with each other, kept on your computer. Free holds 3 profiles. Pro is $49 a month for any number.

Mosaic is a desktop app

Email yourself the link and open it on your computer.