Skip to content
Advanced / 6 min read

How to Use a SOCKS5 Proxy in Chrome with a Username and Password (Local Bridge Method)

Chrome cannot send SOCKS5 credentials, so authenticated proxies fail out of the box. This guide builds a local bridge with gost or Privoxy that holds your IPRoyal username and password and routes Chrome through the proxy.

Windows macOS SOCKS5 Privacy/Anonymity

Overview

Chrome and other Chromium browsers can use a SOCKS5 proxy through the --proxy-server flag, but they cannot send a SOCKS5 username and password. There is no credentials dialog for SOCKS5 in Chrome, and the common proxy extensions authenticate HTTP and HTTPS proxies only. If your proxy requires a login, Chrome either fails with ERR_PROXY_CONNECTION_FAILED or connects without credentials and gets rejected.

The fix is a local bridge: a small forwarder that listens on 127.0.0.1, accepts unauthenticated traffic from Chrome, and forwards it to the authenticated upstream SOCKS5 endpoint. Chrome never sees the credentials, and the browser's network stack never talks to the upstream directly.

How each proxying method behaves in Chrome

Method Handles SOCKS5 credentials Notes
--proxy-server="socks5://..." flag No Resolves DNS at the proxy, but fails when the upstream requires auth
OS or system proxy setting No Same limitation, and it affects every app rather than one browser profile
Proxy extension No Most extensions support HTTP and HTTPS auth only
IP allowlist on the provider Not needed Only works if your plan and configuration support it
Local bridge (this tutorial) Yes Credentials stay on your machine; Chrome talks to localhost

Prerequisites

  • A Chrome or Chromium install you can launch from the command line
  • IPRoyal SOCKS5 credentials: gateway host, port, username, password from your dashboard
  • A local forwarder: gost (recommended) or Privoxy
  • Permission to run a listener bound to 127.0.0.1

Steps

  1. Check whether IP allowlisting removes the problem entirely. Some providers let you authorize a fixed IP address instead of sending credentials. Open your IPRoyal dashboard and confirm whether that option exists for the plan you are using. If it does, and your public IP is stable, you can skip the bridge and use the --proxy-server flag directly.

  2. Install a local forwarder. gost speaks SOCKS5 in both directions and ships as a single binary, which makes it the simplest choice.

  • Windows: download the gost binary from its official releases page and add it to your PATH
  • macOS: install gost with your package manager if a package is available, otherwise download the binary
  • Linux: install the binary from the release page, or use a distribution package if one is available
  1. Start the bridge. It listens on a loopback port with no authentication and forwards everything to the authenticated upstream.
gost -L socks5://127.0.0.1:1080 -F 'socks5://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT'

On Windows PowerShell, quote the upstream URL:

gost -L socks5://127.0.0.1:1080 -F "socks5://USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT"

Leave this process running in its own terminal window while you browse.

  1. Verify the bridge before you touch Chrome. This request goes through the bridge, so the returned address should be the proxy exit IP, not your ISP address.
curl --socks5-hostname 127.0.0.1:1080 https://api.ipify.org

If the command hangs, the bridge is not forwarding. If it returns an authentication error, the upstream credentials are wrong.

  1. Launch Chrome through the bridge. Use a dedicated profile so your daily browsing stays untouched and the flag cannot leak into your normal session.

macOS:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --proxy-server="socks5://127.0.0.1:1080" \
  --user-data-dir="$HOME/.chrome-proxy-profile"

Linux:

google-chrome \
  --proxy-server="socks5://127.0.0.1:1080" \
  --user-data-dir="$HOME/.chrome-proxy-profile"

Windows:

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --proxy-server="socks5://127.0.0.1:1080" `
  --user-data-dir="$env:TEMP\chrome-proxy-profile"

  1. Confirm the exit IP inside Chrome. Open an IP lookup page in the new window and compare the address with the one curl returned. They should match. If Chrome shows your real IP, see the troubleshooting section.

  2. Make a reusable launcher so you do not retype flags. On macOS or Linux, save the command in a shell script or alias. On Windows, create a shortcut whose target includes the flags and the --user-data-dir path.

  3. Rotate by restarting the bridge with a new upstream identity. The bridge holds one upstream identity for as long as it runs, so changing the exit IP, or moving to a country-specific endpoint from your dashboard, means stopping gost, starting it again with the new targeting string, and reloading Chrome.

Alternative: Privoxy as the front end

If you need an HTTP proxy in front of the SOCKS5 upstream, because a tool or extension you use only speaks HTTP proxies, Privoxy can do the conversion.

Add these lines to its config file:

listen-address 127.0.0.1:8118
forward-socks5t / USERNAME:PASSWORD@GATEWAY_HOST:GATEWAY_PORT .

Then point Chrome at the local HTTP listener:

google-chrome --proxy-server="http://127.0.0.1:8118" --user-data-dir="$HOME/.chrome-privoxy-profile"

forward-socks5t keeps DNS resolution on the proxy side, which matters when you are checking region-specific content.

Troubleshooting

  • ERR_PROXY_CONNECTION_FAILED: the bridge is not running, the port is wrong, or Chrome is pointed at the upstream endpoint instead of 127.0.0.1.
  • Chrome ignores the flags: an existing Chrome process may have swallowed the new window. Quit every Chrome window and background process, then relaunch. A distinct --user-data-dir prevents this.
  • Pages load but show your real IP: confirm you are in the profile you launched with the flag. Extensions that control proxy settings, enterprise policy, and PAC scripts can override the command-line proxy.
  • Credentials rejected upstream: percent-encode special characters in the password (@ becomes %40, : becomes %3A) or pass the upstream as separate options if your forwarder supports them.
  • Some sites stall on first load: SOCKS5 forwarding covers TCP, not UDP, and Chrome may try QUIC over UDP. Launch with --disable-quic if a site times out before rendering.
  • WebRTC exposes local addresses: SOCKS5 proxying does not cover WebRTC. Set WebRTC IP handling to disable_non_proxied_udp through enterprise policy, or manage it with a browser policy or extension.
  • Bridge reachable from your network: always bind to 127.0.0.1, never 0.0.0.0. Anyone who can reach the listener can use your proxy account.

Summary

Chrome cannot send SOCKS5 credentials, so the practical answer is a local bridge: gost or Privoxy listens on loopback, holds the IPRoyal username and password, and forwards Chrome's traffic to the authenticated SOCKS5 upstream. Verify the exit IP with curl before launching the browser, use a separate --user-data-dir, and restart the bridge whenever you need a new IP or a different country.