Proxy Location Accuracy: How to Verify Your Exit

A location menu is a promise about a database, not about a wire. Three checks that prove where your exit really is, before your data depends on it.

Every proxy provider sells you a dropdown. You pick Germany, you get an address, and something in the back of your mind files that address away as German. It is worth being precise about what you just bought, because the dropdown is a claim about two separate things, and either one can be wrong without the other being wrong at all.

The first claim is routing: that the packet leaving for your target really did leave from the machine you selected. The second claim is identification: that when your target looks the exit address up, it agrees. Those are independent. A provider can route you perfectly to a genuine Frankfurt machine and still hand you an address that three commercial databases insist is in Amsterdam, and your target site is querying one of those databases, not yours.

This is the part of proxy buying that almost nobody tests, and it is the part where a mistake does the most damage, because the failure is silent. A blocked request tells you it failed. A request served from the wrong country does not fail. It returns a plausible page, and the plausible page goes into your dataset.

Location is a database opinion, not a property of the wire

An IP address carries no location. There is no field in the packet, nothing in the protocol, no authority you can query for a definitive answer. When a website decides you are in Germany, it has consulted a commercial geolocation database, and that database has made an inference from registry records, from routing announcements, from latency measurements, and from whatever ground truth its vendor has managed to buy or collect.

The vendors publish how well this works, and the numbers are more sobering than the marketing around them suggests. MaxMind maintains a public accuracy table for its own GeoIP2 City database, broken down by country, measuring the share of addresses it places within fifty kilometers of where they actually are. Read it before you build anything on city targeting. Italy sits at 41 percent. Sweden is also 41. Finland is 33. Hong Kong is 29.

Those are the vendor's own figures about the vendor's own product, published deliberately, and they are not evidence that MaxMind is bad at this. They are evidence that city-level geolocation is a hard inference problem that nobody has solved. Country resolution is a different story and is broadly reliable. The gulf between those two facts is the single most useful thing to internalize here: country targeting is close to a solved problem, and city targeting is a probabilistic instrument that you should treat as one.

That applies to us as much as to anyone selling you a city menu. If your job genuinely depends on a specific metropolitan area, the accuracy of the city label is a thing to measure per country and per target, not a checkbox to tick at checkout.

Where the databases get their answer

Understanding the inputs tells you which providers can be checked and which cannot.

The oldest input is registry data. Address blocks are allocated by the five regional internet registries, and the inetnum or NetRange record carries a country field along with the organization holding the block. You can read this yourself for any address with whois, and it is the layer that is hardest to fake, because it is maintained by the registry rather than by the address holder.

The second input is self-published. RFC 8805 defines a geofeed: a plain CSV in which a network operator states, for each of its prefixes, the country, region and city it is actually deployed in. RFC 9632 defines how a consumer finds that file, by reading a geofeed: reference out of the operator's registry record. It exists because operators were tired of geolocation vendors guessing wrong about ranges the operator knew the answer for, and the major vendors ingest it.

Geofeeds are the reason the ownership question matters commercially rather than just rhetorically. An operator that holds its own allocation can publish a geofeed and have the databases converge on the stated answer within a refresh cycle. A reseller renting addresses from someone else cannot publish anything authoritative about ranges it does not hold, and has to hope the real holder did.

This is a place to be straight about the shape of our own catalog rather than to imply more than is there. Our owned datacenter footprint is the United States, Italy and Spain, not a world map, and the country of those blocks is unambiguous precisely because we hold the allocation. Our residential coverage spans 170+ countries and works the other way around: those exits are consumer connections whose location comes from the household's own ISP, so the ISP's registry data and geofeed are what the databases read, and no proxy vendor on earth controls that. Both models can be verified. Neither is verified by the dropdown.

Failure one: the exit is not where you asked

Before you can ask whether the databases agree, you need to know that the provider honored the request at all. There are two ways this goes wrong, and the second is worse than the first.

The obvious way is that the pool has no address in the place you selected. What happens next is a product decision, and it is the single most important question to ask a provider before buying: when you have no exit in the country I asked for, do you refuse my request, or do you serve it from somewhere else?

Serving it from somewhere else is comfortable, because the request succeeds and nobody files a support ticket. It is also how a rank tracker ends up writing a US search result into a report labeled Germany. For most traffic a substituted exit is a shrug. For the two workloads that buy geo-targeting in the first place, rank tracking and ad verification, a substituted exit is not a failed request, it is a plausible wrong answer with your customer's name on it.

Our own answer is that both gateways refuse. A rotating request for a country the pool cannot serve is answered with a 502 whose body says so in words, deliberately not a 503, because coverage is not a transient condition and retrying will not fix it. The residential gateway refuses an unservable location rather than quietly substituting the nearest thing it has. Sticky sessions get the same treatment, because pinning a session to the wrong country would make one wrong answer durable across an entire crawl.

The quieter way targeting fails is a typo, and it is worth knowing exactly what a provider does with one. A misspelled key is the most dangerous input a targeting grammar can receive, because the request still looks valid from your side.

Both of our gateways refuse it, by different routes. On the residential gateway an unrecognized key is denied by name. On the rotating gateways nothing strips the bad segment: USERNAME-contry-it stays intact as the username sent to authentication, credentials are matched exactly, and the request fails with a 407. Neither one hands you untargeted exits while you believe your typo was honored. That is the behavior to insist on when you evaluate anyone, ours included: ask what a misspelled location key does, and treat "it is ignored" as the wrong answer.

The rotating gateways also report the outcome directly, in a header rather than a promise. X-Node4-Country reads honored when a country was requested and delivered, unavailable when it could not be, and none when no country segment was parsed.

Where you can read it depends on the protocol, and this is the part worth knowing before you build a check on it. It is delivered on every refusal, and on plain-HTTP responses. It is not delivered on a successful HTTPS request: a CONNECT tunnel's response line carries only X-Node4-Sticky, and SOCKS5 carries no headers at all. So for an HTTPS workload the header answers "why was this refused", and a success has to be verified by its exit address instead, which is what the rest of this article is about.

The rotating pool is our own blocks, so its country segments are the markets those blocks sit in. Over plain HTTP you can read both headers directly:

curl -sv -o /dev/null \
  -x "http://USERNAME-country-us:PASSWORD@gw-rotating_shared.node4.io:8083" \
  http://example.com 2>&1 | grep -i 'x-node4-'

The full segment grammar, including what combines with what and how a malformed segment is rejected, is in residential country and city targeting.

Failure two: the exit is where you asked, and the databases disagree

Now the harder case. The provider routed you correctly, the exit really is in the country you asked for, and your target still serves you the wrong country's site.

This is not the provider lying. This is the address being genuinely in Italy while the specific database your target happens to query has it filed somewhere else, because its inference is stale, or because the block was recently transferred, or because the holder never published a geofeed and the vendor is guessing from routing.

There is no way to resolve this by arguing with your provider. There is only measurement, and the measurement has to be done against the thing that actually decides.

The three checks, in the order that matters

Check what the provider says. Read the response header, or the equivalent your provider offers. This costs nothing and catches the entire class of typo and substitution failures. If a provider offers no way to distinguish "delivered what you asked for" from "delivered something", that absence is itself the answer to your evaluation question.

Check what the databases say, plural. Resolve your exit against more than one source, because agreement between independent vendors is the signal and any single vendor's answer is just one opinion. Start with our IP lookup tool, which shows you the exit address, the country it resolves to and its reverse DNS name. Then read the whois record directly for the country field and the holding organization, and compare both against a second commercial vendor. Where they disagree, the honest conclusion is that the location is contested, and a contested address is a bad choice for work that depends on the label.

IP=$(curl -s -x "http://USERNAME-country-us:PASSWORD@gw-rotating_shared.node4.io:8083" https://ipinfo.io/ip)
whois "$IP" | grep -iE 'country|netname|org-name|descr'

Check what your target says. This is the only check that actually settles the question, and it is the one people skip because it takes real work. Fetch the page you care about through the exit and read the result for evidence of localization: the currency on a price, the language served without an Accept-Language hint, the country the site itself thinks you are in, the store or the fulfilment center it offers you. Everything upstream of this is a proxy for it, in both senses. An Italian exit that three databases agree on and that Amazon still serves in dollars is, for your purposes, not an Italian exit.

Build that last check into the job rather than running it once at evaluation. Geolocation records drift, pools change composition, and an exit that passed in March is not evidence about June. The same argument for continuous rather than one-off measurement applies to throughput and success rate, and is laid out in measuring proxy performance.

What to ask before you pay

Four questions, all of which have a factual answer, and none of which require a provider to disparage anyone:

What happens when the pool has no address in the location I request, and can I detect that case from the response? Are these addresses held by you or rented, and is there a geofeed for the ranges? What accuracy do you claim at city level as distinct from country level, and what is that measured against? Can I run a targeted request against my own target before I commit to a plan?

A provider who can answer all four is not necessarily the cheapest. They are the one whose location data you will not have to re-verify from scratch in six months.

If you are still deciding between address types before you get to any of this, datacenter versus residential proxies covers which one your job actually needs, and the residential pool is where country, city and ASN targeting lives. Run the checks above on whatever you buy, ours included. The whole point is that you should not have to take the dropdown's word for it.