IP location mismatch

You asked for region-de, the gateway gave you a German IP, but the target says "we don't serve your country." Three things can cause this — work through them in order.

1. Geo database lag

Target sites use third-party geo databases (MaxMind, IPinfo, internal). These update on different schedules from helodata's. An IP that we know is residential in Frankfurt today might still be listed as "datacenter in Amsterdam" by an old MaxMind copy the target queries.

Diagnose — confirm the IP we routed you to:

X-Helodata-Exit-IP: 198.51.100.42
X-Helodata-Exit-Geo: de/he/frankfurt

Then look it up in the target's likely geo source:

• MaxMind demo: https://www.maxmind.com/en/geoip2-precision-demo
• IPinfo: https://ipinfo.io/{ip}
• Whoer: https://whoer.net/

If those agree with X-Helodata-Exit-Geo, the target has older data — wait or try a new IP. If they disagree with us, that IP's geo recently changed and our database isn't refreshed yet.

2. Behavioral geo (not IP geo)

Some targets check more than IP. Signals that override IP:

• Accept-Language header
• Time-Zone from JavaScript (Intl.DateTimeFormat().resolvedOptions().timeZone)
• Currency or locale cookies from a previous visit
• Login state if the user has an account region

Fix — clear cookies, set headers to match the IP country, use an antidetect browser that aligns timezone with proxy geo (most do — see Multilogin, AdsPower).

3. Genuine routing error (rare)

The gateway picks an IP whose live geo doesn't match the requested filter. helodata's geo database is refreshed daily, but device-level mobility (a residential subscriber traveled internationally, a mobile SIM crossed a border) can produce a mismatch in the gap.

When that happens we tag the response:

X-Helodata-Exit-Geo-Confidence: low

Fix — request a new IP (drop session) and we'll route past the questionable one. If you see Exit-Geo-Confidence: low on > 5% of your requests, raise a ticket.

Verifying programmatically

import requests

USER = "helo_s1a2b3c4d5e-type-res-region-de"
proxy = f"http://{USER}:[e-mail]:7777"

r = requests.get("https://ipinfo.io/json",
                 proxies={"http": proxy, "https": proxy}, timeout=30)
exit_info = r.json()
exit_geo = r.headers.get("x-helodata-exit-geo")

# Compare what we say vs what a third-party geo provider says
print("helodata:", exit_geo)              # e.g. de/he/frankfurt
print("ipinfo:",   exit_info["country"])  # e.g. DE

If those disagree, that's the mismatch — and the target was probably using something like the second one.

What about VPN / hosting flags?

Some targets reject IPs flagged as "VPN" or "hosting" regardless of country. helodata residential IPs aren't flagged as hosting (they're real consumer ISPs). If a target's blocking based on this flag:

• Try ISP — these are flagged as residential by major databases
• Try mobile — usually flagged "mobile carrier" which most targets allow
• If you must use residential and the target keeps flagging, the IP was likely re-classified after we issued it; rotate

Still mismatching

Email [e-mail] with one X-Helodata-Request-Id, the target URL, and what geo it reported back. We'll trace whether the issue is in our pool, in the third-party geo database, or on the target.