Partly, and never by measuring. A checker reads who registered the address, which network announces it and what a database claims, then guesses. The interesting part is the second question it answers at the same time: whether the address is a proxy at all.
Start here, because everything else follows from it. There is nothing inside an IPv4 or IPv6 address that says where the machine is. The number identifies a block that was allocated to an organisation, and the only thing the internet genuinely knows about it is which network is currently announcing a route to it. Every map pin you have ever seen next to an address is somebody's inference from paperwork and observation.
So when a proxy inspector prints “United States, Ashburn, Virginia”, read it as a claim with a confidence attached. Country-level claims are right most of the time because allocation records are country-scoped. City-level claims are much weaker, and for mobile carrier ranges they are often nonsense, since one carrier block can serve half a country.
The second thing an inspector reports is usually more consequential than the location: a verdict on whether the address looks like a proxy at all. Those are two different tests, and they use different signals.
Every routable block is announced by an autonomous system, and the mapping from address to AS number is public. Anyone can look it up in seconds:
whois 8.8.8.8 | grep -Ei 'country|org|netname' curl -s https://rdap.arin.net/registry/ip/8.8.8.8 | head -40 dig +short AS15169.asn.cymru.com TXT
Two things come out of that. The registry record gives a country code and the name of the organisation holding the block. The ASN gives the network carrying it — and crucially, what kind of business that network is. This is the test that separates proxy types more sharply than anything else.
A datacentre address belongs to a hosting company's AS. That is not a subtle fingerprint; it is the public identity of the range. A request arriving from a well-known cloud or hosting AS is, by definition, not somebody sitting at home, and any site that cares can act on that with a single lookup and zero false positives about the network type.
A residential address belongs to a consumer ISP's AS, because it is a consumer connection. The same lookup returns a broadband provider, the same class of record as every ordinary customer of that provider. There is no hosting signature to find, which is the entire reason residential exits survive checks that datacentre ranges fail immediately. Mobile ranges behave similarly and are often carried by carrier-grade NAT, so a single address may sit in front of a great many real subscribers.
Most sites do not run their own lookups. They buy a commercial IP-intelligence feed that merges registry data, routing data, latency measurements, submitted corrections and the vendor's own observations into a row per range: country, region, city, connection type, and a risk or proxy score.
Those feeds are the practical answer to “where does the internet think this address is”, and they have one defining weakness — lag. A block can be reassigned, re-announced from another country, or moved from a hosting customer to an ISP customer, and the databases will keep describing it the old way for days or weeks. Vendors also disagree with each other, because they weigh different evidence.
This produces the most common complaint about geo-targeted proxies: an exit sold as one country shows up as another on some checker. Usually neither party is lying. The address is registered and routed where the provider says, and one database has not caught up. The only thing that matters is what the specific site you care about uses, so check against that rather than against a random lookup page.
The same feeds carry the proxy verdict — flags like “hosting”, “VPN”, “public proxy” or a numeric risk score. Open proxies scraped off free lists are in every one of those lists within hours, which is why they fail on sites that never inspect anything else.
A determined checker does not have to trust a database, because physics is harder to fake than paperwork. Light in fibre plus switching overhead sets a floor on round-trip time between two points. An address claiming to be in Sydney that answers a probe from a Frankfurt vantage point in 12 ms is not in Sydney; that trip cannot be made in the time. Measure from several vantage points and you can bound the true position inside a region even when every database says otherwise.
ping -c 5 TARGET_IP
mtr -rwzc 10 TARGET_IP
curl -o /dev/null -s -w 'connect %{time_connect}s total %{time_total}s\n' https://TARGET/
Latency proves an address is not somewhere far more convincingly than it proves where it is, and it is only as good as the vantage points used, so it tends to appear as a supporting signal rather than a verdict on its own.
Port fingerprinting is the other active check. Scanning an exit address and finding proxy or tunnel services listening — an open SOCKS or HTTP proxy port, a management panel, a VPN daemon — says plainly what the machine is for. Residential lines mostly answer nothing on the way in, which again is the difference in kind rather than degree. Traceroute shape helps too: the hop pattern into a datacentre and the hop pattern into a subscriber line through an ISP's access network do not look alike.
Here is where most people actually get caught, and no proxy of any type can help. The address is one field. The browser volunteers several more, and they are read from your computer:
Intl.DateTimeFormat().resolvedOptions().timeZone returns your operating
system's zone, and new Date().getTimezoneOffset() returns the offset. A US exit with
Europe/Kyiv is a contradiction on its face.en-US,en;q=0.9 is not disqualifying on its own, but combined with a mismatched clock
it stops looking like coincidence.User-Agent, which together describe a machine, not a location, but which stay identical
across every address you rotate through if you do not change them.Any checker page you visit will list these next to the geolocation, and consistency is what it is grading. A convincing session is one where the address, the clock, the language and the fingerprint tell the same story.
Three things, in order of leverage. First, the network class of your exit: choose residential or
mobile when the target cares whether you look like a person, and accept that datacentre ranges are
identifiable as such by anyone who looks. Second, the country and region you exit from, which is a
selection problem rather than a technical one — request the location you need and verify it against the
lookup your target uses, not a generic one. Third, your own client: set the machine's timezone to match
the exit, send a matching Accept-Language, and disable or proxy WebRTC.
Verification is a one-liner. Check what the world sees, then check the registry behind it:
curl -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip # then look up the address that came back whois <returned-ip> | grep -Ei 'country|org|netname'
If the ASN behind the returned address is a consumer ISP in the country you asked for, the strongest signal is in your favour, and the rest is your browser's job. PyProxy sells residential, ISP, mobile and datacenter exits on one balance so the class can be matched to the target; residential speaks HTTP, HTTPS and SOCKS5 with the SOCKS5 side carrying TCP only, which is worth knowing before you write the client. Country selection is a username option, as above.
No. An address carries no physical position. An inspector reads where the range is registered, which network announces it, and what commercial databases claim about it, then infers a location. Country is usually right, city often is not, and every part of it is a claim rather than a measurement.
Because the strongest signal is the autonomous system the address belongs to. Datacentre ranges are announced by hosting companies and that is public, so any request from them is obviously not a person at home. Residential addresses sit inside consumer ISP ranges that look like ordinary subscribers, so the same test finds nothing.
Because the browser reported it. Timezone read from JavaScript, the Accept-Language header and WebRTC candidates come from your machine, not from the proxy, so they keep saying home until you change them. A US exit address with a Europe/Moscow clock and ru-RU language is a contradiction any checker will show.
Not quickly. Vendors refresh on their own schedule and disagree with each other, so an address can be sold as one country and shown as another for weeks. The practical fix is to test the exit against the lookup your target actually uses and pick a different address when they disagree.