Proxy geo-targeting: how to target by country, city and ASN in TR, the EU and the US

This guide explains what each of the three levels describes, why geo databases show different locations for the same IP, and how to verify your exit location. It then gives a consistency checklist for timezone, Accept-Language, currency and DNS. Examples use the WeProxy gateway gw.weproxy.com.tr:8989 with USER and PASSWORD as credential placeholders.

What do country, city and ASN targeting mean?

An IP address carries three separate kinds of "location", and each comes from a different source. Country and city are estimates made by geolocation databases. The ASN tells you which network the IP block belongs to and is read from BGP routing data. Knowing this difference tells you where to look when a result comes back wrong.

Country targeting

Country targeting routes traffic through an exit IP in the country you choose. It is the minimum requirement for search results, content access, language redirects and prices that vary by country. If the target site only distinguishes by country, finer targeting just shrinks the pool for no gain.

City targeting

City targeting selects an approximate metro area within one country. Local search results, map packs, store inventory and city-level ad campaigns change at this level. Istanbul and Izmir, or New York and Los Angeles, can return different result pages even through the same country exit.

ASN targeting

An ASN (Autonomous System Number) is the number of the network that announces an IP block to the internet. A home broadband provider, a mobile carrier or a data center each appears under its own ASN. ASNs are assigned by Regional Internet Registries (RIRs); for Europe and Türkiye that registry is RIPE NCC. ASN targeting selects a network identity, not a location.

Why do geo databases show different locations for the same IP?

An IP address contains no location data. Geolocation providers such as MaxMind estimate location from RIR records, data published by operators, latency measurements and user signals. Each provider weights sources differently and updates on its own cycle. That is why one database can place an IP in Ankara and another in Istanbul.

The most common split is between registration country and actual location. An IP block can be registered to a company in the Netherlands and be used in Germany. Some databases therefore keep two separate fields: registered country and estimated location. The target site does not tell you which one it reads, so your own test needs to look at both.

Operators can publish the location of their blocks in the geofeed format defined in RFC 8805. Databases that read geofeeds return more accurate results, but not every database picks up every geofeed at the same speed. When a block moves to a new city, the old location can stay in some sources for weeks.

City data is coarser on mobile networks. Thousands of devices behind CGNAT share a small number of public IPs, and those IPs are located by the carrier's regional exit point. Read the city result for a mobile IP as a regional estimate, not an exact position.

The practical result: country level is usually consistent across databases, city level is not, and the ASN is the most stable piece of information regardless of location. When you choose city targeting, you also have to ask "correct according to which database?" If you do not know which source the target site uses, compare at least two different lookups.

When do you need city or ASN targeting?

Country targeting is enough for most jobs. You need a finer level only when the target site shows different content at that level. An unnecessary city or ASN filter reduces the number of eligible IPs and makes the same IPs repeat more often.

City targeting is needed when:

• Tracking local SERPs. For local-intent searches like "dentist near me", the map pack and organic rankings change by city. In SEO proxy work, rankings must be measured from the client's city.
• Regional prices and stock. Retail and delivery sites can show price, shipping time and inventory by delivery area. For market research, samples should come from the same city.
• City-level ad verification. If a campaign targets a specific metro area, you can only check that the ad actually appears there from that region. See ad verification for details.

ASN targeting is needed when:

• Carrier-specific apps and content. Some mobile apps, zero-rated services or carrier portals only accept requests that come from a particular carrier's network.
• Network-type consistency. If an account's history comes from a specific home ISP, keeping the session in the same network family reduces the sudden-network-change signal.
• Per-provider testing. For CDN routing or speed measurements, results vary by operator, so measurements need to be split per operator.

If none of these apply, stay with country targeting. For a wider map of use cases, see proxy use cases in SEO, scraping, ads and social media.

How do you configure targeting with WeProxy?

Targeting options differ by product and are selected in the customer dashboard or in the credential format described there. For the exact syntax of a country, city or ASN parameter, check the connection details of your product in the dashboard. Copying the example from the dashboard instead of guessing the format prevents 407 errors and wrong-location results.

Targeting scope by product:

• Rotating residential IPv4 proxy: City / ZIP targeting is listed among the product features. The network covers 180+ countries, with sticky and rotating sessions. According to the site FAQ, residential and mobile pools support country and city targeting, and ASN level is offered in some locations.
• Static residential IPv4 proxy: The IP is assigned by country and does not change during the package period. Because location and network stay fixed, it suits jobs that need a long-lived identity, such as account management.

Think about city targeting together with the session model. In rotating mode each request can get a different IP; the city may stay fixed while the ASN and IP change. If one session needs the same city and IP, use a sticky session or a static IP. Check which countries and cities are available in which product on the locations page.

The difference between residential and datacenter also affects targeting. The ASN of a datacenter IP shows a hosting provider; even with the right city, the network type does not look like a home user. For the distinction, see residential vs datacenter proxies.

What should you watch for with TR, EU and US targets?

Each region has a different combination of language, timezone and currency. The table below groups the countries listed on the product pages of the two residential products by region. Country lists can change over time; check the product card before you buy.

Türkiye

Türkiye has not observed daylight saving time since 2016 and stays at UTC+3 all year. In the browser, the timezone should be Europe/Istanbul, the language tr-TR and the currency TRY. For local search and e-commerce, results outside Istanbul can differ, so pick the city that matches where the audience is.

Türkiye is listed for both the rotating and static residential products. On the static residential product, UDP support applies to locations outside Türkiye; in Türkiye you use HTTP and SOCKS5. This is not a limitation for web traffic or geo-targeting.

European Union

There is no single "EU exit". The same search in Germany, France and Poland comes back in a different language, a different currency and with different results. Plan each country as a separate target and do not share sessions across countries.

Timezone and language must be set per country. Portugal, on Europe/Lisbon, is one hour behind Central Europe. Poland is an EU member but uses PLN. The United Kingdom is in Europe but not in the EU, and uses GBP.

United States

In the US, country targeting is often not enough. Prices, tax display, stock and local results vary by region, and the country spans several timezones. When you choose city targeting, set the browser timezone to match that city as well (America/New_York, America/Chicago, America/Los_Angeles and so on).

How do you verify the exit location?

Even when the targeting setting looks right, verify the exit on every new configuration. The first step is to note your IP without a proxy using the My IP tool. Then get the exit IP through the proxy and look up its country, city and ASN with the IP lookup tool.

# Exit IP through the proxy
curl -sS -x "http://USER:[email protected]:8989" https://api.ipify.org
echo

# Country, city, ASN and timezone for the same exit
curl -sS -x "http://USER:[email protected]:8989" https://ipinfo.io/json

In the second command's output, the org field gives the ASN number and network name, and timezone gives the timezone the database estimates for that IP. Compare this with the result from the IP lookup tool. If both sources agree on the country but differ on the city, that is a database difference; try to infer from the result page which source the target site uses.

For bulk jobs, add the check to your code. The Python example below compares the exit against the expected country and timezone:

import requests

PROXY = "http://USER:[email protected]:8989"
EXPECTED = {"country": "TR", "timezone": "Europe/Istanbul"}

session = requests.Session()
session.trust_env = False
session.proxies = {"http": PROXY, "https": PROXY}
session.headers["Accept-Language"] = "tr-TR,tr;q=0.9"

info = session.get("https://ipinfo.io/json", timeout=(10, 30)).json()
print(info.get("ip"), info.get("country"), info.get("city"), info.get("org"))

for key, want in EXPECTED.items():
    got = info.get(key)
    if got != want:
        print(f"Mismatch {key}: expected {want}, got {got}")

In rotating mode each request can get a different IP, so run this check as sampling, for example once every 100 requests. In a sticky session, one check at the start of the session is enough. If the mismatch rate rises, recheck the targeting setting and the location selected in the dashboard.

Location consistency checklist: timezone, language, currency, DNS

An IP from the right country is not enough on its own if the rest of the browser describes another country. Target sites can compare IP location with signals such as timezone, language preference and DNS resolver. The table below shows the expected values for a Türkiye target.

You can read the browser side in one go from the console:

console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)
console.log(navigator.languages)
console.log(new Date().getTimezoneOffset())

The format of the Accept-Language header is defined on MDN. In anti-detect browsers, timezone and language are set per profile; when you clone a profile, check that these values do not stay on the old country. In automation libraries (Playwright, Puppeteer), timezone and locale are passed separately when the context is created.

DNS and WebRTC are a separate channel. If resolution stays local, the resolver sees your real IP; WebRTC can produce UDP candidates that bypass the HTTP proxy. To close these channels, follow the steps in the DNS leak, WebRTC and header guide.

What are the most common geo-targeting mistakes?

1. Trusting a single database. When one lookup shows the "wrong city", the targeting may be fine and the database different. Compare at least two sources.
2. Targeting finer than needed. A city or ASN filter shrinks the pool. If the target site only distinguishes by country, stay at country level.
3. Mixing countries in one session. Using a German exit and then a French exit with the same cookie set looks like a sudden country change on the account. Use a separate session and profile per country.
4. Forgetting browser settings. If the IP is in Türkiye while the timezone is Europe/Berlin and the language en-US, the signals contradict each other.
5. Expecting a fixed city in rotating mode. In a rotating session the IP and ASN change even if the city stays fixed. If you need the same identity, use a sticky session or a static IP.
6. Measuring without logging the source. When collecting local SERP or price data, record which exit each sample came from; it is the only way to filter out suspect data later.

Geo-targeting does not change the target site's terms of use. When collecting regional price or content data, follow the target's terms, KVKK and GDPR obligations for results that contain personal data, and the WeProxy acceptable use rules.

The right order is: determine at which level the target distinguishes, select that level in the dashboard, verify the exit with two sources, and align browser signals with the same location. Country sets the market, city sets the local view and ASN sets the network identity; use each one only when the job needs it. If the target still returns 403 while you exit from the right country, the proxy error codes guide helps you tell a country restriction from an IP-type or header problem.