Blog / IP & privacy

What Affects IP Risk Score: Network Type, ASN, Proxy Flags and Abuse

2026-10-20cdnping editors8 min read

An IP risk score comes from two kinds of information. The first is what the address is: which ASN it belongs to, whether it is a datacenter or residential line, whether it is a Tor exit. The second is what it has done: whether it has been listed on a mail blocklist or reported for abuse. The first kind follows the network block and rarely changes. The second is time-sensitive and gets added or expires over time. Knowing which kind a score comes from is far more useful than staring at the total.

This article goes through each factor: how it is determined, roughly how much weight it carries in cdnping, how often it changes, and finally a command-line checklist. The weights match the rules on the methodology page at the time of publication; if they are adjusted later, that page is authoritative. For a full description of each source, see How IP purity is calculated: 14 reputation sources, weights and false positives. This article does not repeat them one by one and instead looks at things by "factor".

A note on scope: this is about how public reputation data rates an IP, so you can troubleshoot your own network and servers. Platforms' risk-control rules are not public. This article does not discuss how to bypass them and offers no tricks for "lowering your risk score".

#How is the risk score added up?

cdnping groups signals together. Each group has a cap, the groups are summed, and the total is capped at 100. Purity = 100 − risk score. Other checkers use different algorithms, so it is common for the same IP to get different scores; see Why different sites report different IP purity.

The table below separates the groups into "intrinsic attributes" and "records that change":

#Network type and ASN: why do datacenter IPs score high by default?

An ASN is the autonomous system number that announces the routes for an address block. It maps to a carrier, a cloud provider or a large organization. To decide "datacenter or residential", the first things to look at are the ASN and the block's registration data:

• If the ASN belongs to a cloud or hosting provider, databases such as ip-api and proxycheck flag it as hosting;
• If the RDAP registration data or the organization name contains words like hosting, datacenter, vps, cloud, idc or "机房" (Chinese for "machine room", i.e. datacenter), cdnping adds points;
• If the ASN appears on a public list of hosting ASNs, points are added as well.

In cdnping these are merged into a "datacenter group" capped at 35. The cap exists because a datacenter egress does not by itself mean anything is wrong with the IP. Your own cloud server or your company's egress gateway will hit the datacenter group, and that is a normal result.

This factor is an intrinsic attribute of the IP. As long as the block still belongs to the same cloud provider and is used the same way, it does not change. After a block changes hands or is repurposed as an enterprise leased line, the databases update gradually, with a delay. The five dimensions for telling datacenter and residential IPs apart are covered in Datacenter IP vs residential IP: what is the difference.

#Where do proxy / VPN flags come from?

Proxy flags come from databases such as ip-api, proxycheck and IP2Location. They generally infer the flag by combining block ownership, active scanning (for example, whether a proxy protocol is running on a port) and historical observation. It is not the verdict of a human reviewer.

In cdnping these databases are combined into a "proxy group" capped at 45. proxycheck also provides its own 0–100 risk score, which counts only when it reaches 33, up to 20. When several databases flag the same IP the points add up, but the proxy group never exceeds 45 in total.

This factor sits between "intrinsic" and "changing":

• If a block is widely used as VPN egress, the flag stays for a long time;
• If an IP was used as a proxy briefly and then stopped, the flag lingers for a while, for as long as each database's update cycle dictates;
• Addresses shared by many people, such as enterprise egress, campus networks and carrier CGNAT, can also be flagged by mistake.

When judging, look at how many databases flag it. If only one does, stale data or a false positive is more likely; if several flag it at once, it is more credible.

#Why does a Tor exit carry the highest weight?

The list of Tor exit nodes is published by the Tor Project, so the basis for the judgment is explicit and involves no guesswork. cdnping merges the Tor Project list, dan.me.uk, proxycheck's TOR type and StopForumSpam's torexit flag. A hit on any one scores 60, and once it hits, the proxy group is not scored again.

This is a record that changes. After a machine stops serving as a Tor exit, each list removes it at a different time, so a few sources may still match it for a short while.

#DNS blocklists and abuse reports: the IP's "history"

These two groups record what the address has been observed doing.

DNS blocklists (DNSBLs) are mostly designed for mail servers and list sources of spam, compromised hosts, open proxies and so on. cdnping queries DroneBL, SpamCop, Mailspike, Barracuda, UCEPROTECT and s5h. Each hit scores 8, up to 24, and only IPv4 is queried.

StopForumSpam collects IPs behind spam registrations and spam posts submitted by forums and websites. cdnping scores by the number of records, adds points if one appeared in the last 90 days, and caps the group at 25.

These two groups change the most, and a few points are worth noting:

1. Records follow the IP, not the person. An address you get after a dynamic residential line redials may carry records left by the previous user.
2. Shared egress implicates everyone. When hundreds of people share one egress, one person sending spam affects all of them.
3. Removal rules differ. Some lists expire entries automatically; others require a request on their website. If it is a server you are responsible for, first find and fix the cause (outbound mail or a compromise), then follow the list's own process.
4. Check the time of the most recent record. A report from several years ago has limited reference value.

#Geolocation consistency: registered location vs actual location

cdnping uses 11 geolocation databases to vote on the location, then compares the result with RDAP registration data:

• If the registration says country A but most databases say country B, it is judged a broadcast IP and scores 10; the principle is explained in Native IP vs broadcast IP.
• If enough databases take part in the vote but support for the winning country is low, it scores 5. Newly allocated or frequently transferred blocks often show this.

These two items carry low weight mainly because large cloud providers and enterprises often use a block registered in one region somewhere else, and the registration data itself may be out of date.

There is another kind of "consistency" that does not count toward the risk score but still shapes how others judge you: the browser time zone or language not matching the IP's location, or DNS or WebRTC exposing a different egress. See Browser fingerprint and environment checks.

#How do I verify each factor myself?

First open IP and environment check, wait for all items to finish, and note which groups were hit. Then verify each item in a terminal. In the commands below, replace 203.0.113.7 with the IP you want to check (this is a reserved documentation example address):

IP=203.0.113.7

# 0. Confirm which egress the terminal actually uses (browser and terminal may differ)
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc)='

# 1. ASN and organization name (Team Cymru public WHOIS)
whois -h whois.cymru.com " -v $IP"

# 2. RDAP block registration data; look at name, country, remarks
curl -sL "https://rdap.org/ip/$IP" | head -c 2000

# 3. Reverse DNS; PTR often carries cloud provider or broadband naming
dig +short -x $IP

# 4. Is it on the Tor exit list?
curl -s https://check.torproject.org/torbulkexitlist | grep -x "$IP" && echo "Tor exit"

# 5. Query one DNS blocklist (reverse the four IPv4 octets + list domain)
REV=$(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}')
dig +short $REV.bl.spamcop.net   # 127.0.0.2 means listed; no output means not listed

Reading the results:

If you want to check egress IP, DNS, WebRTC and API latency together, you can go through them in the order of the Developer network self-check list (2026).

#What a risk score can and cannot tell you

A risk score describes how public reputation sources see this IP. It tells you what kind of network the address belongs to, which lists it has appeared on, and whether its location is consistent. It cannot predict how a specific platform will treat your requests; each platform has its own rules, which are also not public.

The most common reasons for a high score are datacenter egress and shared egress, not necessarily that the IP did anything bad. A low score does not mean you can ignore terms of service. When using AI services, follow the supported regions and terms the provider publishes, and comply with local laws and regulations.