A foreign-looking IP shows up in an auth log, a fail2ban report, or a web server’s access stream, and the on-call engineer needs to make a quick judgement: is this a customer in a new country, a scanner from a cheap VPS provider, or a residential proxy being abused? Reading raw IP addresses doesn’t tell you that. Reading the network and the geography behind the address usually does, and the PortJar IP Lookup & Geolocation tool delivers both in one query.
What the tool does
It takes any public IPv4 or IPv6 address and returns the geolocation (city, region, country) along with the ISP and the autonomous system that announces the address. Geolocation comes from ipinfo.io and ASN ownership from Team Cymru — two of the more trusted sources in the operational community. The combination matters: a city-level location alone can be misleading on a cloud or VPN IP, but seeing “AS14061 DigitalOcean” or “AS16509 Amazon” next to it tells you instantly that the “São Paulo” label is a data centre, not a person.
How to use it
Open portjar.com/tools/ip-lookup — the canonical path is /tools/ip-info — paste the address in question, and submit. The result is a single page combining the geolocation and the network ownership. If you’re investigating a sequence of addresses, work through them one at a time rather than batch-processing; the context you build as you go (recurring ASNs, recurring countries) is the actual signal.
When you’d reach for it
- Triaging a brute-force attempt against WordPress, SSH, or cPanel. Distinguishing a single attacker from a botnet usually comes down to ASN spread: ten IPs from ten different ASNs across five countries reads differently than ten IPs from the same hosting provider in Lithuania.
- Investigating a sudden traffic spike. When the access log shows ten thousand requests in five minutes, IP Lookup tells you whether the burst came from a single CDN (someone re-cached your homepage), a single AWS region (a bot harvesting your sitemap), or scattered residential addresses (organic traffic from a viral mention).
- Confirming a customer self-report. A client reports their site is “slow from Australia.” Lookup on their reported IP confirms whether they really are in Sydney or whether they’re testing through a US VPN exit — which changes the diagnosis entirely.
- Vetting an inbound webhook source. When an integration partner says their webhooks come from a specific provider, the source IP on the request should belong to that provider’s ASN. If it doesn’t, either the partner is wrong about their infrastructure or the request is forged.
- Investigating a “connection timed out” or “connection refused” report. The PortJar troubleshooting guide on the difference between the two notes that knowing the source network is the first sanity check before any packet capture; this tool delivers that context for the address in the report.
What to make of the output
Trust the ASN field unconditionally — it’s derived from BGP and is as authoritative as IP ownership data gets. Treat the city and region as approximate. For residential ISPs, city accuracy is generally good. For mobile carriers, the geolocation often reflects the carrier’s core network, not the subscriber. For VPNs and cloud providers, the registered location is whatever the operator told the geolocation database — often a headquarters address that’s nowhere near the actual server. If the geolocation says “Mountain View” and the ASN says “Google LLC,” you’re looking at a Google data centre that could be in any of a dozen countries; that pattern alone should refocus your investigation. When the ASN and the geolocation disagree (Brazilian city, German hosting provider), believe the ASN.
For teams who need this context surfaced automatically inside their monitoring and incident workflows, Stack Harbor builds source-IP enrichment into monitoring and support.