How to Configure a Proxy in Chrome and Firefox

Most proxy work happens in code, but the browser is where you first check whether a proxy behaves. Routing Chrome or Firefox through a proxy lets you do a few things a bare connection cannot:

• See a page as a specific region does. Load a geo-gated store or search result as if you sat in the US, Germany, or Japan, and confirm the content actually changes.
• Reproduce what your scraper sees. If production traffic leaves through a datacenter or residential IP, browsing from your laptop hides the blocks, prices, and redirects your bot will hit.
• Debug a proxy by eye. Before you wire a proxy into a script, a browser tells you fast whether the IP is alive, whether it is blocked, and what the target renders.

The catch is that "set a proxy in the browser" means two completely different operations depending on which browser you open. Get that wrong and you either change your whole computer by accident or spend an hour wondering why HTTPS pages ignore the proxy.

SparkProxy issues an endpoint in host:port:user:pass form. A datacenter line looks like this:

proxy.sparkproxy.io:10000:sp-user-12345:A1b2c3d4e5

Every dialog below splits those four parts across separate fields, so keep this mapping handy:

If your plan uses IP whitelisting instead of a username and password, you skip the credentials entirely and add your current IP in the dashboard. The trade-off between the two methods is covered in how proxy authentication works and what IP whitelisting is. One protocol note: a standard SparkProxy HTTP endpoint tunnels HTTPS traffic through CONNECT, so you use the HTTP option in every browser field below. Pick SOCKS only if your plan issued a SOCKS endpoint. If that distinction is fuzzy, read HTTP, HTTPS, and SOCKS5 proxy protocols.

Here is the single idea that saves the most time. Chrome does not have a browser-level proxy. Firefox does.

Open chrome://settings/system and click "Open your computer's proxy settings." Chrome does not show you a proxy form. It launches the Windows Internet Options dialog or the macOS Network panel, because Chrome reads its proxy from the operating system. Change it there and you have changed the proxy for Edge, Chrome, Electron apps, and any tool that follows the system setting. That is rarely what you want when you only meant to route one browser.

Firefox is the opposite. Its proxy configuration lives at about:preferences, entirely inside the browser. Choose "Manual proxy configuration" and Firefox ignores the operating system completely. Nothing else on the machine changes.

Read that table once and every step below makes sense. To give Chrome a proxy that does not spill onto the rest of your system, you launch it from the command line. Firefox needs no such trick.

There are two honest ways to set a proxy for Chrome. The GUI path changes your whole system. The launch-flag path keeps the proxy inside one isolated Chrome instance. Pick based on whether you want the machine or just one browser behind the proxy.

Firefox is the friendlier browser for a single-app proxy because everything lives in one dialog and nothing leaks to the OS.

1. Open about:preferences, scroll to the bottom, and under Network Settings click Settings.
2. In the Connection Settings window, choose Manual proxy configuration.
3. For an HTTP endpoint, put proxy.sparkproxy.io in HTTP Proxy and 10000 in Port, then tick Also use this proxy for HTTPS. Older builds label this "Use this proxy server for all protocols"; the effect is the same.
4. Click OK. The change is live immediately for new requests.

The No proxy for box takes a comma-separated bypass list. A sane default:

localhost, 127.0.0.1, ::1

A Proxy Auto-Config file is a small JavaScript file with one function, FindProxyForURL(url, host), that returns which proxy (if any) a given URL should use. It is the cleanest way to say "send these sites through SparkProxy and leave the rest direct." Here is a working example that proxies everything except local addresses:

function FindProxyForURL(url, host) {
  // Local traffic stays direct; everything else uses SparkProxy
  if (isPlainHostName(host) ||
      shExpMatch(host, "localhost") ||
      shExpMatch(host, "127.0.0.1")) {
    return "DIRECT";
  }
  return "PROXY proxy.sparkproxy.io:10000; DIRECT";
}

To route through a SOCKS exit instead, return "SOCKS5 proxy.sparkproxy.io:10000". The trailing DIRECT is a fallback: if the proxy is unreachable, the browser connects directly rather than failing hard. Remove it if you would rather the request fail than leak.

Where you point the browser at that file is, again, split by browser:

• Firefox has a native field. In Connection Settings choose Automatic proxy configuration URL and paste the PAC location, for example https://www.sparkproxy.io/proxy.pac or a local file:///C:/proxy/spark.pac path.
• Chrome has no in-browser PAC field. Set the PAC in the OS "Use setup script" box (Windows) or the "Automatic Proxy Configuration" field (macOS), or push it with the enterprise ProxyPacUrl policy. Chrome then reads it from the system, consistent with everything else about Chrome and proxies.

A PAC file cannot carry a username and password either, so an authenticated proxy still needs the handling below. For the full syntax and more routing patterns, see what a PAC file is and how it works.

The native dialogs give you one proxy for the whole browser and no place to store credentials. A proxy switcher extension fixes both. FoxyProxy is the common pick and ships for Chrome and Firefox.

FoxyProxy Standard lets you:

• Save several proxies, each with host, port, type (HTTP, HTTPS, SOCKS4, SOCKS5), and a username and password stored with the proxy.
• Route by URL pattern, so *.sparkproxy.io goes through one exit while everything else stays direct or uses another.
• Switch the active proxy from the toolbar without reopening any settings dialog.

To add a SparkProxy endpoint: open FoxyProxy options, click Add, enter proxy.sparkproxy.io, port 10000, set the type to HTTP, then fill the username sp-user-12345 and password A1b2c3d4e5. Because the extension answers the proxy's authentication challenge for you, the credential popup never appears. That is the main reason to use it over the launch flag for an authenticated proxy.

FoxyProxy Basic is the stripped-down sibling: it switches between proxies but drops URL patterns. If you only need to flip one proxy on and off, Basic is enough. For per-site routing, use Standard.

A real difference between the browsers shows up here. Firefox exposes a proxy API (browser.proxy.onRequest) that decides the exit per individual request, which is what makes true per-tab and per-container routing possible in Firefox. Pair FoxyProxy or a container proxy add-on with Firefox Multi-Account Containers and each container can hold its own exit IP. Chrome's extension proxy model is coarser and effectively sets one active proxy at a time, so "per tab" in Chrome is really "switch the active proxy as you move between tabs."

This is the part that sends people in circles. You set the host and port, load a page, and Chrome or Firefox throws a dialog asking for a proxy username and password. Type them and it may work for the session, then ask again after a restart. The reason is simple: a username and password proxy uses HTTP Basic proxy authentication, and neither browser's built-in proxy dialog has a field to store those credentials. The --proxy-server flag cannot hold them, and neither can a PAC file.

You have three real ways to deal with it, in order of how much I reach for them:

1. Use IP whitelisting instead of a password. Add your current public IP in the SparkProxy dashboard and drop the credentials entirely. No popup can appear because there is nothing to authenticate. This is the cleanest option on a machine with a stable IP.
2. Let an extension answer the challenge. FoxyProxy (previous section) stores the username and password and responds to the proxy's authentication request before any dialog shows. This is the go-to for a laptop whose IP changes.
3. Run a local auth-forwarding proxy. A small local relay such as a lightweight forward proxy holds the SparkProxy credentials and listens on 127.0.0.1:PORT with no auth. Point Chrome's --proxy-server at http://127.0.0.1:PORT and the relay adds the Proxy-Authorization header upstream. Useful for headless automation where no extension is loaded.

One thing not to do: do not disable authentication by leaving the proxy open to the internet. The password exists so that only you use your allocation. If the popup is the whole problem, whitelist your IP.

Never trust a 200 as proof the proxy worked. Confirm the exit IP directly. Two checks, from fastest to most thorough:

1. Compare the reported public IP. In the proxied browser, open any IP-echo page and read the public IP it reports back. Compare it against the exit ranges listed in your SparkProxy dashboard. If it matches the proxy and not your home connection, routing works. If it shows your own ISP address, the proxy was bypassed. A full checklist for this lives in how to test if your proxy is working.

2. Read the Remote Address in DevTools. Open DevTools with F12, go to the Network tab, reload, click any request, and look at Remote Address in the Headers panel. When you route through a proxy, the browser's socket peer is the proxy, so that field shows the proxy's IP and port rather than the origin server. It is a quick way to confirm the browser is actually talking to the proxy and not falling back to a direct connection.

Two leaks can still expose your real address even with the proxy working:

• DNS leak. Covered above for Firefox SOCKS5 by the DNS checkbox. For an HTTP proxy this is a non-issue, because the browser sends the hostname to the proxy in the CONNECT request and the proxy resolves it. Details and a test in proxy DNS leak testing and mitigation.
• WebRTC leak. A browser can reveal your real IP over WebRTC's direct UDP path, which ignores your HTTP proxy entirely. If you route the browser for privacy, disable or restrict WebRTC. The mechanism and fixes are in what WebRTC leaks are.

Browser proxying is for interactive, manual work. The moment you need many exits, unattended runs, or a target that blocks even a clean proxy IP, the browser is the wrong tool and you switch to a scraping endpoint. The SparkProxy Scraping API is a normal HTTPS call, so no browser or OS proxy is involved at all, and it adds rotation, real-browser rendering, and anti-bot handling behind one request.

Per the SparkProxy Scraping API docs, the base URL is https://scrape.sparkproxy.io/api/v1 and you authenticate with an X-API-Key header:

curl -H "X-API-Key: YOUR_API_KEY" \
  "https://scrape.sparkproxy.io/api/v1?url=https://www.sparkproxy.io&render_js=true&country_code=us&premium_proxy=true"

render_js=true runs the target in a real browser, country_code takes an ISO alpha-2 code for the exit region, and premium_proxy=true routes through residential IPs when a site is strict about datacenter ranges. The same guides that route a browser also route code, so if the browser proxy proves the site is reachable but your script keeps getting blocked, this is the next step, not more browser tweaking.