A while ago a friend who runs an online shop sent me a screenshot: the platform had told him his account signed in from Harbin. He had been in Dongguan the whole time, so his first reaction was that the account had been stolen. He changed the password overnight and then asked me how to find out where an IP comes from. I told him not to panic and to send me the number. Once I had looked up the location and the carrier, it was clearly a cloud server, and later it turned out a colleague in their Guangzhou operations team had hooked up an automation script. That made me realise that with IP location the lookup takes seconds; the hard part is understanding what it can and cannot tell you.
1. Who an IP actually belongs to
Public IPv4 addresses are handed down like this: the global allocation body gives large blocks to the regional registries, the registries pass them to local carriers and cloud providers, and the carrier slices a range into the address pool of a metro network or a data centre. So an address like 36.7.x.x really means one number in one pool belonging to China Telecom, not a house on a particular street. Location lookup reports where this range is allocated, not where this device is sitting right now.
Three everyday facts; understand them and you will not misread a result:
- A public IPv4 address often has a crowd behind it. IPv4 is a 32-bit address space with a theoretical ceiling of about 4.3 billion, long since exhausted, so home broadband generally goes through carrier-grade NAT and a whole neighbourhood shares one exit. When thirty people in an office open your site at once, the server log shows only the single leased-line exit address.
- The address changes. Redialling a home broadband connection can move you to another range; a phone on airport wifi and a phone at home take completely different exits.
- Private addresses cannot be looked up.
10.x.x.x,172.16to172.31.x.xand192.168.x.xare private ranges that take no part in public routing, and no public query of any kind can give a geographic position for them.
2. A location is computed, not measured
When you enter an IP, the tool looks it up in a table of address ranges against regions, usually called a GeoIP database, and finds the narrowest record that covers it. Where does that table come from? From the public allocation statistics of the regional registries, which show who holds which block, from carrier disclosures, and from latency and routing data measured by a large number of probe nodes. Because it is assembled rather than measured, it has two built-in weaknesses: the granularity stops at city level, and updates lag. A carrier can rearrange an address pool and the table may take months to reflect it.
3. What it can and cannot tell you
| Can confirm | Cannot confirm |
|---|---|
| Country, province, city, usually to city level, districts are not guaranteed | Street and house number, and the specific person behind the screen |
| Carrier (ISP): China Telecom, China Unicom, China Mobile, or a cloud provider | The other side's real physical location, because through a proxy or VPN you are looking at its exit node |
| Your own current exit IP, to check whether a proxy is working or whether broadband changed address | The true origin of a visitor on a site behind a CDN, since the log records the edge node address |
IPv6 addresses too, 128 bits, of the form 2001:db8::1 | Any geographic information for a private IP |
The second column is not me making excuses for the tool, it is the physical boundary of the whole exercise: locating an individual is something a competent authority obtains from a carrier under legal process, and no public web tool should or can produce that. Anyone claiming precision down to a house number is exactly the signal to be wary of.
4. How I actually investigate a sign-in from elsewhere
- Pull the addresses out of the log and deduplicate them. Paste a few hundred lines of access log into Text Sort and Dedupe, choose dedupe keeping the first occurrence, and read the total line count, the deduplicated count and the duplicate count. First find out how many distinct sources there really are; a lot of suspicious traffic turns out to be repeated requests from one IP.
- Keep only the IP field. Use Regex Tester, which has a built-in IP address pattern; adapt it to the log format and the addresses come out, with live highlighting so you can see immediately whether it grabbed the wrong thing.
- Check location and carrier one by one. Enter the IPv4 or IPv6 address in IP Lookup and read the city and carrier. What matters here is not which city but the type of carrier: a broadband range of a major carrier, a mobile range, or a cloud data centre range.
- A data centre IP calls for a different explanation. A cloud provider range means a script or a proxy exits from there, which has nothing to do with where the person lives. My friend's case ended at this step.
- Align the timeline. The same account at 10:02 in Dongguan and at 10:47 in Harbin is physically impossible, and that is what counts as an anomaly. A location far from home on its own is not one: a business trip, a holiday, a redial at home or a company routing traffic through headquarters can all explain it.
- Check whether the site sits behind a CDN. If the visitors in the log cluster in a handful of cities and only two carriers appear, you are probably recording node addresses. In that case read the leftmost entry in
X-Forwarded-For, but that header can be filled in by the client, so without validation it cannot be used to determine origin.
5. A few boundaries to remember
- City level is as far as it goes. A city holds millions of people, so location equals suspect is a wrong inference, and using it as a conclusion will get someone wrongly accused.
- Two tools disagreeing about one IP is normal. It usually means the range was recently reallocated, or one vendor's database is older. Do not treat any single lookup as an official registration.
- On a mobile network the location may be the registered location of the SIM or the backbone exit, not where the phone is.
- What it is good for: judging roughly where traffic comes from, filtering out obvious data centre crawlers, mapping the regional distribution of visits to your own site, and checking whether your exit IP has changed.
- What it is not good for: deciding that a particular person did something, using it as evidence in a dispute, or publishing on a public page that a given IP corresponds to a given place and person. That last one is both a capability problem and a compliance problem.
6. Common questions
Q: Can an IP reveal someone's exact address?
No. A public lookup stops at city level, and behind NAT one exit address may serve dozens or hundreds of users at the same time. Getting down to an individual is only possible for a carrier and a competent authority following legal process.
Q: Why is the city different from where the other side actually is?
In order of likelihood: the other side is on a proxy or VPN, so you see the node; the site is behind a CDN, so you see the edge node; the IP database lags; their company shares a leased-line exit in another city; or a mobile network reports the registered location of the number.
Q: If the other side uses a VPN, which location is shown?
The location of the VPN server, usually together with a data centre style carrier label. When you see a city plus a cloud provider, read it as a proxy exit, not as a clue to identity.
Q: Every visitor in my site analytics shows the same city, is the data wrong?
More likely a configuration problem: the log is recording the CDN origin-pull address or a private address behind a load balancer. Check that X-Forwarded-For is written to the log correctly before analysing the data.
Q: Does IPv6 location lookup work too?
Yes, both IPv4 and IPv6 are supported. IPv6 is 128 bits and its blocks are organised differently from IPv4, database coverage varies by source, and the result is occasionally coarser than for IPv4.
My friend's case turned out to be a false alarm, but he learned more from it than I had told him: IP location is a clue, not a conclusion. It can narrow the range from the entire country to one city and one kind of network, and the rest of the judgement depends on matching the timeline, the account's behaviour and other logs. If you really suspect a hijacked account, change the password, turn on two-factor authentication and ask the platform for the sign-in history; that is far more useful than looking up the same IP over and over.