VPN blockers detect VPN use by checking whether a connection comes from a known VPN or hosting address, whether browser signals disagree with the apparent location, and whether the traffic looks like a VPN protocol. No method is certain, so expect both misses and false positives.
Why would a site or network block VPNs?
Reasons are practical. A retailer sees account takeover attempts from rotating addresses. A streaming service has regional licensing terms. A bank wants to flag sign-ins from places that do not fit a customer's history. A school or company may require traffic to go through its own filters.
Some of these are risk signals, and some are policy. Blocking everything also catches legitimate users: employees on a corporate VPN, travelers protecting themselves on public wifi, and people who simply value privacy. So many services use a VPN signal as a risk score rather than a hard block.
What signals do blockers use?
Address reputation. Providers maintain lists of IP ranges known to belong to VPN services and hosting companies. A residential customer rarely connects from a data center range, so an address registered to a hosting network is suspicious. The lists lag and miss new addresses.
Network characteristics. Reverse DNS names, the autonomous system that owns the address, and the number of different accounts seen from one address all feed in. A single address serving thousands of users is likely a shared exit point.
Protocol fingerprints. A network operator inspecting traffic can sometimes recognize VPN handshakes by their packet patterns or default ports. Wrapping the traffic differently changes that, so this is a cat and mouse effort.
Browser signals. A page can compare the time zone and language reported by the browser with the location of the address. It can also use WebRTC, whose connectivity establishment procedure in RFC 8445 gathers candidate addresses, sometimes revealing an address different from the one the site sees. Browsers have added protections that limit this.
Behavior. Impossible travel between sign-ins and bursts of requests from addresses with poor reputation are signs too.
How reliable is this?
Not very, for a determined user. New VPN addresses appear faster than lists update, and private or self-hosted endpoints look like ordinary servers. At the same time, false positives are real. Large organizations route many staff through a few shared addresses, and mobile carriers share addresses among many customers.
A constructed example. A software company blocks all traffic from known VPN ranges on its trial sign-up page, and fake sign-ups drop. But two enterprise prospects complain they cannot reach the trial, because their employees' traffic exits through a corporate VPN. The company changes the rule from block to step-up verification, such as email confirmation, and allows listed corporate ranges.
How should you design around it?
Decide what you are protecting. If the concern is fraud, a risk score with step-up checks serves better than a block. If the concern is licensing or legal restrictions, check what you are required to do, since obligations vary by jurisdiction. If you run a corporate network, publish an approved VPN and allow its ranges so your own staff are not caught.
Be careful with data. Detection uses personal information such as addresses and device signals, so apply your privacy rules to it.
How to check or apply this
- State the goal in a sentence: fraud, licensing, policy, or something else.
- Decide whether a VPN signal should block, challenge or just add to a risk score.
- Pick a source of address intelligence, and plan how often it updates.
- Allowlist your own corporate and partner ranges.
- Measure false positives: count blocked users who later pass verification.
- Provide a support path for blocked legitimate users.
Quick check
Can a website tell for certain that I use a VPN?
No. It can infer from signals such as address reputation and browser data, but results are probabilistic.
Is blocking VPNs a good security control?
On its own, rarely. It is more useful as one signal among several, paired with verification steps.
Sources
- RFC 8445, Interactive Connectivity Establishment (ICE)
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs
- NIST SP 800-113, Guide to SSL VPNs
Last reviewed: 18 October 2026.
