Blog / IP & privacy

Why IP Purity Checks Disagree: Data Sources, Weights, Geo DBs

2026-10-20cdnping editors8 min read

Run an IP purity check on the same exit IP at two different sites and you may get "clean" from one and "high risk" from the other. That is common, and it usually doesn't mean either site is broken. Each site queries different reputation sources, weights each source differently, refreshes its data on a different schedule, and uses a different geolocation database. Squashing all that into a single score magnifies the differences. A more useful approach is to ignore the total and look at each source: which one flagged the IP, and why.

#Where does a purity score come from?

Almost every purity check follows the same pattern: take your exit IP, query several reputation sources, get back a hit/no-hit or a risk value from each, and combine them with some weighting into a score or grade.

None of those three steps has a common standard:

• Which sources to query is up to each site.
• How much each source counts is up to each site.
• How often to query, and how long to cache results, also varies by site.

The IP and environment check on cdnping aggregates 14 reputation sources, including ip-api, proxycheck, IP2Location, StopForumSpam, the Tor exit list, a hosting-ASN list, and DNS blocklists such as DroneBL, SpamCop, Mailspike, Barracuda, UCEPROTECT, s5h and dan.me.uk. The weight of every hit is shown publicly. For how each source decides and where it produces false positives, see How IP purity is scored: the 14 reputation sources, their weights and false positives. This article only covers why sites disagree.

#Cause 1: different data sources answer different questions

"Purity" lumps together several kinds of lists that measure different things. Roughly four types:

A site that only uses a proxy detection database and a site that only uses email blocklists can reach opposite conclusions about the same data-center IP: the first says "it's a proxy", the second says "never sent spam, very clean". Both are right; they are asking different questions.

So when scores differ, first ask which sources each site queried. If a site doesn't publish its source list, treat its score as a rough hint at best.

#Why are data-center IPs always marked down?

Hosting ASN lists and many proxy detection databases judge by network ownership, not by what your machine has done. If your exit sits in a cloud provider's address range, it matches. That doesn't mean the IP has a bad record; it means the IP is "not residential". For how websites tell data-center and residential IPs apart, see Data-center IP vs residential IP: five signals sites use to spot residential addresses.

#Cause 2: the same hit, weighted differently

Say two sites both find that "this IP belongs to a hosting ASN". Site A treats it as a mild signal; Site B treats it as high risk. Same fact, very different totals.

DNS blocklists also differ a lot. Some list only individual IPs confirmed to have sent spam; others list an entire range because of one problem host in it. A hit on the former means this IP itself has a record; a hit on the latter may just be about a "neighbor". A site that treats both kinds equally will be too strict.

The /ip page on cdnping shows the weight of each hit, so you can see which items make up the total. If you think an item doesn't apply to your use case, exclude it and look again.

#Cause 3: update frequency and cache time

Reputation data changes. An IP listed today may expire or be delisted in a few days; when a cloud provider reclaims and reassigns an IP, records left by the previous user may still be attached.

Sites differ in timing in two main ways:

• The sources themselves update on different cycles. A live DNS blocklist query reflects the current state, while an offline database downloaded locally may be a snapshot from days or even weeks ago.
• The checking site's own cache. To cut down on queries, many sites cache an IP's result for a while. What you see on Site A may be fresh, while Site B shows a result from several days ago.

If two results conflict, re-testing on the same site after some time often tells you more than bouncing between two sites.

#Cause 4: different geolocation databases

Many purity results include an "IP location", and some treat a mismatch between geolocation and registration country as a risk signal. But geolocation databases routinely disagree with each other: some locate by network registration data, some by measurements, and their update times differ.

That is why cdnping has 11 geolocation databases vote on the location and report a confidence level. When most databases agree, confidence is high; when they clearly disagree, the IP's location is itself disputed, and the "location" from any single site shouldn't be taken too seriously. The range registration data from an RDAP query is shown alongside, so you can compare it with the geolocation result.

Geolocation disagreement is closely tied to the "native IP vs broadcast IP" question; for the concepts, see Native IP vs broadcast IP.

#Cause 5: the two sites may not see the same IP at all

This is often overlooked. These situations can make two sites measure different exits:

• Dual-stack networks: Site A supports IPv6 and your browser uses the IPv6 exit; Site B is IPv4-only and sees the IPv4 exit. The two exits can have completely different reputations. See IPv6 proxy not working: why IPv4 and IPv6 exits differ on dual-stack networks.
• Split routing rules: A proxy or corporate network routes by domain, so Site A is reached directly and Site B goes through the proxy. Sites inside mainland China and sites abroad then see different IPs. You can confirm this with the mainland China split-routing check.
• Multiple exits: Some networks use different exits for different destinations. The multi-exit check on /ip compares the addresses seen by the Cloudflare traces of Claude, ChatGPT and Grok.

So before comparing two results, first confirm that they show the same IP.

#How to verify an IP's purity yourself

This procedure doesn't depend on any site's total score and is useful when results conflict.

#Step 1: confirm the exit IP, checking IPv4 and IPv6 separately

# Get the IPv4 / IPv6 exit separately (Cloudflare trace returns an ip= line)
curl -4 -s https://www.cloudflare.com/cdn-cgi/trace | grep ip=
curl -6 -s https://www.cloudflare.com/cdn-cgi/trace | grep ip=

# You can also look up your exit via DNS
dig +short txt ch whoami.cloudflare @1.1.1.1

Compare the IPs you get with the IP shown on each checking site's page. If they differ, fix the exit question first, then worry about purity.

#Step 2: check the network's ownership

whois 203.0.113.10 | grep -iE 'netname|orgname|org-name|descr|country|origin'

(203.0.113.10 is a reserved documentation address; replace it with your own IP.) Look at the ASN and the organization name. If it is a cloud provider, hits from hosting-ASN and proxy-detection sources are expected and nothing to worry about.

#Step 3: query DNS blocklists directly

A DNS blocklist is queried by reversing the four octets of the IP and prepending them to the list's domain. For example, for IP 203.0.113.10:

IP=203.0.113.10
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
for BL in dnsbl.dronebl.org bl.spamcop.net bl.mailspike.net \
          dnsbl-1.uceprotect.net all.s5h.net; do
  R=$(dig +short $REV.$BL A)
  echo "$BL -> ${R:-not listed}"
done

A 127.0.0.x address means listed; an empty answer means not listed. If your system DNS uses a large public resolver, some lists may refuse to answer or return an error code; in that case query through your own resolver or your ISP's. For the meaning of specific return codes, follow each list's own documentation. Some lists limit query volume or usage; a few occasional lookups are fine, but read their terms before using them in bulk.

#Step 4: on /ip, read each hit instead of the total

Open /ip and go through the purity section item by item:

• Which type of source hit (proxy detection, hosting ASN, email blocklist, abuse / Tor);
• How much each item weighs and which items contribute most to the total;
• Whether location confidence is high and whether the 11 databases agree.

#Step 5: use the table below to draw a conclusion

The point of these checks is to understand your own network, troubleshoot false positives, and, if an IP really does have a problem, go through proper channels to fix it. Each platform's risk controls and regional policies are governed by that platform's terms of service; please also comply with local laws and regulations.

#Besides the IP, what else affects whether you "look clean"?

Purity looks only at the IP. Real websites usually also consider the browser environment, such as whether time zone, language and fonts match the IP's location, and whether WebRTC exposes another address. These don't enter the purity score but do affect how you should read the overall picture. See Browser fingerprint and environment checks and DNS leaks and WebRTC leaks.

If you want to check exit IP, DNS, IPv6 and latency in one pass, follow the order in the Developer network self-check list (2026 edition). The data sources and calculation methods behind each cdnping check are documented on the Methodology page.