Frequently Asked Questions (FAQ)

CleanIP organizes IP types based on ownership consistency, network purpose, and anonymity risk. Common types are as follows:

Colors only indicate a risk tendency, not an absolute conclusion. The final judgment still depends on abuse history, ASN reputation, and the specific business scenario.

A common approach is to check the ASN owner type. However, this only shows that the IP is owned by an ISP — it doesn't mean the IP is actually used for home broadband. For example, in China most traditional IDC server IPs are registered under the three major carriers (China Telecom, China Unicom, China Mobile), since they are ISPs, but these IPs are actually used in datacenter servers.

CleanIP combines ASN type, organization name, reverse DNS, open ports, service banners, proxy/VPN signals, and historical behavior to make this call. This helps distinguish two easily confused cases: datacenter server IPs registered under a carrier, and residential proxy egress points disguised as home broadband.

Native IP refers to an IP address whose block is registered in the same country as its physical location, and whose announcing network (ASN) is registered in that country too. Most home broadband IPs are native IPs, and some local IDC providers use native IPs as well. A block leased from a local ISP but announced by a company registered abroad is a cross-region announcement and is treated as a broadcast IP.

Some global, multinational IDC providers (such as AWS, GCP, and Azure) purchase large IP blocks for ease of management and broadcast them across multiple countries. This type of IP is called a broadcast IP.

When an IP is marked as native, it typically indicates the IP belongs to home broadband or a local IDC provider. When an IP shows as broadcast, it typically indicates the IP is neither home broadband nor from a local IDC provider.

CleanIP determines whether an IP is native based on its registration location. If the registered country matches the geolocated address country, it's shown as "Native IP"; otherwise, it's shown as "Broadcast IP". The "Registration History" table below can be used to view the IP's registration location and its historical records.

Three typical reasons, ordered by frequency:

1. Broadcast IP: The IP's registered country differs from its geolocated address country. Common with multinational IDCs, cloud providers, carriers' overseas nodes, or datacenter broadcasting. CleanIP marks this with a Broadcast IP yellow badge.
2. Public infrastructure: Public DNS, CDNs, or global cloud platform nodes may use the same address blocks across multiple regions, so geo databases may report different countries or cities depending on probe location and routing perspective.
3. Geo database lag: After an IP block changes ownership, different geo providers update at different speeds (commercial geo databases typically update weekly, while some free sources update monthly or slower). This tends to converge over time; stale data from a minority of sources needs cross-validation to identify.

CleanIP compares geolocation, ASN, and network ownership data from multiple sources side by side. Higher consistency means higher confidence; when there's a clear discrepancy, CleanIP prioritizes flagging likely causes such as broadcast IPs, public infrastructure, or database lag.

CleanIP provides two independent scores that point in opposite directions — don't confuse them:

For most IPs the two scores are negatively correlated (a high purity score usually means a lower risk score), but they aren't exact complements. They're computed differently: purity is a composite quality score, while the risk score leans more toward threat and blocking decisions.

The Purity Score (0–100, higher means cleaner) is a weighted combination of 6 dimensions:

• Identity trust (20%): ASN ownership consistency with the IP's registered country, RPKI validation, whether it's known public infrastructure
• Anonymity evasion (25%): Proxy / VPN / Tor / residential proxy detection (the more concealed, the larger the deduction)
• Abuse history (20%): AbuseIPDB report count and report age, cross-validated across multiple data sources
• Blacklist coverage (15%): 21 DNSBL sources, honeypot databases (HTTPBL), and known-compromised IP lists
• Attack behavior (10%): Network-wide attack counts, reflecting active scanning or brute-force records
• Local reputation (10%): CleanIP's own reputation assessment and threat events over the past 30 days

Grade mapping:

The score isn't the result of a single field — it's a composite judgment formed by six dimensions working together: identity, anonymity, abuse, blacklist, attacks, and local reputation.

The Risk Score is a separate score independent of purity (0–100, higher means more dangerous, the opposite direction from purity). It's specifically used for business risk-control decisions on whether to block or blacklist an IP:

Risk-control data comes from honeypot monitoring, abuse reports, DNSBL blacklists, behavioral analysis, and other multidimensional sources. An IP's risk value decays over time as risk-control records age.

Note: The large number on the homepage is the Purity Score, not the Risk Score. Higher purity is better; a higher risk score is more dangerous.

The risk score isn't directly tied to whether an IP is home broadband. If a home broadband IP has previously been used for scanning, brute-forcing, crawling, or outbound attacks, its risk score can be high. Conversely, even a datacenter IP can have a low risk score if there's no record of malicious behavior.

Common reasons for a high score on home broadband:

• • Historical contamination — A previous user ran proxy, crawler, or attack traffic on this IP, and data sources retained the record
• • Whole-prefix flagging — A malicious IP exists elsewhere in the same /24 block, and data sources flagged the entire block
• • Device compromise — An IoT device at home was compromised and joined a botnet
• • Residential proxy client — Residential proxy software such as ProxyScrape or 911 is running on the network

CleanIP's IP-block-level classification has relatively high accuracy. However, IP address usage isn't static — a large number of IPs change hands every day. Overall data accuracy is roughly around 95%.

To check whether an IP has recently changed hands, look at the "first seen" timestamp in the ASN data. If the data for this IP is recent, that may indicate its ownership or status has changed.

The Platform Safety Rating estimates the probability that this IP will trigger verification, restrictions, or blocking across different business scenarios. It factors in IP type, anonymity risk, geographic consistency, abuse history, and platform tolerance. Ratings fall into three levels:

• Safe: Generally suitable for long-term use, with a low probability of triggering extra verification
• Risk: May occasionally trigger verification or restrictions
• Block: High probability of being restricted or banned

The Platform Safety Rating isn't a guarantee. Account history, device fingerprint, payment method, region, and access behavior all influence the final risk-control outcome.

Platforms vary in how strict their risk control is:

• Lenient (YouTube, X/Twitter, Facebook, e-commerce, gaming): mainly watches for Tor, public proxies, and severe abuse
• Strict (Netflix, Disney+, TikTok): actively blocks datacenter IPs and VPNs
• Payment-grade: more sensitive to anonymity services, datacenter IPs, geographic mismatches, and unusual devices
• AI platforms: fairly sensitive to proxies and datacenter IPs

Browser fingerprinting collects a series of browser and device attributes (such as browser version, operating system, screen resolution, installed fonts, timezone, and Canvas/WebGL output) and combines them into a nearly unique identifier, used to recognize or track the same device without needing cookies.

Common fingerprint signals include: User-Agent, screen resolution/color depth, timezone/language settings, Canvas/WebGL rendering output, font measurement differences, audio fingerprinting, hardware concurrency, and more. Even if you clear cookies or use a private window, fingerprinting can still recognize you.

A WebRTC leak happens when the browser's WebRTC connection process (ICE candidate exchange) unintentionally exposes your local or real public IP address — meaning that even while using a VPN or proxy, a target website may still see your real IP.

• Chrome: Install the "WebRTC Network Limiter" extension (from Google) or "WebRTC Leak Prevent"
• FirefoxOn the about:config page, set media.peerconnection.enabled to false

JA3 fingerprint is a hash fingerprint generated by analyzing the fields of the Client Hello message sent by the client during the TLS handshake (SSL version, cipher suites, extensions, elliptic curves, etc.), uniquely identifying the client implementation. Different browsers and applications use different TLS parameter combinations when establishing HTTPS connections, and these differences form a kind of "network-layer fingerprint."

JA4 is an improved version of JA3 that addresses JA3's sensitivity to ordering changes, allowing better differentiation of slightly modified implementations.

"Dual ISP" only means the IP's owner is an ISP — it doesn't mean the IP is actually used for home broadband. For example, the IP 110.242.68.66 returned by ping baidu.com belongs to China Unicom with an ASN type of ISP, but it's actually one of Baidu's server IPs.

CleanIP's server detection engine uses reverse DNS, port scanning, banner analysis, and other techniques to identify actual server IPs within ISP networks, providing more accurate classification.

CleanIP combines commercial IP intelligence feeds, public network data, routing databases, DNS blacklists, and its own behavioral data. Different sources cover different dimensions:

• Geolocation and ASN ownership
• Proxy, VPN, Tor, and residential proxy detection
• Abuse reports and blacklist records
• ASN traffic and network profiling
• BGP routing and registration history
• Open ports and service fingerprints
• In-house honeypots and behavior monitoring
• Manually curated brand and public infrastructure database

When data sources disagree, CleanIP prioritizes showing an explainable conclusion and keeps a user feedback channel open to correct anomalous samples.

"Shared users" is an estimate of the number of distinct users associated with an IP address, based on network-wide big-data monitoring and analysis. An IP shared by many users usually indicates a public proxy or VPN IP.

Given the widespread use of NAT in mainland China, a large number of end users access the internet through the same public IP, which is normal network behavior. Therefore, the system doesn't show the shared-users metric by default for mainland China IP addresses.

Home broadband IP addresses typically stay registered under a fixed ASN and organization, with a low rate of change. When an IP's historical ASN or owning organization changes frequently, it indicates unstable ownership status — commonly referred to as an "unclean" IP.

The ASN history and company history tables let you clearly see all change records for the IP, helping assess its stability.

CleanIP's data collection module identifies IPs belonging to common CDNs (including Cloudflare, Akamai, Tencent Cloud CDN, Alibaba Cloud CDN, and others). If you run a reverse proxy on your server and the proxied domain uses a CDN, your server's IP may be identified as a CDN IP.

CleanIP performs a TCP connection scan against 26 common ports on the target IP. Beyond discovering open ports, it also:

• Banner grabbing: identifies the specific software and version running on open ports
• CPE mapping: maps identified software to standardized CPE identifiers
• Tag inference: infers IP type from port combinations and CPE data (e.g., CDN, database, IoT, etc.)
• CVE vulnerability matching: matches identified software versions against known CVE vulnerability databases

CPE (Common Platform Enumeration) is a standardized software naming scheme; for example, cpe:/a:nginx:nginx:1.24.0 represents Nginx 1.24.0.

CVE (Common Vulnerabilities and Exposures) is the standard identifier for known security vulnerabilities — for example, CVE-2024-6387 is a remote code execution vulnerability in OpenSSH. CleanIP automatically matches scanned software versions against known high-severity CVEs.