How VPN Detection Actually Works
"Just block VPN users" is advice that sounds simple until you try to implement it. VPN detection is a cat-and-mouse game between privacy tools that want to look like regular traffic and detection systems that need to tell the difference. Here's how the detection side actually works - and where each method falls short.
Method 1: IP database matching
The most common approach is the most straightforward: maintain a database of IP addresses known to belong to VPN providers, and check incoming connections against it. When NordVPN, ExpressVPN, or any other provider spins up a server, it gets an IP address from a hosting provider or ISP. Those IP ranges can be identified and catalogued.
This works well for commercial VPN services that operate known server infrastructure. The challenge is keeping the database current. VPN providers actively rotate their IP addresses to avoid detection. A new server might appear on Monday and be decommissioned by Friday, replaced by a different IP in a different data center.
The quality of the database matters enormously. A stale list produces false negatives (missing new VPN IPs) and false positives (flagging IPs that VPN providers have already released back to the general pool). This is why services like AntiProxies update their IP reputation databases monthly - the internet's IP landscape shifts constantly.
Method 2: Datacenter vs. residential classification
Most VPN servers run in datacenters - AWS, Google Cloud, OVH, Hetzner, DigitalOcean, and similar hosting providers. Regular users connect from residential ISPs like Comcast, BT, or Deutsche Telekom.
By classifying IP addresses as datacenter or residential, you can flag connections that originate from hosting infrastructure. A residential broadband customer connecting from a Comcast IP is almost certainly a regular user. A connection from an OVH IP address in Strasbourg is much more likely to be a VPN, proxy, or automated system.
The weakness here is residential proxies. These route traffic through actual residential IP addresses - real home connections provided by users (sometimes knowingly, sometimes through bundled SDK programs). To the datacenter detection method, a residential proxy looks identical to a legitimate user. We cover this challenge in depth in our post on why residential proxies are so hard to detect.
Method 3: DNS leak detection
When a VPN is working properly, all DNS queries should route through the VPN tunnel. But VPN software sometimes fails to capture DNS requests, allowing them to leak to the user's real ISP DNS resolver.
A website can detect this by triggering DNS lookups to unique subdomains it controls. If the DNS query arrives from an IP that doesn't match the user's apparent connection IP, it suggests the user is tunneling their traffic - their browser says they're in Frankfurt, but their DNS resolver is in São Paulo.
Modern VPN clients have gotten better at preventing DNS leaks, so this method catches fewer users over time. But it remains effective against poorly configured VPNs, browser extensions that only proxy HTTP traffic, and split-tunnel configurations.
Method 4: WebRTC IP exposure
WebRTC (Web Real-Time Communication) is a browser API designed for peer-to-peer connections - video calls, file sharing, and similar features. By design, WebRTC needs to discover the user's real IP address to establish direct connections. This can bypass VPN tunnels entirely.
A detection script can use WebRTC's RTCPeerConnection API to request the browser's local and public IP addresses. If the WebRTC IP differs from the HTTP connection IP, the user is likely using a VPN or proxy. This was one of the most reliable detection methods for years, though major browsers have added protections - Firefox can disable WebRTC entirely, and Chrome now limits IP exposure in some modes.
Method 5: Behavioral and timing analysis
VPN connections have measurable characteristics that differ from direct connections. Traffic routed through a VPN server adds latency - the round trip from user → VPN server → destination → VPN server → user is always longer than user → destination. Analyzing TCP connection timing, packet round-trip times, and response patterns can reveal the presence of an intermediary hop.
Similarly, if a user's claimed timezone (from JavaScript) doesn't match the geographic location of their IP address, that's a signal. Someone browsing at 2 PM local time from an IP geolocated to a timezone where it's 3 AM raises a flag.
These signals aren't conclusive individually - someone could be traveling, or their ISP could route traffic through a distant city. But combined with other indicators, they strengthen detection confidence.
Method 6: Port scanning and protocol fingerprinting
VPN servers typically run services on known ports - OpenVPN commonly uses UDP 1194, WireGuard uses UDP 51820, and many commercial VPNs run on TCP 443 to blend with HTTPS traffic. Probing an IP address for these open ports can identify VPN server infrastructure.
Additionally, the TLS fingerprint of a VPN connection may differ from a standard browser connection. Tools like JA3 fingerprinting can identify the TLS client library in use, and VPN clients often have distinctive signatures that don't match any major browser.
Why layered detection matters
No single method catches everything. IP databases miss new servers. Datacenter detection misses residential proxies. DNS leak detection misses well-configured VPNs. WebRTC detection is being patched out of browsers.
Effective VPN detection combines multiple signals into a confidence score rather than relying on a single binary check. A connection from a known datacenter IP, with a timezone mismatch, and an unusual TLS fingerprint is almost certainly a VPN. A residential IP with a minor timing anomaly probably isn't.
This is the approach behind AntiProxies - comprehensive IP intelligence databases covering VPN providers, datacenter ranges, Tor exit nodes, and proxy services, updated monthly to stay current. Instead of depending on one fragile detection method, you get multiple classification signals per IP address, queried locally with zero latency and no data sent to third parties. For a broader comparison of the technologies behind anonymous traffic, see our post on proxy vs VPN vs Tor. To understand how these signals feed into a scoring system, read about IP reputation and fraud prevention or our practical guide to ISP reputation scoring.