This guide covers how targeting is applied, what each level can and cannot guarantee, and how to verify results before trusting them.
How a targeting request is routed
A targeting header or credential tells the proxy gateway which pool to draw from. The gateway selects a peer that matches the requested attributes when one is available. If no exact match exists, behaviour depends on the network: it may return the closest match or fail the request.
Because availability changes as peers join and leave, targeting is a request, not a permanent assignment. Sticky sessions help when a workflow needs the same peer across multiple steps.
Country versus city versus ISP
Country targeting is the most reliable level because pools are largest and geolocation at country level is usually consistent. City targeting narrows the pool and depends on how the ISP registers address blocks; some cities share ranges with neighbouring areas.
ISP targeting selects a network rather than a place. It is useful when a target treats a specific carrier differently, but it should not be used as a substitute for geographic accuracy.
- Country: broadest pool, highest availability, best default.
- City: useful for local search and marketplace checks, lower availability.
- ISP or ASN: useful for carrier-specific behaviour, not for geography.
Verify from inside the proxy
Do not trust the label alone. Query an IP intelligence endpoint through the proxy and compare the reported country, region, and ASN with what you asked for. Then check the target itself, because some sites use their own geo databases.
A small verification script that runs before a collection job catches mismatches early. Store the exit IP and reported location with each result so later analysis can exclude outliers.
curl -sS -x http://USERNAME:PASSWORD@proxy.graviix.com:8080 \
-H "X-Graviix-Country: GB" \
-H "X-Graviix-City: london" \
-H "X-Graviix-Session: verify-london-1" \
https://ipinfo.io/jsonCommon mistakes
The most common mistake is rotating the IP between the verification request and the real request, then assuming the verified location applies. Use a sticky session when location matters across a sequence.
The second is expecting city accuracy from a country-level pool. If a workflow depends on city-level behaviour, test the exact city repeatedly and measure how often the result matches expectations before scaling.
Targeting and data minimisation
Geographic targeting is a technical control, not a licence to collect more than you need. Decide which location data is actually required for the task, and avoid storing precise coordinates or addresses when a country or city is sufficient.
Treat the exit IP as operational data with a retention limit. Keep it long enough to debug and audit, then remove it. A shorter retention window reduces risk and keeps reports focused on the question the project was meant to answer.
A verification checklist you can automate
Before a targeted job starts, run one request through the intended configuration and assert four things: the request succeeded, the exit IP matches the expected country, the reported ASN is plausible for the selected ISP, and the target returned the expected regional variant.
If any assertion fails, stop the job instead of collecting data with the wrong configuration. A failed pre-flight check is cheaper than a dataset that has to be discarded later because half of the records came from the wrong location.
When the country is right but the content is still wrong
Location is one input among several. A target may choose language, currency, and inventory from language headers, cookies, or account settings rather than from the IP alone. Requesting from the correct country with the wrong headers can still return the wrong variant.
Inspect the response for signals: currency symbols, shipping estimates, store names, and the presence of regional promotions. These are better indicators than the IP lookup alone, which only proves where the request entered the network.
CDNs add another layer. Some assets are served from the nearest edge regardless of the proxy country, so a page can look local while images and scripts are global. Test the elements that matter for the task instead of judging the whole page by its address.
Key takeaways
- Country targeting is the most dependable level; city is approximate and pool-dependent.
- Verify the exit location through the proxy and on the target itself.
- Use sticky sessions when a workflow needs the same location across steps.
Frequently asked questions
Why does a geo-check website disagree with my targeting request?
Different databases map IP ranges differently, and the target may use its own source. Verify against both a general IP intelligence service and the target you care about.
Can I target a specific city reliably?
Availability varies by city and time. Test the exact city repeatedly, measure match rates, and have a fallback strategy for requests that cannot be matched.
Does ISP targeting also control the country?
Not necessarily. Select a country alongside the ISP and verify the result, especially when the carrier operates in multiple regions.
Need proxies for this workflow?
Graviix provides residential, mobile, datacenter, and static ISP proxies with country and city targeting, rotating or sticky sessions, and a documented HTTP API.
