Reduce VPN Detection False Positives: A Practical Guide
VPN detection false positives happen when an IP address is flagged as a VPN, proxy or anonymizer even though the person behind it is an ordinary user, and the most common causes are shared addresses, cloud-hosted egress points and stale list data. Reducing them is mostly a matter of understanding what a flag actually means and deciding what your application does with it.
Why legitimate traffic gets flagged
VPN detection is inference, not observation. A service sees only a source address, and it has to guess from that address what kind of network it belongs to. Two broad techniques are in play: matching the address against published lists of known VPN and Tor exit nodes, and looking at who operates the network the address sits in. Both can be wrong in predictable ways.
The first source of error is address sharing. Carrier-grade NAT lets an ISP place thousands of subscribers behind a small pool of public addresses, and many companies, universities and hotels do the same with ordinary NAT. From the outside, one address produces a large volume of unrelated sessions from many people, which is exactly what a commercial VPN exit looks like when you only have request logs. Behavioural heuristics that trigger on volume or on many distinct accounts per address will therefore misfire on perfectly normal networks.
The second source is hosting. Corporate users frequently reach the internet through a secure web gateway, a cloud proxy or a zero-trust service whose egress addresses live inside a datacenter network. Remote workers on a company VPN, which is a legitimate and common arrangement, appear to come from that datacenter. A rule that treats every datacenter address as suspicious will catch these people along with the abusers. The third source is time: a VPN provider drops an address, another tenant inherits it, and a list that has not been refreshed keeps reporting the old status.
Read the network, not just the flag
A boolean is the least informative part of a lookup. The IP lookup on ipto returns is_vpn, is_tor, is_abuser, is_datacenter and the bogon and bogon_type fields, alongside the ASN and organization that operate the address. Those fields are meant to be read together. An address with is_datacenter true and is_vpn false belongs to a hosting network but did not match a known VPN source; that is a different situation from a match on a published exit list, and your policy can treat them differently.
The VPN, Tor and proxy checker shows the same evidence for a single address, including the network and which source produced the match, which is useful when you are investigating a specific complaint from a user who says they were blocked unfairly. For the ownership side, an ASN lookup tells you whether the operator is a residential ISP, a mobile carrier, a university or a cloud provider. If your flagged address resolves to a consumer ISP, a VPN verdict deserves more scepticism than the same verdict on a hosting provider.
For the background on how list and ASN signals are combined, the post on how VPN detection works goes through the mechanics.
Design policies that tolerate mistakes
The biggest reduction in false positives usually comes from changing what a positive result triggers, not from tuning the detector. Using a VPN is legal and ordinary; many people use one on public Wi-Fi or for work. Hard-blocking on a VPN flag alone will always punish some legitimate users, so reserve blocking for situations where the risk is concrete, such as a payment from a new account, and use softer responses elsewhere.
- Step up instead of block. Ask for an extra verification step, add a CAPTCHA, or delay a high-value action rather than refusing the request outright.
- Combine independent signals. A VPN flag plus a disposable email domain plus a mismatched phone region means more than any one of them. The fraud score checker combines IP, email, phone and User-Agent signals into a single 0-100 score for this purpose.
- Allow-list what you know. If your own office, a partner or a customer's known gateway is flagged, record the range and exempt it. Review the list periodically, because addresses are reassigned.
- Log the reason. Store which field triggered the decision so support can explain it and you can measure how often a flag was overturned.
- Re-check on a schedule. Threat feeds on ipto refresh every 6 hours and IP and ASN datasets refresh daily, so a cached verdict older than that may already be out of date.
Know the limits of any detector
No list is complete, so a negative result means "not known", never "definitely not a VPN". ipto does not detect residential proxies, which route traffic through ordinary home connections and are by design hard to separate from real users. Measuring your own false-positive rate is therefore important: sample flagged sessions, check how many turned out to be legitimate customers, and adjust the action you attach to each signal. The threat feeds page shows the VPN, Tor and high-risk lists themselves, which helps when you want to confirm whether an address is really on a published list or was flagged for another reason.
You can try all of this without signing up: the free tier allows 1,000 requests per day, and the API documentation lists the lookup endpoint and the response fields.