Easiest Way to Change Your Proxy Settings in Google Chrome

Chrome's "Open your computer's proxy settings" button is the whole feature. On desktop, Chrome delegates to the operating system, so changing it in Chrome changes it for Slack, your package manager, and everything else that reads system configuration.

That is fine if you want the machine on a proxy. It is wrong if you want one browser, or one profile, on one — which is what most people asking this question actually want. Four approaches, from least to most isolated.

1. System settings (affects everything)

Windows 11. Settings → Network & internet → Proxy → Manual proxy setup → Edit. Address gate.fleetproxy.com, port 8080. Add localhost;127.0.0.1;*.internal to the bypass list or local development will start routing through the proxy and failing.

macOS. System Settings → Network → your active interface → Details → Proxies → enable "Web Proxy (HTTP)" and "Secure Web Proxy (HTTPS)". Same host and port in both.

Ubuntu/GNOME. Settings → Network → Network Proxy → Manual.

Chrome will prompt for the username and password on the first request and remember them for the session. This is the fastest route to "it works" and the wrong one for daily use, because you will forget it is on.

2. A separate Chrome profile with command-line flags (recommended)

--proxy-server applies to one Chrome instance. Pair it with --user-data-dir and you get a fully separate browser — separate cookies, separate cache, separate everything — running through the proxy while your normal Chrome stays direct.

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --proxy-server="http://gate.fleetproxy.com:8080" \
  --user-data-dir="$HOME/chrome-profiles/us-exit"

# Windows (PowerShell)
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --proxy-server="http://gate.fleetproxy.com:8080" `
  --user-data-dir="C:\chrome-profiles\us-exit"

# Linux
google-chrome \
  --proxy-server="http://gate.fleetproxy.com:8080" \
  --user-data-dir="$HOME/chrome-profiles/us-exit"

Chrome shows a credential dialog on the first proxied request. Enter the full targeting username — user-country-us — and the password, and tick "remember" for the life of that profile.

Useful companions:

• --proxy-bypass-list="<local>;*.internal;127.0.0.1" keeps local development direct.
• --incognito for a clean jar each launch, at the cost of re-entering credentials.
• One --user-data-dir per exit country gives you several browsers, each pinned to a market, all runnable at once.

--proxy-server does not accept credentials in the URL. Chrome strips userinfo from that flag; it has to come from the dialog or from approach 3 or 4.

3. An extension (per-profile, no dialog)

A proxy-switching extension sets the proxy through Chrome's own extension API and can supply credentials programmatically, so no dialog appears and switching between exits is a two-click operation. It applies to the Chrome profile it is installed in, which is exactly the granularity most people want.

The cost is trust: the extension sees every URL you visit and holds your proxy password. Install one with a visible source repository and a permission list you have read, keep it in a profile that does not hold your primary accounts, and do not install one because it was the first search result.

Configuration is always the same three fields — scheme HTTP, server gate.fleetproxy.com, port 8080 — plus the username and password.

4. A local authenticating relay (best for automation)

If you are driving Chrome from Puppeteer, Playwright, or Selenium, the credential dialog is a genuine obstacle: it is native UI and there is nothing to click from inside the page. The clean fix is a local proxy with no authentication that forwards to the authenticated upstream. Chrome talks to 127.0.0.1, the relay handles the credentials.

# One-off with mitmproxy
mitmdump --mode upstream:http://gate.fleetproxy.com:8080 \
  --set upstream_auth=user-country-us:pass \
  --listen-port 8081

# Then point Chrome at the local relay
google-chrome --proxy-server="http://127.0.0.1:8081" \
  --user-data-dir="$HOME/chrome-profiles/automated"

Playwright avoids the problem entirely, because it accepts credentials directly:

import { chromium } from "playwright";

const browser = await chromium.launch({
  proxy: {
    server: "http://gate.fleetproxy.com:8080",
    username: "user-country-us",
    password: "pass",
  },
});

const page = await browser.newPage();
await page.goto("https://api.fleetproxy.com/v1/ip");
console.error(await page.textContent("body"));
await browser.close();

Verify, then check for leaks

Load a page that echoes what the server sees:

curl -x http://user-country-us:[email protected]:8080 \
  -s https://api.fleetproxy.com/v1/ip

Then open the same URL in the proxied Chrome. The country should match your targeting segment.

Two leaks to close afterwards. WebRTC can reveal your real address through STUN regardless of the proxy — test it and disable WebRTC in that profile if the address shows. DNS may still resolve locally on an HTTP proxy; if that matters for your work, use the SOCKS5 endpoint on port 1080 with remote resolution instead.

Which to choose

Casual, occasional use: system settings, and turn them off afterwards. Regular use on one machine: a dedicated --user-data-dir profile per exit. Frequent switching: an extension you have vetted. Automation: a local relay, or Playwright's built-in credentials. The one to avoid is the system-wide setting left on for months, quietly routing your package manager through a metered residential exit.