IPASKMethodology
How an IP becomes a verdict here: which signals we use, how confidence is assigned, what the risk score means, and the limits we accept. Last reviewed 2026-10-28.
1. Data sources
| Source | Used for | Refresh |
|---|---|---|
| MaxMind GeoLite2-City | country, region, city, coordinates, timezone, accuracy radius | weekly |
| IPtoASN | AS number, operator name, announced range | daily |
| Tor Project exit list | Tor exit detection | several times a day |
| Own ASN statistics | how often a network shows hosting/proxy signals in our own checks | continuous |
We do not buy commercial residential-proxy databases. That is a deliberate choice: those feeds are expensive and unverifiable for us, and a wrong “residential” label is worse than a cautious one.
2. Verdict rules
Rules are evaluated strongest first; the first match wins. Confidence describes how strongly the rule is supported by data — it is not a probability of a ban.
| Verdict | Condition | Confidence |
|---|---|---|
| Tor exit | address is on the Tor exit list | 95% |
| VPN provider | ASN belongs to a known VPN range | 88% |
| Datacenter | ASN is a hosting/cloud provider | 82% |
| CDN edge | ASN is a CDN (shared infrastructure) | 60% |
| Mobile | usage type indicates a mobile carrier | 65% |
| Residential (screen) | ASN looks like a consumer ISP and no signal matched | 70% |
| ISP | ISP range, no stronger signal | 55% |
“Residential (screen)” is a screen, not a certificate. Rented residential proxies route through real devices and are invisible to any database until they act.
3. Risk score
The 0–100 score is a weighted sum of the flags above plus ASN history. It is a heuristic on purpose: every point comes from a rule you can inspect. Two tools can disagree on the same IP without either being broken, because the weights differ.
- Deductions increase with hosting / proxy / VPN / Tor / blacklist signals.
- The score never changes the verdict; it explains how many signals fired.
4. Environment consistency client-side
Five checks run in your browser and never leave it: timezone vs IP timezone, system clock offset, browser language vs IP country, user-agent consistency, and whether WebRTC exposes a private address. The score starts at 100 and subtracts 25 / 15 / 15 / 15 / 20 for each mismatch.
These checks describe your browser, not the IP in isolation. A clean IP with a mismatched browser is still an easy target.
5. What we do not do
- No guarantee. Platforms use device, payment and behaviour signals we never see.
- No black-box model. We publish the rules so you can disagree with them.
- No storage of pasted IP lists beyond what your report or history requires.
- No selling proxies. We are an inspection layer, not a supplier of addresses.
6. Accuracy
We sample addresses by hand and re-check them against RDAP registration, reverse DNS and, when possible, a real connection. The table below is filled from those samples; we publish it even when it is unflattering.
| Check | Sample size | Match | Notes |
|---|---|---|---|
| Cloud ranges → datacenter | 60 | 100% | 60/60 matched the reference set |
| Cloudflare ranges → CDN | 15 | 100% | 15/15 matched the reference set |
| DROP ranges → blacklist hit | 50 | 100% | 50/50 matched the reference set |
| Tor exit list → Tor verdict | 50 | 100% | 50/50 matched the reference set |
| Consumer ISP samples → not flagged as hosting | 20 | 100% | 20/20 matched the reference set |
Last audit: 2026-11-01. Method: Rule-level audit against public ground-truth datasets (cloud ranges, Cloudflare ranges, Spamhaus DROP, Tor exit list) plus a hand-picked consumer ISP sample. This validates the pipeline against reference data, not against platform decisions..
If you find a clear misclassification, send the IP with a note to hi@ipask.net and we will re-check it by hand.