Bulk IP Lookups: When You Need to Investigate More Than One Address

Single-IP lookup tools are great for one-off curiosity. You've got an IP, you paste it in, you see the country and the ISP. But the moment you have several IPs to look at — a firewall log, an email's Received chain, a list of suspicious connections from your SIEM — the one-at-a-time workflow falls apart. You're not learning anything by clicking through 30 lookups in sequence; you want to see the shape of all of them together. Which countries dominate. Which ASNs repeat. Which ones cluster at one hosting provider in a way that suggests they're a single actor on rented infrastructure.

That's what bulk IP lookup is for. Paste up to 100 addresses at once, get geolocation / ASN / hostname for all of them, and see the aggregates: X results across Y countries on Z ASNs. Sort by any column, filter by any field, export the whole thing as CSV for a spreadsheet or JSON for a script. Here's what to do with it.

When you need it

The use cases all share the same shape: you have a list of IPs that came from somewhere, and the value is in seeing them together rather than one by one.

• Server and firewall log triage. Your edge logged a hundred connection attempts to a suspicious endpoint in an hour. Paste the source IPs and the aggregate view tells you almost immediately whether it's one actor (most IPs on the same ASN) or distributed traffic (lots of small ASNs, lots of countries). The difference matters for the response.
• Security incident investigation. Your SIEM flagged a cluster of IPs as related to a phishing campaign. You want to know which infrastructure they're running on — hosting providers (probably rented for the campaign), residential ISPs (likely a botnet), or a mix.
• Email investigation. An email's chain of Received: headers names every server that handled it on the way to you. Paste those IPs and trace the route: which country accepted it, which relay forwarded it, where it ultimately came from. Useful when the email-header analyzer finds something suspicious and you want to drill into the IPs.
• Network audit / inventory. Your CDN serves from a list of edge PoPs. Your monitoring shows traffic egressing from a list of NAT outs. Your VPN gateway has IPs in different regions. Bulk-look-up the lot and verify they're where you expect them to be, on the right networks.
• Compliance. Regulations sometimes require you to demonstrate traffic origin or restrict service to certain regions. A spot-check across a representative IP list answers "is this traffic actually coming from where the contract says it's coming from?"
• Mapping attacker infrastructure. Threat-intel reports often publish IOC lists. Pasting all the IPs at once is the fastest way to see what shape that infrastructure has — single ASN means one actor's footprint; many ASNs across hosting providers means the attacker is rotating through commodity rentals.

What each lookup returns

For every IP in the list the tool returns the same per-row data the single-IP IP lookup would, just sixty rows at a time:

• Country + city. Geolocation from the MaxMind GeoLite2 database, which is the de-facto industry standard for free IP geo. We bundle GeoLite2 into the worker so the lookup is local, not a third-party API call.
• ASN + organisation. The Autonomous System Number the IP belongs to, plus the organisation's registered name. AS15169 — Google LLC, AS13335 — Cloudflare, AS7922 — Comcast Cable. ASN is usually the highest-signal field for grouping.
• Reverse DNS hostname. The PTR record for the IP — the name the address resolves back to. Often reveals what the server is (dns.google, ec2-1-2-3-4.amazonaws.com, mail-pf1-f51.google.com). The bulk tool runs reverse DNS for the first 10 valid public IPs only; doing it for all 100 would blow past the worker timeout.
• IP version. IPv4 or IPv6, useful when the same list mixes both.
• Private / public flag. RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), CGNAT (100.64.0.0/10), loopback, link-local, and the IPv6 equivalents are all flagged. Private IPs aren't internet-routable, so they have no geolocation — the tool labels them as private rather than silently returning empty.

Understanding geolocation accuracy

IP geolocation is approximate. It is not GPS. It's not a street address. It's the location an ISP or hosting provider has registered as the broad area an address block serves — which is usually accurate to the city, often only the region, and sometimes wrong in interesting ways:

• Residential ISPs tend to be accurate to the city the customer is in, or at least the city the ISP's POP is in. Comcast in San Francisco, BT in Manchester, NTT in Tokyo. Good enough for most analysis.
• Data centre IPs show wherever the hosting provider has registered the IP block. AWS in us-east-1 shows up as Ashburn, Virginia; eu-west-1 as Dublin. A server physically in another city but using AWS Direct Connect through Ashburn will still geolocate to Ashburn.
• Mobile carrier IPs typically show the carrier's gateway city, which can be hundreds of miles from the actual device. T-Mobile customers nationwide get geolocated to a small number of gateway cities.
• VPN / proxy IPs show the location of the exit node, not the user. A user in Berlin behind a Mullvad node in Stockholm geolocates to Stockholm. (See how VPN detection works for what else IPs reveal.)
• CDN edge IPs show the closest CDN POP, which is often city-accurate but might be the nearest large city rather than the literal one.

For more depth on the accuracy story, see how IP geolocation actually works — short version: it's good enough for the use cases above and not good enough for anything requiring street-level precision.

Reading the ASN column

The ASN is usually the field that tells you the most. Some ranges to recognise:

• Residential ISPs. Comcast (AS7922), AT&T (AS7018), Verizon (AS701), Charter (AS20115), BT (AS2856), Deutsche Telekom (AS3320), Orange (AS5511). These are real consumer connections.
• Cloud and hosting. AWS (AS16509), Google Cloud (AS15169 and AS396982), Cloudflare (AS13335), DigitalOcean (AS14061), Hetzner (AS24940), OVH (AS16276), Microsoft Azure (AS8075). These are server IPs, not human users.
• VPN providers. Mullvad (often M247 / AS9009), Surfshark (AS212238 and others), NordVPN (rotates across many), ExpressVPN (mostly hosting infrastructure). Heavy concentration of VPN ASNs in a list = likely privacy-conscious users.
• Mobile carriers. T-Mobile (AS21928), Verizon Wireless (AS22394), Vodafone (AS12576), KDDI (AS2516). Mobile IPs often have high churn — the same address might serve thousands of different users in a day.

The ASN explorer can expand any ASN to see every IP range it announces, which is useful when the bulk lookup surfaces an unfamiliar ASN you want to dig into. For deeper context on what an ASN actually is, the ASN explainer walks through BGP, peering, and the policy side.

Export — CSV for spreadsheets, JSON for scripts

The export buttons cover the two common downstream cases:

• CSV — opens cleanly in Excel, Google Sheets, Numbers, or any data-analysis tool. RFC 4180 quoting handles commas in organisation names. Useful for filtering ("show me all rows where country = DE"), pivoting ("group by ASN, count"), or just sharing the raw findings with a non-technical colleague.
• JSON — the same data, structured exactly the way the API returns it. Useful when you're piping the results into a script, a SIEM ingestor, or another tool's API. The shape matches the API documentation directly so anything that reads the API can read the export.

The summary cards underneath the table — countries and ASNs ranked by count, with proportional bar fills — are the at-a-glance version of "where is this traffic coming from?" If the country list is dominated by one country and the ASN list dominated by one provider, that's almost always a single actor's infrastructure.

Three concrete patterns

To make the use cases more concrete:

• Log analysis. 50 IPs hit your /wp-admin/ endpoint in an hour. Paste them in. 40 are on a single Romanian VPS provider's ASN. Conclusion: automated scanning from a botnet rental, not a targeted attack — block the ASN at the firewall and move on.
• Email investigation. A phishing email has five Received: headers. Paste those IPs into the bulk tool. The path traces from a US ESP (legitimate sender or compromised account) → a Bulgarian hosting provider (where the attacker probably sat) → your own inbound MX. The middle hop is the lead.
• Infrastructure audit. Your CDN claims to serve from 50 edge PoPs. Pull the egress IPs from your logs, paste them in. You see 40 on the CDN's expected ASN with country distribution matching their published PoP list, plus 10 that look like AWS US-East. The 10 are an internal rewrite path you forgot existed.

What you'll still need single-IP for

Bulk lookup is breadth over depth. For per-IP investigation, the single IP lookup still wins: it shows postal code, latitude/longitude, timezone, whether the IP is on a known blacklist, and the full WHOIS contact. Bulk gives you the patterns; single gives you the narrative for any one row.

And if a particular IP looks worth attacking back at — looking up its DNSBL reputation, or running its ASN through the ASN explorer to see how big its announced footprint is — the right move is to copy that one IP out of the bulk results and into the focused tool. The two workflows compose well.