To see how a site treats two different exits, send it through two proxies and put the results side by side. In the ProxyHive browser extension, per-site rules route each host through the proxy you pick, and in Firefox, containers can each have their own proxy, which lets the same page load through two exits at once in two tabs. That is enough to answer "do these two exits get the same page?" quickly and by eye. It is not enough to say which proxy is better, and the reasons are worth knowing before you trust what you see.

The rules below come from the extension's routing code, version 0.3.0. The setup guide covers installing it and connecting a first proxy.

What a side-by-side can answer

Good questions for this setup are about what a site serves to a given exit:

  • Does the site load at all through proxy A, and through proxy B, or does one get a block page or a captcha?
  • Do the two exits see the same currency, language, prices or stock? A site that geolocates by IP shows it here first.
  • Does the site's own idea of your country match the country on the proxy's label?
  • Does one exit get redirected to a different regional storefront?

Each of these has a visible answer on one page load, and that is what a manual comparison is good for. Pick targets you are allowed to look at, and check our allowed-use policy before you point anything automated at them.

How per-site routing decides

Per-site mode is a list of rules, each a host pattern and the proxy it goes through:

  1. The rules are checked from the top. The first rule that matches a request decides, so put narrow patterns above broad ones.
  2. A request that matches nothing goes to the Every other site fallback, which is either a proxy or direct.
  3. Patterns match host names: shop.example matches that host exactly, and *.shop.example matches every subdomain but not the bare host. List both when you need both. IPv4 ranges such as 10.0.0.0/8 and <local> for plain host names also work.
  4. A rule names one proxy and nothing else. If that proxy stops answering, the sites behind it fail; they are not quietly sent out on your own connection.

The consequence for comparisons: routing is by host, not by tab. While a rule sends shop.example through proxy A, every tab that opens shop.example uses proxy A. One host cannot go through two proxies at the same moment with rules alone.

Three ways to get two arms

Two host names of one site. Many sites answer on more than one name: a regional storefront such as de.shop.example beside fr.shop.example, or a mobile host beside the main one. Give each name its own rule and its own proxy, and open both. This is the quickest setup, with one caveat you must keep in mind: they are different pages, so a difference may be the site's, not the exit's.

RuleGoes through
de.shop.exampleGermany ISP
fr.shop.exampleFrance ISP
Every other siteDirect, no proxy

One host, one proxy after the other. Point the rule at proxy A, load the page, note what you see, then switch the rule to proxy B and reload. It is the same page both times, but at two different moments, and the browser still holds the cookies and cache from the first visit. Clear the site's data between the two loads, or the second visit is not a fresh one.

Firefox containers, the same host in two tabs. On the extension's Containers page (Firefox only), give one container proxy A and another proxy B, then open the same page in a tab of each. Container tabs follow their own choice whatever the Rules page says, and each container keeps its own cookies, so the two arms do not share a session. Container choices apply while a proxy is connected and not in PAC script mode, and the page asks Firefox for the cookies permission the first time, because listing your containers needs it. In Chrome, the nearest equivalent is two browser profiles, each with the extension and its own proxy.

What it cannot tell you

A side-by-side in one browser is a lab with the windows open. These are the leaks:

  • Shared browser state. In one profile, both arms share cookies, cache, logins and the browser's fingerprint. A site that saw you through proxy A may recognise you through proxy B. Containers separate cookies; nothing in one browser separates the fingerprint.
  • Other hosts on the page. Rules match each request's host. The page's HTML may come through proxy A while its images, scripts and price API come from other host names that follow the fallback. With a fallback of Direct, those requests leave from your own IP and the page you see is a mixture. Set the fallback to a proxy, or add rules for the hosts the page calls (the browser's network panel lists them).
  • One sample. One page load is one draw. A block on proxy B may be the site having a bad minute. Before you conclude anything, load it a few more times, at different times of day.
  • Shared addresses. Two proxies on the same host and port that differ only in their logins cannot both sit in the rules: the browser answers an address with one login, so the extension blocks Save and names the pair. Gateway-style products that select a session or a country through the username run into this. Compare exits on different addresses, or test one after the other.
  • Rotating exits. A rotating gateway may hand out a new IP for each request, so the HTML and the API call on one page can leave from different addresses. Read the exit IP in the popup, and remember it describes one request.
  • Timings. The network panel shows timings for each request, but they are one sample each and include your own connection. They show that one arm is much slower, not by how much on average.

Write it down like a test

A comparison you cannot repeat is an anecdote. For each arm, note:

  1. The date and the time to the minute.
  2. The proxy's label and the exit IP from the popup, with its country.
  3. The routing used: the rule, or the container.
  4. What you saw: status, page, currency, language, anything that differed.

Run the Test button on both proxies first, so a dead proxy is not mistaken for a blocked one; what the Test button measures explains why a passing test still says nothing about your site. With containers, open the proxy checker in a tab of each to confirm the container's exit and that no WebRTC leak gives your own address away. Under per-site rules the checker shows the fallback's exit instead, because its own host is not one of your rules.

When to graduate to a script

Once the question turns from "is it different?" to "how often?", the browser is the wrong tool. Run the same target list through each proxy with the benchmark script, which counts successes, separates block pages from real pages with a marker, and reports a p95 rather than a feeling. For browser-rendered targets, Playwright can give each browser context its own proxy, which is the container trick done properly, in code, as many times as you like. And if the job runs from scripts anyway, ProxyDesk puts all your proxies behind one local address with a log of every recent connection.

The extension page shows the Rules page with four per-site rules, in both themes.