How to Configure a Proxy in Chrome, Firefox and macOS

Chrome reads the OS proxy settings and Firefox keeps its own, and a browser leaks in ways a script never does. Set it up, verify it, close the leaks.

Pointing a script at a proxy is one line of configuration. Pointing a browser at one is a different job, because a browser is not a single program making requests. It is an operating-system citizen with a media stack that opens its own sockets, a resolver that looks things up before you click, and a cookie jar that knows exactly who you are. Getting the IP to change is the easy half.

This guide covers where the proxy setting actually lives on each platform, why Chrome and Firefox behave differently, how to scope a proxy to one browser profile instead of the whole machine, PAC files for conditional routing, and the three leaks that can undo the whole exercise after the IP check passes.

Everything below assumes you have a host, a port and a credential from the Proxies page of your dashboard. If you have not picked a product yet, datacenter proxies are the usual starting point for ordinary browser work.

One setting or two: system-level versus browser-level

There are two places a proxy can be configured, and which one your browser reads decides how far the setting reaches.

Chrome, Edge, Safari and almost everything else use the operating system's proxy configuration. Chrome has no proxy settings of its own: chrome://settings → System → "Open your computer's proxy settings" is a button that opens the OS dialog and nothing more. This is a deliberate design decision: Chromium delegates proxy resolution to the platform so that one network configuration governs every application. But it has a consequence people trip over constantly: changing "Chrome's" proxy changes the proxy for your mail client, your update daemons and every other browser on the machine.

Firefox ships its own networking stack and its own proxy implementation. By default it is set to "Use system proxy settings", so it looks like it behaves the same way, but flipping it to "Manual proxy configuration" gives you a proxy that applies to Firefox alone and leaves the rest of the machine untouched.

That difference is the reason a common working setup is: personal traffic in Chrome directly, proxied work in Firefox, and nothing at the system level at all.

Windows

Settings → Network & Internet → Proxy → Manual proxy setup. Turn "Use a proxy server" on, enter the host and the port from your dashboard, and save. The "Don't use the proxy server for addresses beginning with" box is a bypass list: local addresses and your own intranet belong there.

Windows gives you no field for a username or password. Credentials are negotiated per-application: the first proxied request the browser makes comes back with an authentication challenge, the browser shows a login popup, and what you type is cached for the session. Type the credential shown on the row of the product you are connecting to. The popup reappearing in a loop almost always means the credential belongs to a different product, which is cause number one in fixing a 407.

If the popup annoys you, the cleaner fix is IP whitelisting: register your public address once and the challenge never appears, because the proxy recognizes where the connection comes from. It works on every product. Residential has one wrinkle worth knowing before you rely on it: a whitelisted residential connection sends no username at all, and the username is where country, city and session targeting live, so you get an untargeted exit. If you need targeting there, the popup is still the way in and an extension that fills it is the answer.

macOS

System Settings → Network → select the active interface → Details → Proxies. Enable Web proxy (HTTP) and Secure web proxy (HTTPS) and put the same host and port in both; a frequent mistake is filling only the first and then wondering why only unencrypted sites are proxied. macOS does provide username and password fields, so the credential can be stored here rather than typed into a popup.

Two macOS specifics worth knowing. The configuration is per network service: a proxy configured while on Wi-Fi does not follow you to Ethernet. And the same panel offers a SOCKS proxy entry, which is a different protocol with its own behavior; if you plan to use it, read SOCKS5 setup first, because the DNS handling differs in a way that matters.

Linux

On GNOME: Settings → Network → Network Proxy → Manual. KDE has an equivalent under Connections. Desktop browsers launched from the applications menu read this.

The environment variables http_proxy, https_proxy and no_proxy are a separate mechanism that governs terminal programs (curl, wget, package managers), and they accept credentials inline in the form http://user:pass@host:port. Exporting them in a shell does not affect a browser that is already running, or one launched from the desktop, which inherits the desktop session's environment rather than your terminal's. Treat the two mechanisms as unrelated and configure whichever layer your tools actually read.

Scoping a proxy to one Chrome profile

Because Chrome defers to the OS, its settings UI cannot give two profiles different proxies. There are two honest ways around that.

The first is a command-line flag:

chrome --proxy-server="http://HOST:PORT" --user-data-dir="C:/profiles/proxied"

The flag applies to that instance only, and the separate --user-data-dir keeps its cookies and cache away from your everyday profile. Chromium refuses credentials inside the flag (user:pass@host is ignored there), so you will still get the login popup once per session, or you can whitelist your IP and skip it.

The second is an extension. FoxyProxy and its relatives use the browser's proxy extension API to override the OS setting while the extension is active, and they can switch per-pattern: requests to one domain through the proxy, everything else direct. Two cautions. In Chrome an extension's proxy setting applies to the whole browser instance, not per-tab, whatever the UI implies. And an extension holding the proxy permission sits in the path of every request you make, so install one with a reputation you have checked, because you are handing it your traffic.

Firefox's manual configuration

In Firefox: Settings → search "proxy" → Network Settings → Manual proxy configuration. Fill the HTTP Proxy field and tick "Also use this proxy for HTTPS". The SOCKS Host field is for a different protocol and should stay empty unless you mean it. The checkbox labeled "Proxy DNS when using SOCKS v5" only applies to SOCKS configurations, but remember it exists; it decides where hostname lookups happen, and leaving it unticked is the classic DNS leak.

Firefox profiles (about:profiles) each carry their own network settings, so two Firefox profiles genuinely can run two different proxies side by side, something Chrome's own settings cannot do.

PAC files: routing by rule

A proxy auto-configuration file is a JavaScript function the browser calls for every URL, and it is the right tool when "everything through the proxy" is too blunt:

function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, ".target-site.com")) {
    return "PROXY HOST:PORT";
  }
  return "DIRECT";
}

Serve the file over HTTP somewhere the browser can reach and point the OS "automatic proxy configuration" (or Firefox's equivalent field) at its URL.

The failure mode to respect: when a PAC file has a syntax error, or its URL is unreachable, browsers quietly fall back to DIRECT. There is no error page. Your real address is used for everything and nothing tells you. After any PAC edit, verify; never assume.

Verify it before you trust it

Open an IP echo service in the browser you configured:

https://api.ipify.org

It should print the proxy's address, not yours. Then check the scope is what you intended: open the same URL in another browser, or in a profile you did not configure, and confirm it still shows your real address. A system-level setting that was meant to be browser-level shows up here immediately.

Do this check in the browser itself. A curl from a terminal exercises a completely different configuration path, and passing there proves nothing about what Chrome is doing. If the browser cannot load pages at all after the change, work through connection issues before touching anything else.

The leaks a browser has that a script does not

A script makes the requests you wrote and no others. A browser does more, and three of its behaviors can identify you while the IP check above still passes.

WebRTC. Real-time media negotiation sends STUN packets outside the proxy path, and any page's JavaScript can trigger it and read back the addresses it discovers, including your real public one. In Firefox, set media.peerconnection.enabled to false in about:config. Chrome will not fully disable WebRTC from its settings; you need its IP-handling policy applied through an extension or enterprise policy. Then test on a WebRTC leak checker page, because this leak is invisible in an ordinary IP echo.

DNS. With a manual HTTP proxy the hostname travels to the proxy inside the request, so the proxy does the lookup, which is good. But browsers also prefetch DNS for links on the page you are reading, and those lookups go through your system resolver, which means your ISP's resolver logs hostnames you never actually visited through the tunnel. Firefox exposes network.dns.disablePrefetch; Chrome buries prefetching under its preload settings. SOCKS configurations leak harder by default; the Firefox checkbox above exists precisely for this, and the SOCKS5 guide explains what is actually being decided.

The session itself. If you sign in to an account, the site knows who you are, and no IP change alters that. Cookies, localStorage and cached tokens carry identity across address changes; a target correlating one account across five exit IPs learns about the IPs; it does not forget the account. If separation is the point, use a fresh browser profile per identity, and treat "logged in" as equivalent to "identified" no matter what the address says.

None of this means browser proxying is futile. It means the IP is one signal among several, and the other signals are yours to manage.

Which product fits browser work

Browsing through a proxy is low-volume compared to automation, so most plans stretch a long way. Shared proxies are the economical choice for ordinary sites; move to residential when the target treats datacenter ranges with suspicion. Some will, and no configuration on your side changes that. To sanity-check a setup before paying anything, the free tier on the pricing page provisions 3 free shared proxies with 1 GB/month bandwidth and 10 concurrent threads, enough to walk through every verification step in this guide against a real endpoint.