Why complete VPN blocking can't be a compliance solution
A blocklist of every VPN IP does not exist and cannot exist. Commercial providers rotate exits hourly, residential proxies look identical to real consumer broadband, and bypass protocols mask VPN traffic as ordinary HTTPS. Treating VPN detection as a boolean and shipping a static blocklist is the most common compliance mistake engineers make. Here is what actually works, and what doesn't.
The blocklist problem
A commercial VPN of any size operates thousands of exit IPs. Mullvad, PIA, IVPN, AirVPN, Surfshark, IPVanish, and AzireVPN each publish their own server lists; aggregators like X4BNet compile tens of thousands of CIDRs covering the rest. The lists go stale within hours of being scraped because new servers come online, old ones rotate out, and providers re-IP their fleet for both performance and censorship-resistance reasons.
A site that ships a quarterly “known VPN” CIDR list and a 403 rule will achieve two things at once: miss most current VPN traffic, and block IPs that providers have already released back to other customers. Both errors are visible to users and both create support load.
Residential proxies defeat ASN classification entirely
Residential proxy networks (Bright Data, Webshare, Oxylabs, IPRoyal, NetNut) sell access to real consumer broadband connections, sourced from SDKs in mobile apps, browser extensions, and compromised devices. The exit IP belongs to a genuine ISP ASN — Comcast, BT, Deutsche Telekom, Reliance Jio — so an ASN-based detector returns “residential” and most commercial classifiers wave the request through.
The recent FBI/Europol takedown of SocksEscort reported 369,000 compromised devices across 163 countries. Every one of those IPs sat on a real consumer ASN and would have passed an ASN-only check. Detection at this layer needs backbone-reputation signals, vendor gateway lists, and behavioural heuristics (RTT mismatch, multi-geo per user-agent) rather than ASN classification alone.
See the longer treatment in residential vs datacenter IPs and the definitional entry in the glossary.
Anti-censorship protocols evolve faster than blocklists
Obfuscation protocols like REALITY, Xray, and AmneziaWG exist precisely to defeat protocol-level detection. They mask VPN handshakes as ordinary TLS traffic to common services, which means a deep-packet-inspection blocklist that flags “VPN protocols” will miss them. The space changes fast — see the REALITY / Xray / AmneziaWG breakdown for current state. A blocklist compiled six months ago is already behind a generation of protocols designed to evade it.
What actually works: graded verdicts and per-action policy
The honest answer is to stop treating “is this a VPN” as a yes/no question. A pragmatic policy uses tiered verdicts and applies different rules per action surface:
| Verdict | Read traffic | Write / payment / signup |
|---|---|---|
| vpn_detected | Allow | Block, step up to strong auth, or require verification |
| vpn_likely | Allow | Step up auth; require 3DS on payment; queue for review |
| suspicious | Allow | Treat as elevated risk; require email verification |
| clean | Allow | Standard flow |
Two principles make this work. First, expose every signal that contributed to the verdict so policy can apply different rules per evidence type (Apple Private Relay and Cloudflare WARP are not commercial VPNs and shouldn't share their policy). Second, measure the false-positive rate openly — IPLogs publishes its at /accuracy so the trade-off is auditable.
A note on compliance framing
Some jurisdictions have proposed or passed rules that effectively require websites to verify a user's physical location even when the user is on a VPN. Whether such rules are technically achievable is a separate question from whether they are enforceable on you, and verifying the current text of any statute against an authoritative source — your counsel, the statute itself, or organisations such as the Electronic Frontier Foundation and Access Now — is the only safe path before acting. The technical reality is that no detection layer guarantees physical location against a determined, well-configured user.
FAQ
Is it possible to block every VPN IP?
No. Commercial providers rotate exits constantly, anti-censorship protocols mask VPN traffic as normal TLS, and residential proxies run from real consumer ISPs that look identical to ordinary home users. Any static blocklist starts going stale within hours of being compiled.
Why don't ASN-based blocks catch residential proxies?
A residential proxy exit is a real consumer device on a real consumer ASN. The IP belongs to Comcast, BT, Deutsche Telekom — the same ASN your legitimate users come from. ASN classification was designed to flag datacenter traffic; it has no signal to separate a real customer from a rented home connection.
If complete blocking fails, what should I do instead?
Treat VPN detection as a graded verdict, not a boolean. Block high-risk write actions (signup, payment, KYC, admin) on confirmed VPN exits, step up authentication on weaker signals, and allow read traffic. Use multi-source provenance so policy can apply different rules per signal type.
How do compliance rules like age verification interact with VPN use?
Specifics vary by jurisdiction and verifying current text against an authoritative source (your counsel, the relevant statute, or organisations like EFF and Access Now) is required. Technically: no detection layer can guarantee a user's physical location when they use a well-configured VPN or residential proxy. A site that blocks VPNs to satisfy a 'physical location' requirement will both miss bypass traffic and harm legitimate privacy users.
Does multi-signal detection have a measurable false-positive rate?
It should. IPLogs publishes a 0.3% false-positive rate against a Cymru-validated ground-truth corpus at /accuracy. Any IP-intelligence vendor that won't share an error rate against a labelled corpus is asking you to trust a number you cannot audit.
See the accuracy benchmark at /accuracy, the implementation walkthrough at detect-vpn-users, and how IPLogs compares to other IP-intel APIs at /compare/vpn-detection-apis.