Geo-Targeting with Residential Proxies: Country, Region, and City Explained

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

‍

‍

Compare the requested location with the exit location observed in the response. Country, region, and city are separate targeting dimensions; the illustration does not prove exact physical location or identical results for every visitor.

‍

‍

‍

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

‍

‍

Read the username in layers: customer identifies the account; cc sets the country; rg and city request region and city; sessid selects a sticky session; sesstime sets seconds. With sessid, hardcountry-true fails when neither the linked proxy nor a same-country replacement is available. It does not enforce city-level continuity.

‍

‍

**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 MagneticProxy parameter system encodes location directly into the username string:

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 MagneticProxy. 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.

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.

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.

‍

Keep exploring: See the General Purpose Capsule for the relevant proxy setup, then read What Is a Residential Proxy? for the technical foundation.

‍

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, MagneticProxy 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.

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 MagneticProxy

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

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 MagneticProxy 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 MagneticProxy'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 MagneticProxy 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 PROXYSTART for 30% off your first month on the 10GB plan to validate your pipeline before scaling.

‍