Geo-Targeting Not Working

Fix wrong-country, wrong-state, and wrong-city proxy results, covering city slugging (newyork, not new-york), why state is a code and not a slug, the country segment a state or city needs, geolocation-database disagreements and stale sticky sessions.

Nearly every geo-targeting problem is one of three things: a slugging mistake, a missing country segment, or a geolocation database that disagrees with yours. Work through them in that order.

Username geo-targeting applies to Residential proxies. ISP and Datacenter proxies are delivered as dedicated IPs with fixed locations and no username targeting.

Check your slugs and codes first

Two different rules apply here, and mixing them up is the single most common cause of a wrong location.

City is slugged: lowercase, with everything except letters and numbers stripped. Dashes and spaces must go.

City	Wrong	Right
New York	`new-york`, `New York`	`newyork`
Los Angeles	`los-angeles`	`losangeles`
Winston-Salem	`winston-salem`	`winstonsalem`

Country and state are codes, not slugs. For the country, use the two-letter code the dashboard's location selector emits, for example us, never unitedstates or united-states. For the state, use the ISO 3166-2 code exactly as GET /locations or the dashboard selector gives it, for example ca for California or ny for New York. Slugging the state's full name yourself (california, new-york) produces a value the gateway doesn't recognize. That's not an error you'll see: the segment is silently ignored and the exit isn't targeted to that state. See Geo-Targeting for the full rule.

Check the country segment is there

A -st- or -city- segment needs -region- to set the country. Without it there is no country to resolve the place against, and you get an untargeted exit.

Incorrect (city with no country):

abcxyz123def-city-losangeles

Correct (country plus city):

abcxyz123def-region-us-city-losangeles

The state segment is optional. Add it when two places in the same country share a name, so -region-us-st-or-city-portland and -region-us-st-me-city-portland land in different places:

curl -x "http://abcxyz123def-region-us-st-ca-city-losangeles:[email protected]:16666" https://ipinfo.io

The full segment reference is on Geo-Targeting.

The IP resolves to a different location than I targeted

IP geolocation is not exact, and databases disagree. ipinfo.io, the databases behind other lookup sites, and the target website's own geolocation data can each place the same IP in a different city, or occasionally a different country.

Before assuming targeting failed, check the exit IP against two or three independent sources.
An IP can be correctly placed by Proxio's data and still look "wrong" to one third-party database. That is a database disagreement, not a targeting bug.
What matters in practice is how your target site geolocates the IP, so test against the site itself when you can.

The location I want isn't available

Pick locations from the dashboard's live location list rather than guessing slugs. The selector only offers what is currently servable, and availability changes over time.

If a state or city returns no matching IP, widen to the country, or choose a nearby location the selector does offer.
A slug you invented by hand may not correspond to any available pool, so always confirm it exists in the selector first.

My sticky session is pinned to an old location

A sticky session holds one exit IP for the length of its sesstime. If you change your targeting but keep the same sessid, you can keep the old IP (and its old location) until the session expires.

After changing country, state, or city, start a new sessid so a fresh IP is selected for the new target.
Remember sesstime runs 1 to 90 minutes; the pin releases when it expires.

See Session Types for how sticky and smart sessions choose and hold IPs, and Geo-Targeting for the full parameter table.