Blog / IP & privacy

IP Purity Score Explained: 14 Reputation Sources and Weights

2026-10-17cdnping editors10 min read

On cdnping, the IP purity score is 100 minus the IP risk value. The risk value is the sum of the weights of individual risk signals, capped at 100. The signals come from 14 public reputation sources, and for every hit the page lists the source and its weight. When the purity score is low, you can look at which items hit and how many points each cost, instead of guessing from a single total.

Below, each source is covered in turn: what it checks, how much it weighs on cdnping, where false positives tend to come from, and finally the order in which to read your results. The weights in this article match the rules on the methodology page as of the publish date (2026-10-17). If they change later, that page is the source of truth.

#How the risk value is calculated: group first, then cap

cdnping does not simply add up the results of all 14 sources. It first merges checks of the same kind into a group, caps each group, and then adds the groups together:

Risk value = sum of matched weights (capped at 100). Purity = 100 − risk value.

Group caps prevent double counting. ip-api, proxycheck, and IP2Location rely on similar underlying data when they judge proxies, so one fact flagged by all three should not count as triple the risk. Also, when Tor is matched, the proxy group is not scored separately, because a Tor exit is itself a kind of proxy.

Here is a hypothetical example. A cloud server's IP is flagged as hosting by ip-api (25), its ASN is on the hosting list (15), and its registration data contains "hosting" (15). The datacenter group subtotal is 55, which is capped at 35. If ip-api also flags it as a proxy (30), the proxy group scores 30. With no other hits, the risk value is 65 and the purity score is 35. What that score means is "this is a datacenter egress, and one database thinks it is a proxy." It does not mean the IP has done anything bad.

#What the 14 sources check, and where they go wrong

#Proxy and type databases: ip-api, proxycheck, IP2Location, freeipapi

These four are IP databases. They mainly answer two questions: is this IP a proxy or VPN exit, and is it in a datacenter range.

• ip-api: provides three flags, proxy, hosting, and mobile. proxy counts in the proxy group (30), hosting counts in the datacenter group (25), and mobile costs nothing and is only used to classify the type as a mobile network.
• proxycheck: returns whether the IP is a proxy, its type (such as Hosting, Business, TOR), and a 0–100 risk score. Proxy counts 30, type Hosting counts 20, and when the risk score is ≥ 33 an extra "risk score ÷ 5" is added, up to 20.
• IP2Location: uses only the is_proxy field; a hit counts 20.
• freeipapi: the proxy flag counts 20.

Where they misjudge: most of these databases infer from range ownership, scan results, and historical observation, and they update with a delay. A range that just changed hands, moved from a datacenter to an enterprise leased line, or was briefly used as a VPN and then retired can keep a stale flag. Places where many people share one IP, such as corporate egress, campus egress, and carrier-grade NAT (CGNAT) at ISPs, are also easily mistaken for proxies.

#Hosting ASN list and datacenter keywords

• Hosting ASN list: cdnping uses a public list of hosting ASNs. If the autonomous system that owns the egress IP is on the list, it counts 15.
• Datacenter keywords: words such as hosting, server, datacenter, vps, cloud, idc, and the Chinese terms for "data center," "cloud service," and "machine room" are matched against RDAP registration data and the ISP and organization names. A hit counts 15. This item is cdnping's own rule, not an external source.

Where they misjudge: ASNs are assigned per autonomous system. A provider that sells both cloud hosting and enterprise access may have its enterprise lines swept into the hosting list along with the rest. Keyword matching is coarser still, since a company with "cloud" in its name is not necessarily selling servers. That is why both items carry modest weights, and together with ip-api and proxycheck they sit in the datacenter group, which totals at most 35.

#StopForumSpam: abuse records

StopForumSpam collects IPs that forums and websites report for spam registrations and spam posts. cdnping scores it by the number of records and how recently the last one appeared: a base of 10, higher with more records, plus 5 if it appeared within the last 90 days, up to 25.

Where it misjudges: mainly shared egress. Many people can sit behind one IP, and if one of them posted spam, everyone is affected. When a dynamic IP is reassigned by the ISP, the old records follow the IP, not the person. When you read this item, check the time of the most recent record. Records from several years ago have limited value.

#Tor exits: Tor Project list and dan.me.uk

The Tor Project publishes a list of Tor exit nodes, which cdnping fetches periodically. dan.me.uk offers Tor exit checks via DNS queries. A proxycheck type of TOR and the torexit flag from StopForumSpam also count. A hit from any source counts 60.

This is the highest single-item weight. The Tor exit list is published by the Tor network itself, so the judgment rests on a clear basis, not on inferred traits.

Where it misjudges: rarely, and mostly a matter of timing. After an IP stops being a Tor exit, each list removes it at a different time, so for a short while one or two sources may still hit.

#Six DNS blacklists

DroneBL, SpamCop, Mailspike, Barracuda, UCEPROTECT (L1), and s5h are all DNSBLs. The four octets of the IP are reversed and prepended to the list's domain name for a DNS query, and a return of 127.0.0.x means the IP is listed. Each hit counts 8, up to 24.

What each list focuses on:

Where they misjudge: most of these lists were designed for mail servers. Home broadband IPs are not supposed to send mail directly, and some lists include whole dynamic address ranges, so a hit does not mean you did anything. Removal rules also differ: some lists require a request, others expire automatically. Also, cdnping queries DNS blacklists for IPv4 only. For an IPv6 egress this group is not queried and not scored.

#Broadcast IP and geolocation disagreement

These two items do not come from reputation databases. They are derived from cdnping's geolocation results:

• Broadcast IP (10): RDAP registration data shows the range is registered in country A, but the majority vote of 11 geolocation databases says it is in country B. Such ranges are usually announced across regions. For the underlying idea, see Native IP vs broadcast IP.
• Geolocation disagreement (5): at least 4 databases took part in the vote, and fewer than 60% of them place the IP in the winning country. This is common for newly allocated or frequently transferred ranges.

Where they misjudge: large enterprises and cloud providers often use ranges registered in one region in other regions, which the rules classify as broadcast. The registration data itself can also be out of date.

#Why different checkers give different scores

For the same IP, scores can differ a lot between checkers. Common reasons:

1. Different sources. Some sites use only one or two commercial databases, some include mail blacklists, and some add their own traffic observations.
2. Different weights. For the same datacenter IP, some sites deduct heavily and others barely deduct at all. cdnping caps the datacenter group at 35 because a datacenter egress does not by itself mean risk.
3. Different direction. Some sites show a risk score where higher is worse; others show purity or a reputation score where higher is better. Confirm the direction before comparing.
4. Different freshness. Databases update on different schedules, and checkers generally cache external lookups, as cdnping does too. When an IP has just changed purpose, sites do not catch up at the same time.
5. Different egress. A check run in the browser sees the browser's egress, while a command-line tool sees the terminal's egress. With split-routing rules enabled, these may not be the same egress.

So the total score from a single site is of little use. It is more useful to look at the hits it lists and compare them with the hits from another site.

#In what order to read your results

Open IP and environment check, wait for all checks to finish, and go through the table below:

To check an egress outside the browser, you can use Cloudflare's trace endpoint in a terminal to see the IP the command line actually uses:

# Show the terminal's egress IP, Cloudflare colo, and country code
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|colo|loc)='

Compare the ip in the output with the IP shown at the top of the /en/ip page. If they differ, the browser and the terminal use different egresses, and you need to check the purity of each one separately.

#How to generate a result image and hide your IP

To send results to a coworker or paste them into a ticket, you can export the check results as an image:

1. On /en/ip, once all checks have finished, "Copy report" and "Generate result image" buttons appear in the results area.
2. If you do not want others to see your full IP, click "Hide IP" first. Your own egress IPs on the page (including those in the multi-egress and WebRTC checks) keep only the first two octets, so an IPv4 address shows as something like 1.2.*.*. Click "Show IP" to restore it.
3. Click "Generate result image". The image contains the IP purity score, IP type, native or broadcast judgment, environment consistency score, mainland China split-routing verdict, and each check item, with a cdnping watermark. When Hide IP is on, the IPs in the image are masked too.
4. If you only want text, use "Copy report", which also respects the hide state for IPs.

Browser fingerprint checks are all computed locally and are not uploaded.

#What the purity score can and cannot tell you

The purity score describes how public reputation sources view this IP. It cannot predict how a particular website or platform will treat you. Each platform has its own risk-control rules, and they are not made public.

Low purity is most often caused by datacenter egress and shared egress, and does not necessarily mean the IP did anything bad. High purity does not mean you can ignore terms of service either: when using AI services, follow the supported regions and terms published by the provider, and comply with local laws. Neither this article nor cdnping offers ways to bypass a platform's region restrictions or risk controls.

#Next steps

• Open /en/ip and go through your egress item by item using the table above, noting the hits.
• Check the current weights on /en/methodology. cdnping started collecting data on 2026-10-17, and the rules will be adjusted based on feedback; changes are recorded on that page.
• If you are checking your IP because AI API calls are failing, first look at API status to rule out a server-side outage, then come back to check your egress. AGI Plan is a commercial partner of cdnping, and /en/status/agiplan mirrors AGI Plan's public availability data, read the same way as the status pages for other services.