How VPN and Proxy Detection Works, and Where It Fails
IP lists, reputation APIs and fingerprints fail differently. Decide what abuse you are stopping, measure false positives, then enforce with a reason code.
When someone asks how to block VPN users, three different requests are hiding in the sentence: stop fraud, stop scraping, or enforce a licensing boundary. Each one tolerates a different error rate, and none of them is answered by knowing whether an address belongs to a tunnel. What a classifier returns is a probability about infrastructure, not a statement about the person using it.
What an IP classifier actually computes
Most services combine four data sources, and they age at different rates. Tor exit lists come from the directory consensus and are close to complete while it lasts. Open-proxy lists are partial and stale within days. Commercial exit lists trail new providers by design, because addresses rotate faster than any vendor can crawl them. Hosting-range heuristics are the cheapest signal and the bluntest.
That last one is where most false positives are born. Corporate egress, cloud-hosted browsers, campus NAT and mobile carrier gateways all look like hosting or shared infrastructure, and every one of them can contain ordinary customers.
| Signal | What it shows | Typical failure |
|---|---|---|
| Tor exit consensus | A known exit relay | Good coverage, obvious to anyone who cares |
| Hosting or datacentre ASN | Infrastructure, not a home line | Flags corporate egress and cloud browsers |
| Commercial exit list | A provider's current ranges | Always behind new providers and rotations |
| Behavioural rate | What the client is doing | Needs tuning, but survives address changes |
IPv6 removes any remaining comfort. A client can hold a different address per connection, and a provider can rotate a prefix between requests, so a rule that treats an address as durable identity will drift away from reality within weeks.
Why protocol fingerprints decay
MSS and timing differences can identify some OpenVPN configurations, and the technique is genuinely fragile. The signal depends on options the user controls, on path MTU, and on middleboxes you do not own. Change one cipher or one MSS clamp and the fingerprint moves. A provider that ships a new default does the same thing to your rule overnight.
Reverse probes have a worse problem than fragility: they are hostile. Scanning a visitor's ports is slow, easily blocked by the same corporate firewall your customers sit behind, and hard to defend in a privacy review. Latency thresholds catch distant users as reliably as tunnel users, which means your rule is really "block people far away" wearing a different label.
Whatever you choose, you have to be able to explain it to a support agent at 2am. A signal nobody can describe becomes a block nobody can reverse. Write the explanation before you write the rule, not after the first complaint.
Identity and behaviour beat anonymity guesses
Rate limits, login requirements, payment checks and per-account quotas address abuse without punishing readers who care about privacy. They also keep working when the address changes, because they attach to something the client cannot rotate for free.
If a geo restriction is a licensing requirement, enforce it as a documented policy with a clear error message and a periodic review. That is a different control from guessing at anonymity, and it should be described differently in the customer-facing text. Blocking the ports a VPN protocol uses may reduce automated abuse, but it also breaks legitimate remote access and is trivially bypassed by anyone determined.
Roll it out as a measurement first
Run the classifier in report-only mode for a couple of weeks. Compare the population it would have blocked against signups, conversions and support tickets, then set the false-positive budget before you set the threshold.
Re-test against a small known set: a home connection, a mobile carrier, a corporate egress and a commercial VPN. Four cases expose most of the errors that would otherwise reach customers, and they cost an afternoon.
Keep the raw signal and the enforcement decision separate. Log the score even when the threshold is high, route the ambiguous middle to a human queue, and tag every block with a reason code so the next policy review can tell which signal earned its place.
The appeal path is part of the control
Every automated block needs a human route: a contact address, a stated response time and a named review owner. Without one, a false positive is a silent lost customer and a support ticket nobody can action.
Say plainly that access may be restricted, why, and how to ask for a review. Version the policy so support can say which rule applied on a given date. A block you cannot explain, reverse or measure is not a control; it is a guess with a log line.