How we measure

Where the data comes from

Most of it is published by the operator of the network in question, which is the only source that can be authoritative about it.

Cloud and hosting ranges

Taken from the providers themselves: AWS ip-ranges.json, Google Cloud, Oracle Cloud, DigitalOcean and Zscaler all publish their own address space. A range is classified as hosting because its operator says it is hosting, not because we guessed from a hostname.

Crawler ranges

Google publishes separate lists for its crawlers and its user-triggered fetchers; OpenAI publishes GPTBot, ChatGPT-User and SearchBot; Anthropic publishes ClaudeBot; Perplexity, Apple and DuckDuckGo publish theirs. We read each operator list directly rather than pattern-matching user-agent strings.

Privacy relays

Apple publishes the iCloud Private Relay egress ranges as a CSV, which is why Private Relay traffic can be identified as a relay rather than lumped in with VPNs. These are paying consumers on a default-on feature, and treating them as anonymisers is a common and expensive mistake.

Threat and routing data

Spamhaus DROP for hijacked and criminal-leased netblocks, abuse.ch Feodo Tracker for botnet command-and-control addresses, RIPEstat for announced prefixes, and iptoasn for ASN assignment. Feeds are selected partly on licence: we only ingest sources whose terms permit commercial use.

Tor

The Tor Project publishes its exit relay list, so Tor detection is a lookup rather than an inference. This is the one category in this field where enumeration is genuinely complete, which is why its coverage is the highest of any flag we return.

How claims get verified

A user agent is not evidence

Any client can claim to be Googlebot, and the ones worth catching do. A user-agent string is treated as a claim to be checked, never as an identity.

Forward-confirmed reverse DNS

To verify a crawler we reverse-DNS the address, check the hostname belongs to the operator domain, then forward-resolve that hostname and confirm it maps back to the same address. Anyone can send the string; only the operator controls both directions of DNS.

Verified crawlers are exempted, not scored

An address that passes verification is exempted before scoring runs, rather than being scored and then forgiven. That ordering matters: it means a legitimate crawler cannot accumulate a risk score through sheer volume.

How the risk score is built

The score is a weighted sum of signals, clamped to 0-100. The weights are visible here because a score you cannot interrogate is not evidence.

Default weights

Malicious 90, Tor 85, proxy 75, crawler 60, VPN 45, country 40, datacenter 35, timezone mismatch 15. Every weight is adjustable per account, so a site that genuinely wants to refuse all VPN traffic can say so explicitly rather than having that policy smuggled into a default.

Why VPN sits at 45

It is deliberately below the 50 threshold our WordPress and WooCommerce plugins ship with, so a VPN flag alone does not auto-block. A VPN carrying additional evidence still crosses 50. Blocking VPN traffic outright is an explicit choice an administrator makes, not a side effect of a default.

A flag is not a verdict

In our August 2026 measurement of 93,414 scored addresses, 30.3% carried a datacenter flag while only 2.2% scored 50 or above. Acting on the flag alone refuses roughly a quarter of ordinary traffic to address a two-percent problem.

The distribution is a barbell

Of those 93,414 addresses, 75.4% scored 0 and only 16 landed in the entire 50-64 band. Traffic clusters at clearly clean and clearly risky, so tuning a threshold by five or ten points changes the outcome for almost nobody. What changes outcomes is which categories you choose to act on.

Community reputation, and the line we draw

Customer sites report blocks back. What counts toward an address reputation is restricted on purpose.

Behavioural reasons count

SQL injection, XSS, command injection, path traversal, file probing, scanner user-agents, repeated failed logins and mass automated signups are evidence the address did something. Only these propagate to reputation.

Policy reasons do not

If a customer configured their plugin to refuse Tor, VPNs or a whole country, that block says something about the customer configuration rather than about the address. Counting it would make reputation circular - an address would score highly simply because many sites had a rule for its category. Policy blocks are logged for the customer own audit trail and go no further.

Single reports do not move an address

Softer signals require multiple independent events before they count at all, so one misconfigured site cannot brand an address on its own.

What we are less sure about

The limits are part of the method. Treating every category as equally solid would be the error.

Residential proxies are the hard case

When the exit is a real consumer device on a real ISP, there is often nothing in the address itself to find. Detection there rests on behaviour and pool membership, both of which need volume and time, and neither of which is conclusive on a single request.

Coverage differs by category

Tor detection is near-complete because the list is published. Datacenter and VPN classification are strong because they follow registered network ownership. Proxy detection is weaker. We publish these as different numbers rather than one blended accuracy figure, because a single number would hide exactly the variation that matters.

Shared and mixed networks

Carrier-grade NAT puts many subscribers behind one address, and some ISPs sell broadband and server hosting from neighbouring ranges. We found 4,532 of 92,518 addresses (4.9%) on a network flagged as hosting and residential at once, across only 71 of 99,737 networks - but those few include some of the largest consumer ISPs in the world.

Geolocation precision

Country-level geolocation is reliable enough to build policy on. City-level is not, and we say so rather than selling the precision implied by returning a city name.