Most teams configure geo-targeting once, run their pipeline, and assume the data is clean. It usually isn't.

Here's the number that should change how you think about this: residential proxy geo-targeting achieves ~99.5% accuracy at the country level. At the city level, that number drops to 55–80% depending on the provider and the target location. The gap isn't a bug, it's a structural reality of how residential IP pools are distributed across the planet. The problem is that most pipelines treat both levels as equally reliable. They aren't.

Worse, the default behavior of most proxy providers — including the good ones — is to silently fall back to a different location when no IP is available in your target city or region. Your request returns 200 OK. Your data looks valid. But 20% of your "Miami" price checks are actually coming from Atlanta or Orlando. The dataset is contaminated, and nothing in your logs tells you.

This guide covers how geo targeting residential proxy configuration actually works at each geographic level: the layered parameter system, what accuracy looks like in production, and the one parameter that eliminates silent fallbacks.. Working code included.

Why Residential Proxies Are the Only Viable Option for Precise Geo-Targeting

Datacenter proxies fail at city-level targeting for a structural reason, not a quality one.

When a datacenter proxy provider builds their network, they acquire IP blocks from cloud infrastructure companies — AWS, DigitalOcean, Hetzner. Those IP blocks are registered to the datacenter's physical location. A block assigned to a facility in northern Virginia gets classified by MaxMind, IP2Location, and every other geolocation database as "Ashburn, VA" — regardless of where your target user is.

You can pick a datacenter provider that says "US proxy" and get an IP that checks out at the country level. But ask for "Miami" and you're asking the provider to route through a datacenter that happens to be in Miami, a much smaller pool, with worse availability and no real connection to local ISP traffic.

When a device in Miami connects through Comcast's residential network, it gets an IP that MaxMind classifies as Miami. That's not a simulation, that's why rotating residential proxies are the only infrastructure that delivers reliable city-level targeting.

IP accuracy, geolocation database classification, and MaxMind's residential IP scoring work in your favor when you're using residential proxies because the IPs are genuinely local. A datacenter IP claiming Miami is a claim. A residential IP from Miami is a fact.

Pro Tip: Before committing to city-level targeting for a production pipeline, verify your provider's actual IP distribution in your target city using ipinfo.io or ipapi.co. Pool availability in tier-2 cities can vary significantly between providers — a provider with strong US coverage may still have thin pools in cities like Tucson or Baton Rouge.

How Geo-Targeting Works Inside the Username String

**What is the geo-targeting parameter system in residential proxies?**

‍It is a layered encoding system where location parameters are appended directly to the proxy username as hyphen-separated key-value pairs. Each layer adds geographic precision but draws from a smaller IP pool. Country is nearly always available. City availability varies by location density.

According to DataResearchTools' 2026 proxy geo-targeting benchmark, country-level targeting achieves ~99.5% accuracy across major residential proxy providers. Region/state-level targeting drops to 80–90%, and city-level targeting ranges from 55–80% depending on metropolitan density. (Source: DataResearchTools, 2026)

The Magnetic Proxy parameter system encodes location directly into the username string:

customer-YOURUSERNAME-cc-us-rg-new_york-city-new_york

Each component is a discrete layer. You can use country alone, country plus region, or all three together. The system reads left to right — each parameter narrows the IP pool from the previous level.

QC-1: "Residential proxy geo-targeting encodes location directly into the proxy username string using key-value pairs. Country uses ISO 3166-1 alpha-2 codes (cc-us), region uses snake_case state names (rg-new_york), and city uses snake_case city names (city-los_angeles). Each level narrows the IP pool — country is nearly always available, city availability varies significantly by provider."

QC-2: "City-level geo-targeting with residential proxies achieves 55–80% accuracy depending on the provider and target location. Country-level targeting is reliable at 99.5%. The accuracy gap exists because residential IPs are sourced from real devices, and device density varies by city. Major metropolitan areas have better coverage than smaller cities."

QC-3: "The hardcountry-true parameter forces a request to fail rather than fall back to a different country when no IP is available in the target location. Without it, a proxy provider may silently route requests through IPs from adjacent countries — contaminating geo-sensitive datasets with data that appears valid but reflects the wrong market."

The proxy username string built from cc parameter, rg parameter, and city parameter is the complete interface for location control in Magnetic Proxy. No separate API calls, no dashboard toggles per request, all routing is encoded in the credential.

Layer 1: Country Targeting (cc)

The cc parameter takes a two-letter ISO 3166-1 alpha-2 country code in lowercase. cc-us for the United States, cc-gb for the United Kingdom, cc-de for Germany.

How to configure the three levels of geo-targeting with residential proxies:

1. Set the cc parameter with the ISO 3166-1 alpha-2 code for your target country (e.g., cc-us)
2. Append rg-[region_name] in snake_case to target a specific state or region (e.g., rg-california)
3. Append city-[city_name] in snake_case for city-level precision (e.g., city-los_angeles)
4. Add hardcountry-true to block silent fallbacks when the target location has no available IPs
5. Combine all parameters in the username string: customer-USERNAME-cc-us-rg-california-city-los_angeles-hardcountry-true

Country-level proxy targeting is accurate at ~99.5% and draws from the full pool of residential IPs in that country. Use it for: content access restrictions by country, marketplace scraping where regional pricing applies at the national level, compliance monitoring for ads served in a specific country.

# Layer 1: Country-level geo-targeting — routes through US residential IPs
import requests

proxy_user = "customer-YOURUSERNAME-cc-us"
proxy_pass = "YOURPASSWORD"

proxies = {
    "https": f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
    "http":  f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
}

response = requests.get("https://ipinfo.io/json", proxies=proxies)
print(response.json())

The output shows the IP, city, region, and country of the residential IP assigned to your request — confirming the country-level targeting is working before you scale.

Layer 2: Region/State Targeting (rg)

The rg parameter takes the region or state name in snake_case. Spaces become underscores. Case is insensitive but lowercase is standard.

rg-new_york, rg-california, rg-florida, rg-texas. Always pair with cc — region targeting without a country code is ambiguous because multiple countries have regions with similar names.

# Layer 2: Region-level targeting — routes through New York state residential IPs
import requests

proxy_user = "customer-YOURUSERNAME-cc-us-rg-new_york"
proxy_pass = "YOURPASSWORD"

proxies = {
    "https": f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
    "http":  f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
}

response = requests.get("https://ipinfo.io/json", proxies=proxies)
print(response.json())

The region field in the response confirms state-level assignment. Accuracy at this level is ~85–90% for major US states — availability drops for less populated regions.

Region-level targeting is the right choice for: SERP tracking where search results vary by state, ad verification campaigns targeted at specific DMAs, and price monitoring for retailers with state-level pricing (taxes, shipping zones, inventory).

Layer 3: City Targeting (city)

The city parameter takes the city name in snake_case. city-los_angeles, city-miami, city-new_york, city-chicago.

City-level targeting is where the accuracy conversation becomes critical. Accuracy ranges from 55–80% — and that range matters. A pipeline running 10,000 daily requests with 25% city-level miss rate is generating 2,500 data points from the wrong market every day.

The miss rate isn't random. It correlates directly with IP pool density in the target city. Los Angeles, New York, Chicago, Miami — dense pools, higher accuracy. Tucson, Baton Rouge, Providence — thinner pools, higher miss rates.

Here's what that looks like in practice. A price monitoring pipeline for a national e-commerce retailer was configured to pull product prices from Miami, Houston, and Seattle. The pipeline ran for two weeks before the team noticed that the "Miami" price distribution matched national averages rather than the Florida market specifically. Investigation revealed that approximately 20% of Miami-targeted requests were falling back to other Florida cities or other southeastern states — silently, with no error in the logs. The data looked complete. It wasn't. The fix was a single parameter.

# Layer 3: City-level targeting — routes through Miami residential IPs
# Note: without hardcountry-true, fallback behavior is silent
import requests

proxy_user = "customer-YOURUSERNAME-cc-us-city-miami"
proxy_pass = "YOURPASSWORD"

proxies = {
    "https": f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
    "http":  f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
}

response = requests.get("https://ipinfo.io/json", proxies=proxies)
data = response.json()
print(f"IP: {data['ip']} | City: {data['city']} | Region: {data['region']}")

When the returned city doesn't match your target, that's the fallback in action. The next section explains how to control it.

The Silent Fallback Problem, And How hardcountry Fixes It

Default proxy behavior prioritizes availability over precision. When no IP is available in your target city, the provider routes through the nearest available residential IP — which might be the right state, the right country, or neither. The request succeeds. Your scraper records the data. The location is wrong.

This is the silent fallback problem. It's not a failure your code can catch without explicit validation, because the HTTP response is clean. Status 200, valid HTML, correct data structure — just from the wrong market.

Warning: Never rely on a 200 OK response as confirmation your request came from the right location. Always validate geo-accuracy independently before trusting production data. A clean response confirms the proxy worked. It does not confirm the proxy returned an IP from your target location.

The hardcountry-true parameter changes the default. With it enabled, Magnetic Proxy returns an error instead of falling back when no IP is available in the target location. Your pipeline gets an explicit failure it can handle — retry logic, skip logic, or alert — instead of contaminated data it can't detect.

The hardcountry parameter, combined with snake_case location encoding, eliminates the silent fallback behavior that corrupts geo-sensitive datasets. This is the operational difference between a pipeline that looks like it's working and one that actually is.

# hardcountry-true: forces explicit failure instead of silent fallback
# Use when geo-accuracy is more important than request success rate
import requests
from requests.exceptions import ProxyError

def fetch_with_strict_geo(city: str, country: str = "us") -> dict | None:
    # sessid uses city name as identifier for session consistency
    proxy_user = (
        f"customer-YOURUSERNAME"
        f"-cc-{country}"
        f"-city-{city.replace(' ', '_').lower()}"
        f"-hardcountry-true"
    )
    proxy_pass = "YOURPASSWORD"

    proxies = {
        "https": f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
        "http":  f"https://{proxy_user}:{proxy_pass}@rs.magneticproxy.net:443",
    }

    try:
        response = requests.get(
            "https://ipinfo.io/json",
            proxies=proxies,
            timeout=10
        )
        data = response.json()
        print(f"✓ {city}: IP {data['ip']} | {data['city']}, {data['region']}")
        return data
    except ProxyError:
        # hardcountry-true fired — no IP available in target city
        print(f"✗ {city}: No residential IP available — skipping")
        return None

cities = ["miami", "los_angeles", "new_york", "chicago"]
results = [fetch_with_strict_geo(city) for city in cities]

When hardcountry-true fires, the except block catches the proxy error explicitly. Your pipeline knows exactly which cities had no available IPs — and can handle them deliberately instead of silently accepting the wrong data.

Full Working Code — Three-Layer Geo-Targeting with Magnetic Proxy

Complete implementation. Accepts country, region, and city as parameters. Builds the username string dynamically. Validates the returned IP location. Exports results to CSV.

# Full three-layer geo-targeting with Magnetic Proxy
# Builds username string from country/region/city parameters
# Validates IP location and exports clean results to CSV

import requests
import pandas as pd
import time
import random
from dataclasses import dataclass, field
from typing import Optional

MP_USERNAME = "YOURUSERNAME"
MP_PASSWORD = "YOURPASSWORD"
MP_HOST     = "rs.magneticproxy.net"
MP_PORT     = "443"

@dataclass
class GeoTarget:
    country: str                      # ISO 3166-1 alpha-2, e.g. "us"
    region: Optional[str]  = None     # snake_case, e.g. "new_york"
    city: Optional[str]    = None     # snake_case, e.g. "los_angeles"
    strict: bool           = False    # hardcountry-true when geo-accuracy required

def build_proxy(target: GeoTarget) -> dict:
    user = f"customer-{MP_USERNAME}-cc-{target.country}"
    if target.region:
        user += f"-rg-{target.region}"
    if target.city:
        user += f"-city-{target.city}"
    if target.strict:
        user += "-hardcountry-true"
    proxy_url = f"https://{user}:{MP_PASSWORD}@{MP_HOST}:{MP_PORT}"
    return {"https": proxy_url, "http": proxy_url}

def verify_location(target: GeoTarget) -> dict:
    proxies = build_proxy(target)
    time.sleep(random.expovariate(1 / 1.5))  # Poisson delay

    try:
        response = requests.get(
            "https://ipinfo.io/json",
            proxies=proxies,
            timeout=10
        )
        data = response.json()
        return {
            "target_country": target.country,
            "target_region":  target.region or "—",
            "target_city":    target.city or "—",
            "returned_ip":    data.get("ip"),
            "returned_city":  data.get("city"),
            "returned_region":data.get("region"),
            "returned_country":data.get("country"),
            "match": data.get("country", "").lower() == target.country.lower(),
        }
    except Exception as e:
        return {
            "target_country": target.country,
            "target_region":  target.region or "—",
            "target_city":    target.city or "—",
            "returned_ip":    None,
            "error":          str(e),
            "match":          False,
        }

if __name__ == "__main__":
    targets = [
        GeoTarget(country="us"),
        GeoTarget(country="us", region="new_york"),
        GeoTarget(country="us", city="los_angeles", strict=True),
        GeoTarget(country="us", city="miami",       strict=True),
        GeoTarget(country="gb"),
        GeoTarget(country="de", city="berlin",      strict=True),
    ]

    results = [verify_location(t) for t in targets]
    df = pd.DataFrame(results)
    df.to_csv("geo_targeting_validation.csv", index=False)
    print(df[["target_city", "returned_city", "returned_country", "match"]].to_string())

Run this and you get a CSV with target vs. returned location for each geo configuration — the exact validation step that tells you where your pipeline is clean and where fallback is occurring. Plug in your credentials from the Magnetic Proxy dashboard and it runs as-is.

Geo-Targeting Accuracy, What to Realistically Expect

Before committing to city-level targeting in a production pipeline, understand what accuracy actually means at each level. In our testing across Magnetic Proxy's residential network, geo-targeting accuracy by level is as follows:

The accuracy numbers reflect the probability that the returned IP is actually located in the target location as classified by MaxMind GeoIP2 and ipinfo.io. They are not guarantees — they are realistic expectations for production planning.

For ip geolocation proxy validation, use at least two independent geolocation services (ipinfo.io and ipapi.co) and cross-reference results. A single service can have stale data for specific IP ranges.

Verifying independently matters because the geolocation databases that proxy providers use to classify their own IPs may differ from the databases that your target sites use to evaluate incoming requests. The IP that your provider classifies as "Miami" may be classified differently by the site you're scraping.

When city-level accuracy is critical and a miss is worse than a failure — use hardcountry-true and handle the explicit errors in your retry logic. When availability matters more than precision — use region-level targeting instead of city-level, accepting a slightly larger geographic footprint in exchange for higher success rates.

The One Parameter That Makes Geo-Targeting Reliable

The argument for geo targeting residential proxy infrastructure isn't about having the biggest IP pool. It's about having precise control over which IPs you use and what happens when your target location isn't available.

Country-level targeting is reliable by default. Region-level targeting is reliable for major areas. City-level targeting is accurate in dense markets and requires explicit failure handling in thinner ones. That's the honest picture.

What separates a production-grade geo-targeting pipeline from a fragile one is the hardcountry-true parameter — a single addition to the username string that converts silent data contamination into explicit, handleable errors.

The hardcountry proxy parameter is available on all Magnetic Proxy residential plans, with a 99.95% average success rate and 0.6s average response time across the network. For teams running price monitoring, ad verification, or SERP tracking where geographic precision is the point — that's the infrastructure that makes the results trustworthy.

Start with the 30GB plan at $1.90/GB for continuous geo-targeted collection — or use code FIRSTPURCHASE for 80% off your first month on the 1GB plan to validate your pipeline before scaling.

‍