Checking IP Purity on Your Own VPS: Native IPs, Fraud Scores, and How to Test Without Leaving a Trail

Bottom line: IP purity is how clean an address looks across the fraud databases, decided by four things — registration type (ISP vs Hosting), blacklist history, the behavior of its /24 neighbors, and whether it's flagged as a proxy. To test your own VPS safely, skip the browser: SSH into the box and run a CLI. The path can't be misread, and the IP never lands in a checker's logs.

What IP purity actually measures

A fraud engine scoring an IP looks at four things: registration type, reputation history, neighbor quality, and proxy flags.

Registration type comes first — it's the field streaming services check before anything else. IP2Location sorts IP usage into ISP (residential), MOB (mobile), DCH (datacenter/hosting), and COM (commercial); ipinfo uses parallel hosting/isp/business labels. Any box you spin up at a cloud provider is born DCH. That's a factory setting, not something you broke.

Reputation history means blacklists. A DNSBL like Spamhaus records spam, scanning, and abuse reports. IPs get recycled between tenants, so if the previous renter ran a spam campaign from yours, the mark can still be sitting in the database when you take it over.

The third one is the least fair: neighbor guilt. Fraud systems commonly rate reputation by /24 block, so a handful of bad IPs in your segment drags the whole block down. Your own address can be spotless and still inherit the penalty. When I pick a checker I look for a C-block profile feature — scoring one IP in isolation tells you very little.

Last is the proxy flag. Intelligence firms scan the public internet continuously and write confirmed Proxy/VPN/Tor exits into their databases. Hit this one and the first three don't matter — you're getting blocked.

Two VPSes with identical spec sheets can test a full tier apart, and the gap usually traces back to one of these four.

Native vs broadcast IPs: one word apart, worlds apart

The difference between a native IP (ISP) and a broadcast IP (Hosting) is whether the WHOIS registration matches how the address is actually used. A native IP is registered to a local ISP at the location where the server physically sits. A broadcast IP is registered to a segment in another country or another use class, then announced to a local datacenter over BGP— the paperwork and the physical reality don't line up.

The business behind it is address arbitrage. A datacenter holds a block of US-registered ISP space, announces it via BGP onto racks in Tokyo or Singapore, and sells it. WHOIS says a US carrier; the routing and latency say local datacenter. That registration-vs-location mismatch is exactly the pattern fraud systems hunt for.

The practical differences, side by side:

Every row is a tendency, not a verdict. Native blocks get burned too — there's a FAQ on that at the end.

Why your test setup is probably lying to you

Most people trip on one thing: they're not testing the exit they think they are.

Take OpenClash/mihomo. The routing core decides which node each connection uses based on rules (domain, GeoIP, GeoSite). When you open an IP checker in your browser, whichever rule that connection matches picks the exit — it might get sent to a different node, or GeoSite might rule it direct. The result has nothing to do with your target VPS, and judging the node by it means grading a different machine. To test correctly in a browser, write a dedicated rule pinning the checker's domain to the target node; the easier route is to skip the browser and run a CLI on the VPS, where traffic never touches your local routing layer.

Now Cloudflare. Behind the orange cloud, visitors resolve to a CF edge Anycast IP and your origin's real IP is hidden from inbound requests. Watch the direction: that protects you from people seeing where your origin lives. It has nothing to do with the exit IP your VPS uses when it reaches out to other sites. "I'm behind CF so my IP is safe" confuses inbound with outbound.

One more: WebRTC. A browser gathers network candidates over STUN, and those requests slip past the proxy set at the browser layer. Under a system proxy or PAC mode, your address-bar traffic goes through the proxy while the STUN request can still leak the real exit. TUN or global-capture mode pulls all traffic in and shuts that path. Checking a node for WebRTC leaks belongs in the routine.

The privacy cost of ordinary checkers: you test them, they log you

While you read the result, the checker is recording you. Access logs, cookies, browser fingerprinting, WebRTC probes — these are the raw material such sites use to decide "is this visitor a proxy or a bot." Keeping the record is the default, not malice.

That's fine for an ordinary visitor and backwards for someone testing a fresh IP. A clean exit that hasn't entered any fraud database yet — you hand it over, fingerprint, timestamp, request signature and all, into their store. Some checkers also feed data-intelligence firms, so "just a quick test" can be the moment that IP gets logged and tagged. The act of testing manufactures the risk of being flagged.

So when you pick a checker, how it handles your data matters as much as how many signals it reads. ipok.io puts the promise on the page: no storage, no logging, no tracking, no cookies or beacons, WebRTC only runs when you click, and the result stays local. It aggregates 8 fraud sources into a composite score, ships an offline reputation database so part of the verdict never leaves your machine, and gives a C-block profile of your /24 neighbors. For split-routing users the useful part is the Chrome extension and the CLI — the CLI runs straight on the VPS, no browser in the path.

A repeatable testing procedure

One rule: SSH when you can, browser only when you can't.

Test with a CLI on the VPS (cleanest)

SSH into the target box and run the checker CLI locally. Traffic skips your browser, proxy client, and routing rules, so you measure the machine's own exit — and there's no checker quietly collecting your browser fingerprint. A tool with an offline reputation database keeps part of the verdict local; the 8-source composite still queries external data, so don't expect zero outbound. No tool can promise that.

Test in a browser (mind the routing path)

If the browser is unavoidable, pin the checker's domain to the target node in your rules first — don't gamble on the default. Then confirm the proxy mode: system proxy and PAC need a WebRTC leak check, TUN global is more trustworthy. Time it too — test when only the target node is carrying traffic, since concurrent nodes muddy the result.

Verify the test path under split routing

Not sure the rule fired? Run a control. Add a temporary DIRECT rule for the checker's domain and note the result; switch back to the target-node rule and test again. Different results mean the rule is doing its job. Identical results mean traffic probably took another path — fix the rule before you trust the check.

FAQ

My IP's fraud score is low, so why can't I watch Netflix?

Because fraud score and streaming detection are separate systems. The first rates scam risk; the second checks whether usage type is Hosting, plus the platform's own proxy database. For IPs it reads as Hosting/VPN, Netflix used to limit you to its originals and now more often just throws an error. A low score only says the IP doesn't look like fraud — it says nothing about residential status.

Is a native IP always better than a broadcast IP?

Better on the odds, not a law. A native IP's registration matches its use, so unlock and risk tend to go better; but if its segment has heavy abuse or a Spamhaus listing, it burns anyway, and a clean broadcast block can be steadier. Judge on measured data — usage type, blacklist records, C-block profile — not on the IP's pedigree.

Behind Cloudflare or running OpenClash, whose IP am I even testing?

Two cases. Cloudflare's orange cloud hides the inbound origin IP, which has nothing to do with the exit IP you use as a client reaching out. Under OpenClash, the IP you measure depends on which routing rule the checker's domain matched — no way to know without seeing the config. The reliable move is to SSH into the VPS and test with a CLI: no browser, no routing layer, no ambiguity.