The core idea: geolocation vs. detection are two different questions
The single most common confusion here is treating "where is this IP?" and "is this IP a VPN?" as the same lookup. They are not.
When you connect through a VPN, the website you visit only ever sees the exit server's IP. Geolocating that IP truthfully returns the exit server's location — that is geolocation working correctly, not failing. The interesting question, "is this a VPN?", is answered by a completely different set of signals layered on top of the raw location lookup.
The detection signals, and how each one works
There is no single "VPN flag." Providers combine the signals below, weighting them and requiring several to agree before they block. Here is what each signal is and how reliable it is in practice.
| Detection signal | How it works | Reliability |
|---|---|---|
| Datacenter / hosting ASN | Every IP belongs to an Autonomous System (a network) with a known owner. Home users originate from consumer-ISP ASNs; VPN exits almost always sit in datacenter or cloud-hosting ASNs (AWS, OVH, DigitalOcean, dedicated VPN ranges). An IP owned by a hosting company is the single strongest tell. | High for ordinary VPNs; useless against residential proxies |
| Commercial IP-intelligence lists | Services like IPQualityScore, MaxMind, IP2Location, and Spur maintain continuously updated databases of known VPN/proxy IPs, harvested by buying the services and recording their exit addresses. A hit is near-certain. | High, but only as fresh as the feed; new IPs lag |
| Public blocklists (Tor, open proxies) | The Tor Project publishes an authoritative list of all exit nodes; open-proxy scanners publish theirs. Matching against these gives near-perfect detection for those categories. | Very high for Tor and known open proxies |
| WebRTC / DNS leaks | Not a server-side IP check — a client-side leak. WebRTC can expose the device's real IP via browser JavaScript, and DNS queries escaping the tunnel reveal the true resolver. Catches the real user, not just the VPN. | High when the leak exists; a well-configured VPN blocks it |
| Latency / timezone / locale mismatch | Compares the claimed IP location against physics and browser hints: round-trip latency inconsistent with the distance, a device timezone or Accept-Language that contradicts the IP's country, or "impossible travel" between logins. | Medium — a strong corroborating signal, weak alone |
| Open ports & protocol fingerprint | Scanning the IP for VPN service ports (OpenVPN 1194, WireGuard 51820) or fingerprinting the TLS/protocol handshake. Increasingly evaded by running on 443 with obfuscation. | Low–medium and declining as obfuscation spreads |
| Behavioral / shared-IP analysis | Many unrelated accounts hitting one IP, persistent high-bandwidth sessions, or abnormal request volume. This is the fallback that catches residential proxies with no datacenter fingerprint. | Medium; the main lever against residential proxies |
The practical upshot: the top three rows catch the vast majority of consumer VPNs cheaply, and the bottom rows exist to catch what those miss. A basic site checking only ASN will block NordVPN's datacenter ranges but wave through a residential proxy; a streaming service running an aggressive commercial feed plus behavioral analysis catches far more.
Why the same VPN is blocked on one site and works on another
Detection is not a property of the VPN — it is a property of the checker. Three variables decide the outcome:
- IP reputation. A popular VPN server whose IP thousands of users have hammered is on every blocklist; a fresh, unlisted IP in an obscure hosting provider passes until it is discovered. Providers fight this by constantly rotating and buying new ranges.
- How aggressive the checker is. A small site doing one ASN lookup is easy to pass. A streaming service or bank paying for a frequently updated commercial feed and layering behavioral analysis is not.
- Cost tolerance for false positives. Blocking every datacenter IP also blocks legitimate corporate VPNs and cloud-based tools, so many sites deliberately tune detection loose to avoid angering real customers — which lets some VPNs through by design.
This is why VPN detection is a moving target rather than a solved problem. It is the same cat-and-mouse dynamic as spam filtering: each side adapts to the other continuously.
Where your real location can still leak
Even when the IP layer behaves — geolocation shows the exit, detection may or may not flag it — your true location can escape through channels that bypass the tunnel entirely:
- WebRTC leaks. The browser's real-time communication API can hand a web page your actual local and public IP via JavaScript, sidestepping the VPN. This is the most common real-IP leak. Block WebRTC or confirm your VPN forces it through the tunnel.
- DNS leaks. If DNS queries go to your ISP's resolver instead of through the VPN, the resolver's location (and your query history) is exposed.
- Timezone and locale. A US exit IP paired with a browser set to
Europe/Moscowand Russian language headers is a giveaway that corroborates other signals. - Account and cookie history. None of this matters if you log into an account that already ties the session to your identity.
A correctly configured modern VPN with leak protection closes the first two. The last two are on you.
The hardest case: residential proxies
Residential proxies are the reason "just block datacenter IPs" is not a complete answer. They route traffic through IP addresses assigned by consumer ISPs to real homes — sourced from SDK-bundled apps, browser extensions, or compromised devices. Because the exit IP carries a legitimate residential ASN and a plausible geolocation, the datacenter and blocklist signals that catch ordinary VPNs simply do not fire.
Detecting them means falling back to behavior: a single "household" IP suddenly serving thousands of requests, many unrelated accounts sharing it, impossible travel between logins, or automation-shaped request timing. This is slower, more expensive, and more error-prone than an ASN lookup — which is exactly why residential proxies command a premium in the fraud and scraping markets.
Tor is the easy case
Tor sits at the opposite end. Because the Tor Project publishes a complete, authoritative list of every exit node, any service can download it and block or challenge those connections with near-perfect accuracy — no commercial feed required. Geolocation still just shows the exit relay's location, but the public exit list makes Tor detection far more reliable than VPN detection. If you want to do this yourself, see How to Check if an IP Is a Tor Exit Node.
What this means if you are building detection
If you are implementing IP-based security or access policies, treat VPN/proxy status as a signal, not a verdict:
- Start with ASN classification and a reputable commercial feed — that combination is cheap and catches most consumer VPNs.
- Add behavioral analysis only where residential proxies are a real threat (fraud, credential stuffing, ticket scalping); it is where the cost lives.
- Expect false positives. Corporate VPNs, cloud-hosted tools, and shared CGNAT IPs all look suspicious. Use VPN status to raise friction (a second verification step) rather than to hard-block, unless the stakes justify it.
- Keep your feeds fresh. Detection accuracy decays daily as IPs rotate. A stale database is worse than useless because it produces confident wrong answers.
- Respect the privacy dimension. VPN use is legitimate — privacy protection, accessing a home network, evading censorship. Regulations like GDPR constrain profiling on it, and blanket blocking punishes ordinary users. Detection is a tool, and how you act on it is a policy choice with legal weight.
The bottom line
IP geolocation does not detect VPNs — it faithfully reports the location of whatever IP it is handed, which for a VPN user is the exit server. VPN and proxy detection is a separate layer built from ASN classification, commercial IP-intelligence lists, public blocklists, leak channels, and behavioral analysis. That layer is strong against ordinary commercial VPNs, near-perfect against Tor, and genuinely weak against residential proxies and freshly rotated infrastructure. No consumer VPN is 100% undetectable, but none is 100% detectable either — the honest answer is a probability, not a yes or no, and the number depends far more on who is checking than on which VPN you use.