VisitorOpsB2B visitor identification and lead-magnet operations

Free interactive tool

Cloud IP Checker: Server, Relay or Real Company?

Reverse-IP identification names a company from the network a visit came from. When that network is a cloud provider, a CDN or Apple’s iCloud Private Relay, the name is either the provider itself or a guess. This checker looks up the addresses you paste in the IP ranges that AWS, Google, Microsoft Azure, Oracle, DigitalOcean, Cloudflare, Fastly and Apple publish, and tells you which “identified” visits to hold, which to exclude as non-human, and which are real people whose company no IP can reveal.

How the check works

for each address:
  find every published range that contains it   (IPv4 and IPv6, CIDR containment)
  keep the smallest (most specific) range         → provider, region, kind
  (same size in two lists: relay, then CDN or cloud, then provider)

kind      cloud     customer compute: AWS EC2 and other services, Google Cloud, Azure, Oracle, DigitalOcean
          cdn       CDN or proxy network: Cloudflare, Fastly, Amazon CloudFront
          relay     Apple iCloud Private Relay exit
          provider  the provider's own network: goog.json outside cloud.json, AWS AMAZON-only ranges
          none      in none of the lists

The ranges are this site’s dated copy of each provider’s published file (the date is shown under the result), built by a script that reads the official URLs below. Only the smallest matching range sets the verdict: a Google Cloud address is also inside Google’s all-ranges list, and the more specific Cloud range wins, including when both lists carry the same block. Adjacent prefixes with the same provider and region are merged in the copy, so the range shown can be wider than one published prefix. No match is not a clean bill: home broadband, mobile carriers, corporate networks and every hosting provider not listed here all show as “not in these lists”.

Check your addresses

IPv4 and IPv6. Ports and duplicates are ignored; up to 1,000 distinct addresses per run. The lookup runs in your browser: the addresses are not sent anywhere. The prefilled list is sample addresses from the published ranges plus two documentation addresses.

LoadingLoading the published ranges…

Worked example (hypothetical numbers)

A marketing-ops lead sees Amazon, Google and Microsoft among the top “companies” in the vendor’s weekly report. She exports last week’s 250 identified visits with their IP addresses and pastes the IP column in (hypothetical numbers). The checker finds 38 cloud addresses (15.2%), 21 Private Relay (8.4%), 4 CDN, 6 Google-owned outside Google Cloud, and 181 in none of the lists.

She compares the flagged rows with the company names the vendor attached. Of the 38 cloud addresses, 31 carry the name of the cloud provider itself (Amazon, Microsoft or Google): they go on the exclusion list as servers and bots, not buyers. The other 7 are named as other companies and go to a hold queue; one turns out to be a customer’s VPN hosted in Azure, which is exactly why they are held rather than dropped. The 21 relay visits are real people, so they stay in the match-rate denominator as unidentifiable traffic and stop being counted as vendor misses. The 181 unflagged visits go through the match-quality audit as usual.

Why do reverse-IP tools show Amazon, Google or Microsoft as visitors?

A reverse-IP match looks up who registered the network an address belongs to. For a visit from a cloud server, that owner is the cloud provider, so the report shows “Amazon” or “Microsoft” although no one there looked at your site. Those visits come from uptime monitors, crawlers, link-preview and security scanners, and scripts. A vendor may filter some of them; the checker lets you see how many reach your report.

The harder cases are the ones the vendor names as some other company. A company can route its staff through a VPN or secure web gateway hosted in a cloud, or give them cloud desktops, so a cloud address can hide a real employee. The address alone cannot tell you which. That is why the verdict for cloud addresses is “hold for a second signal”, not “delete”.

What should you do with each verdict?

  • Cloud, named as the cloud provider: exclude from alerts and from the working match-rate denominator (D2 in the match-rate guide), the same as other non-human traffic.
  • Cloud, named as another company: hold. Route only when a form fill, a known contact or a CRM match confirms the account. The exclusion guide has the hold-queue wording for ambiguous matches.
  • iCloud Private Relay: keep in the denominator, never route. Apple says a relay address can be shared by more than one user in the same area, so any company name attached to it is a guess.
  • CDN or proxy: if many of your addresses land here, the problem is your pipeline, not the visitors. Your server logs or server-side tag are reading the proxy’s address instead of the forwarded client address. Fix that first; every match downstream depends on it.
  • Provider’s own network: Google’s ranges outside Google Cloud carry its own services, crawlers and proxies; AWS ranges listed only under AMAZON are Amazon’s, not a specific customer service. Treat these as non-human unless you have a reason to think otherwise.

Before you add range exclusions in the vendor’s settings, ask the vendor whether it already filters hosting traffic and how. If it does, the flagged rows in your export are the ones its filter missed, which is worth raising with the vendor.

When is the check not enough?

  • Other hosting providers. Only the eight publishers above are checked. Addresses at any other hosting company show as “not in these lists”.
  • Commercial VPNs and consumer proxies. Most do not publish their exit addresses. A commercial IP-intelligence database is the tool for those.
  • Ranges that are not published. AWS says its file covers the services customers commonly filter, not every service, and leaves out addresses customers bring to AWS themselves.
  • Snapshot age. The ranges change. An address added after the snapshot date shows as “not in these lists”; re-run old exports with care.
  • Person-level tools. Vendors that name people use more than the IP. A clean IP result does not confirm a named person, and a cloud IP does not by itself make a named-person match wrong; audit those separately.

Which lists does it check?

Each list is read from the provider’s own URL. The addresses you paste stay in your browser; only the range file is downloaded, from this site.