You have an IP address. Maybe it's hammering your login endpoint, maybe it appeared in a server log at 3am, maybe a user claims they're in Frankfurt but your latency graph says otherwise. Tracing where that IP sits geographically and who operates it is a five-minute job, and this guide covers how to do it properly.
It also covers what geolocation can't tell you, because the gap between what IP tracing actually does and what TV crime dramas claim it does is enormous.
What IP geolocation actually is
There's no location field in an IP packet. Geolocation works by cross-referencing the address against databases built from regional internet registry (RIR) allocations, ISP-published data, BGP routing information, and latency measurements. Commercial providers like MaxMind and IP2Location maintain these databases and update them continuously.
That means accuracy is probabilistic and degrades as you zoom in:
- Country - reliable. This is the level RIR allocation data operates at, and it's correct the vast majority of the time.
- Region / state - usually right, occasionally a neighbouring region.
- City - approximate. Often you get the city where the ISP aggregates traffic, not where the user sits. A rural user can resolve to a city 100 km away.
- Street address - never. No geolocation database maps an IP to a building. Anyone claiming otherwise is selling something. The coordinates you see on the map are typically the centroid of the city or even the country.
Keep that hierarchy in mind for everything below. "This IP is in Romania" is a solid finding. "This IP is at 42 Elm Street" is fiction.
Step 1. Collect the addresses
Pull the IPs you care about from wherever they surfaced:
- Web server access logs (
nginx, Apache, your CDN's log export) - Auth logs (
/var/log/auth.logfor SSH brute-force sources) - Firewall or WAF block lists
- Application audit trails
If you're behind a proxy or CDN, make sure you're reading the real client IP (X-Forwarded-For or CF-Connecting-IP), not the proxy's address. Geolocating your own CDN edge node tells you nothing.
Step 2. Run the geolocation lookup
Open the IP Geolocation tool and paste the address. You'll get back:
- Country, region, city - with the accuracy caveats above
- ISP / organisation - who the address is allocated to
- ASN - the autonomous system announcing the route
- Connection type hints - hosting provider vs residential ISP vs mobile carrier
The ISP and ASN fields are frequently more useful than the map pin. An IP belonging to "DigitalOcean" or "Hetzner" is a rented server, not a person at home. An IP belonging to "Comcast" or "Deutsche Telekom" is a residential or business line. That distinction matters more for most investigations than which city the pin lands in.
Step 3. Cross-check with reverse DNS and WHOIS
A single data source is a hint. Two or three agreeing sources is a finding.
Reverse DNS - run the IP through the Reverse DNS Lookup. The PTR record often encodes useful structure: static.88.198.x.x.clients.your-server.de confirms a hosting provider; c-73-x-x-x.hsd1.wa.comcast.net confirms a Comcast residential line in Washington state. No PTR record at all is common and not suspicious on its own.
WHOIS - run the IP through the WHOIS Lookup. This returns the registered owner of the netblock, the allocation date, and crucially the abuse contact - the email address you'll need if you're reporting malicious activity to the network operator.
When geolocation says "Netherlands", the PTR says *.nl-ams-1.linodeobjects.com, and WHOIS says the block belongs to Linode, you have a consistent picture: a rented VPS in Amsterdam.
Step 4. Check for VPN, proxy, and Tor indicators
The location you resolve is the location of the address, not necessarily the person. Common signs the IP isn't an end user's real connection:
- The ASN belongs to a hosting provider (AWS, OVH, Hetzner, M247) rather than a consumer ISP. Most VPN endpoints live in datacentres.
- The organisation name literally contains "VPN", "proxy", or a known provider name.
- The IP appears on the public Tor exit-node list.
- Reverse DNS resolves to a generic hosting hostname.
None of these prove anything malicious. Plenty of legitimate users browse through VPNs. But it means "the attacker is in Sweden" should be read as "the attacker's exit point is in Sweden."
Step 5. Map patterns across multiple addresses
One IP is an anecdote. For a real investigation, geolocate the whole set and look for structure:
- Same ASN, scattered IPs - one actor cycling addresses within a single provider. Block the netblock or rate-limit the ASN, not individual IPs.
- Many countries, identical request signature - a botnet or rented proxy pool. Per-IP blocking is whack-a-mole; move mitigation to the application layer (see our DDoS response guide).
- Single residential IP, persistent - the easiest case to act on via the WHOIS abuse contact.
A quick shell pipeline gets you a frequency table to start from:
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
Then run the top offenders through the geolocation tool.
Step 6. Document the findings
If this is for an abuse report or internal security write-up, record for each IP: the address, timestamp range of activity, geolocation result (with the database/tool used), ASN and netblock owner, reverse DNS, and what the traffic was doing. Abuse desks act faster on reports with timestamps and log excerpts than on "this IP is attacking me."
Legitimate uses, and the limits
IP tracing is a standard tool for:
- Abuse investigation - identifying which network operator to report a brute-forcer or scraper to.
- Log forensics - answering "was this login from a plausible location for this user?"
- CDN and routing debugging - verifying users are hitting the edge node nearest them, or why traffic from one region has 300 ms latency. Pair it with the Ping Test to confirm what the geography implies.
- Fraud signals - a "local" customer ordering from a hosting-provider IP on another continent is a flag worth weighing.
What it is not for: identifying an individual. An IP maps to a network allocation, not a person. The subscriber behind a residential IP can only be identified by the ISP itself, under legal process. If your situation is serious enough to need that, it's serious enough for law enforcement.
Common mistakes
Treating the map pin as precise. The pin is a city or country centroid. There's a well-documented history of default database coordinates landing on innocent people's homes. Country: trust it. City: approximately. Anything finer: no.
Geolocating the proxy instead of the client. Check X-Forwarded-For handling before you waste an hour investigating your own load balancer.
Forgetting that mobile IPs travel. Carrier-grade NAT means one mobile IP can represent thousands of users, and the geolocation often points at the carrier's gateway city, not the handset.
Stopping at geolocation. The ASN, WHOIS owner, and reverse DNS usually carry more investigative weight than the coordinates. Use all three.
TL;DR
- Pull the IPs from your logs (real client IPs, not proxy addresses).
- Run each through the IP Geolocation tool - note country, ISP, and ASN.
- Cross-check with Reverse DNS and WHOIS; grab the abuse contact.
- Check for hosting/VPN/Tor indicators before trusting the location.
- Map patterns across the full IP set, not single addresses.
- Trust country-level results, treat city as approximate, and never expect a street address.
Related
- IP Geolocation tool - the lookup this guide is built around
- Reverse DNS Lookup - PTR records for cross-checking
- WHOIS Lookup - netblock ownership and abuse contacts
- MAC address forensics - the layer-2 counterpart to IP-level investigation