Choosing an Exit Country: When the Nearest Proxy Is the Wrong One

The first instinct when setting up a proxy is to pick the location closest to you. It feels like it should be fastest, and it often gives you the wrong data. A website does not know where you are sitting. It sees the exit, so with a residential proxy the exit country decides which version of the site you get.

This guide shows how to choose an exit country by what you are trying to learn, how to check whether a site reacts at all, and when the nearest exit really is the right call.

The question to ask first

Do not ask where you are. Ask whose view you need.

What you are doing	Choose an exit in
Monitoring competitor prices	The market your customers buy in
Checking search rankings	The place the searcher is, down to the city if needed
Verifying ads	The country the campaign targets
Testing a localized site	Every market you sell in, one at a time
Checking your own geo redirects	Each country the rule covers, plus one it does not
Collecting content that does not vary	Near the target, with a deep pool

A team in Germany tracking US prices gets nothing useful from a German exit: it would see euros and maybe a different catalogue, and the data would look perfectly fine.

Test whether the site reacts

Not every site changes by IP. Before you plan around an exit country, measure it. The script below requests a page from several countries, confirms where each request really left, and records what the page showed. It runs on Python 3.9 and later with requests. Credentials come from environment variables, so keep them out of your code.

from __future__ import annotations

import os
import re

import requests

GATEWAY = "p.shifter.io:443"
USER, PASSWORD = os.environ["PROXY_USER"], os.environ["PROXY_PASS"]


def session_for(country):
    proxy = f"http://{USER}-country-{country}:{PASSWORD}@{GATEWAY}"
    s = requests.Session()
    s.proxies = {"http": proxy, "https": proxy}
    s.headers["User-Agent"] = ("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
                               "(KHTML, like Gecko) Chrome/130.0 Safari/537.36")
    return s


def signals(url, country):
    """What this page shows a visitor from one country, and where they really exited."""
    s = session_for(country)
    try:
        exit_country = s.get("https://ip-info.com/json", timeout=30).json().get("country")
        r = s.get(url, timeout=30)
    except (requests.RequestException, ValueError) as exc:
        return {"exit": country.upper(), "error": type(exc).__name__}
    lang = re.search(r'<html[^>]*\blang=["\']?([\w-]+)', r.text, re.I)
    currency = re.search(r'priceCurrency["\']?\s*(?:content=|:)\s*["\']([A-Z]{3})', r.text)
    price = re.search(r'itemprop=["\']price["\']\s+content=["\']([\d.,]+)', r.text)
    return {"exit": exit_country, "status": r.status_code, "final_url": r.url,
            "lang": lang.group(1) if lang else None,
            "currency": currency.group(1) if currency else None,
            "price": price.group(1) if price else None}


if __name__ == "__main__":
    for url in ("https://www.apple.com/shop/buy-iphone",
                "https://store.steampowered.com/app/620/Portal_2/"):
        print(url)
        for country in ("us", "de", "gb", "br"):
            s = signals(url, country)
            print(f"  exit {s['exit']}  {s.get('status')}  lang={s.get('lang')}  "
                  f"{s.get('currency')} {s.get('price') or ''}".rstrip())

We ran it on 4 November 2026 with a Shifter test account. These are the results, and prices will change over time:

https://www.apple.com/shop/buy-iphone
  exit US  200  lang=en-US  USD
  exit DE  200  lang=en-US  USD
  exit GB  200  lang=en-US  USD
  exit BR  200  lang=en-US  USD
https://store.steampowered.com/app/620/Portal_2/
  exit US  200  lang=en  USD 9.99
  exit DE  200  lang=en  EUR 9,69
  exit GB  200  lang=en  GBP 8.19
  exit BR  200  lang=en  BRL 33,99

Those two sites show the two cases you need to know.

Apple does not react to the IP. Every exit got the same US page in USD. Apple keeps its localization in the URL: /de/shop/buy-iphone serves the German store. Your exit country made no difference to this page, so choosing one by geography would achieve nothing.

Steam does react. The URL and language stayed the same, but the currency and price changed with the exit: USD 9.99, EUR 9,69, GBP 8.19 and BRL 33,99. A price check from the wrong country gives you a clean, believable, wrong number, with no error to warn you.

Check the exit as well as the page, as the script does. A wrong location is much easier to catch here than later in your data.

When the nearest exit is the wrong one

• Your audience is somewhere else. This is the most common case, and the examples above show why.
• Your neighbour is a different market. Germany and Austria share a language but not always prices, and a shared currency does not mean a shared catalogue. Treat them as separate.
• The market is regional. Some results vary by city or state as much as by country. Our guide to when city-level targeting matters covers how to tell.
• The rest of the request does not match. A US exit with a German browser language can get you an odd mix of both. Geo, timezone and locale should agree, so set them together.

When nearest is right, and nearest to what

If a site serves the same content everywhere, as Apple’s URL does, geography stops being about accuracy and becomes about performance. Even then, the distance that counts is rarely the one from your desk. A proxied request goes from your client to the gateway, then to the exit, then to the target. An exit close to the target shortens the last leg, however far away you are.

So if the content does not vary, pick an exit near the target with plenty of available IPs, and measure it. Smaller countries have thinner pools, so a popular neighbouring market can be more dependable when location truly does not matter.

Common mistakes

• Testing one country and assuming the rest. A site that ignores the IP on one page can react on another, such as checkout or search. Test the page you care about.
• Trusting a clean response. A page in the wrong currency still returns 200. Add a check for the currency or language you expect.
• Assuming every step follows the exit. Some sites steer by DNS or by account settings as well as by IP, and DNS may not resolve in the exit country. If it matters, verify the page you get.
• Mixing up exit and residency. The exit is where a request leaves the network. It says nothing about where your data is stored.
• Treating an exit as permission. Showing a site another country’s view for testing or research is one thing. Using it to get around licensing, sanctions or a site’s terms is another. Check with your legal team first.

The bottom line

Pick the exit by whose view you need, not by where you are. Test whether the site reacts to the IP at all, confirm where each request really left, and add a check for the currency or language you expect. Only when the content is the same everywhere does distance come into it, and then what counts is the distance to the target.