VPN detection identifies whether a connection or IP address is routed through a VPN server, proxy, Tor, or relay rather than the user's own network. Fraud, security, and platform teams run it at signup, login, and checkout to decide how much to trust the traffic in front of them.
The pressure behind it keeps growing. A wave of age-verification laws in US states and the UK puts VPN circumvention on the site owner's plate, streaming licenses are enforced by region, and fraud rings rotate through clean-looking addresses by the hour. Knowing which connections are masked has become baseline hygiene for any risk decision.
TL;DR
VPN detection works by combining two signal families: IP intelligence collected ahead of time (enumerated VPN exit nodes, hosting and ASN context, Tor exit lists, published relay ranges) and live connection analysis at request time (timezone and OS mismatches, DNS and WebRTC leaks, TLS fingerprints). Results arrive as flags and confidence scores, not verdicts.
- Datacenter VPNs and Tor are the easiest traffic to identify; residential proxies are the hardest.
- Detection is probabilistic. Read confidence scores and last-seen dates, not just the is_vpn boolean.
- Relays like iCloud Private Relay are not evasive VPNs and deserve their own policy.
- Check high-value actions (signup, login, checkout), then allow, challenge, or block based on the full risk picture.
What is VPN detection?
VPN detection is the process of determining whether the IP address behind a request belongs to an anonymization service instead of a household or mobile network. A positive result tells you one specific thing: the address you see is an exit point, not the user's own connection. It does not tell you who the user is or what they intend.
The address being checked is whatever your stack extracts from the request, which is its own problem behind proxies and CDNs. Our guide to getting the visitor's real IP address covers that step. Once you have a trustworthy address, VPN detection for fraud prevention is the classic use case: scoring signups, logins, payments, and promo redemptions before abuse lands, the workflow we walk through in protecting your business from VPN and proxy fraud.
The teams that run it daily tell you what it is for. Streaming platforms enforce licensing regions, iGaming operators keep sanctioned geographies out, banks flag logins that jump continents, and ticketing sites break resale bots that hide behind rotating exits.
It is also narrower than people assume. Detection cannot reveal a person's true location or identity; that stays inside the tunnel. What it can do is establish that the connection is masked, attribute it to a specific provider, and say how confident that assessment is.
How does VPN detection work?
Every VPN detection technique in production falls into one of two signal families. The first is IP intelligence: things you can know about an address before it ever touches your site. The second is live connection analysis: things you can only observe while the session is happening. Strong systems run both.
1. Signal family 1: IP intelligence built ahead of time
The bluntest method is also the most reliable: subscribe to VPN services, connect to every server region they offer, and record the exit IP each time. Repeat continuously and you get a self-verifying map of VPN infrastructure. We run this continuously against commercial VPN and proxy providers, and we document the pipeline in detail in how we detect risky and hidden IPs.
Network ownership fills the gaps enumeration misses. Consumer traffic almost never originates from datacenter address space, so an IP announced by a hosting provider's autonomous system starts with a strong prior of being infrastructure: a VPN endpoint, a proxy, or a bot runner. If the routing side is unfamiliar territory, our explainer on what an ASN is covers it.
Some anonymization networks simply tell you where they are. The Tor Project publishes its exit relay list as both a bulk file and a DNS lookup service that answers 127.0.0.2 when an address matches a known exit. Several relay operators publish their egress ranges just as openly.
History rounds out the picture. Addresses that hammer honeypots with brute-force attempts or push spam earn attacker and spam flags; and we run our own honeypots to collect that evidence first-hand rather than buying it in. A VPN exit with attack history reads very differently from a clean one.
The weakness of all of it is time. Exit nodes rotate, providers launch new ranges, and yesterday's VPN address gets reassigned to a broadband customer. A detection list that updates monthly is wrong within days, which is why serious databases refresh daily and attach last-seen dates to every classification.
2. Signal family 2: live connection analysis
Lists describe the past. Live analysis catches what no list has seen yet: inspect the connection actually in front of you and compare what it claims against how it behaves.
- Timezone and location mismatch. The browser reports Tokyo while the IP geolocates to Frankfurt. One mismatch is weak evidence; stacked with others, it gets loud.
- OS fingerprint disagreement. The user agent claims Windows while TCP/IP-level characteristics look like a Linux server, a common tell for relayed traffic.
- MTU and packet-size anomalies. Tunnel encapsulation shrinks the usable packet size, so certain MTU values are characteristic of specific VPN protocols.
- DNS and WebRTC leaks. Requests that escape the tunnel can expose the resolver or the underlying address the VPN was supposed to hide, contradicting the visible IP.
- TLS/HTTP fingerprinting. VPN protocols leave identifiable patterns on the wire. In a USENIX Security study of OpenVPN fingerprinting, researchers identified over 85% of OpenVPN flows at a million-user ISP with negligible false positives, and still caught 34 of 41 obfuscated configurations.
Crowding is a signal of its own: when dozens of unrelated accounts surface behind one address in an afternoon, that address is an exit point for something. Live checks are also what catch a server that came online an hour ago or a residential proxy mid-rotation. The trade-off is integration, since request-time analysis has to run inside the session, using a lightweight client-side script backed by server-side network tests.
That integration is a separate step from an IP lookup. Our real-time proxy and VPN detection handles it: a lightweight client-side script starts the check, server-side network tests do the work, and the result comes back as an anonymization flag with separate VPN and proxy scores plus a confidence value for that session. Validated signals from those sessions also feed back into the IP Security database, which is part of why the enumeration side stays current.
3. Why one signal family is never enough
Enumeration and lists are precise but perishable. Live signals are current but individually spoofable: a user can fix a timezone mismatch in system settings, and a well-configured VPN does not leak DNS. Detection becomes dependable when independent signals agree, which is why corroboration, not any single check, is what drives a confidence score up.
The same lens sorts vendor claims quickly: ask which family each signal belongs to, how fresh the list data is, and whether any live analysis exists at all.
What VPN detection catches, and what it misses
Commercial datacenter VPNs are the easy case. Their exit nodes sit in hosting address space, their providers get enumerated, and the two signals confirm each other. Tor is easier still because the network publishes its own exits. If datacenter VPNs were the whole job, every vendor would score perfectly.
Relays deserve their own bucket. iCloud Private Relay routes Safari traffic through two hops, but Apple publishes the relay egress ranges, keeps the assigned IP mapped to the user's coarse city-level region, and explicitly advises site owners to adapt IP-based fraud logic rather than block. Treating relay traffic like fraud mostly punishes iPhone owners on default settings.
Residential proxies are the hard case. That traffic exits through real ISP addresses on real home connections, often an address that was streaming video an hour earlier. Static lists alone are not enough, which is why the Proxy & VPN Detection API pairs enumeration with behavioral profiling and returns a dedicated is_residential_proxy flag with provider attribution. The same data ships offline as the residential proxy detection database.
Then there is the churn window. A VPN server launched this morning is on no list yet, and an address a provider dropped last week may still carry a stale flag: the false-negative and false-positive zones every vendor lives with. If a vendor tells you their VPN detection is 100% accurate, you are reading marketing, not measurement. The honest ceiling is high confidence with visible evidence.
What a VPN detection result looks like
A useful detection result is a set of claims with evidence attached, not a bare yes or no. The Proxy & VPN Detection API returns boolean flags, the provider names behind them, a confidence score per detection, last-seen dates, and a 0 to 100 threat score that aggregates everything. Here is the full response for one flagged address:
{
"ip": "5.180.208.234",
"security": {
"threat_score": 80,
"is_tor": false,
"is_proxy": true,
"proxy_provider_names": [
"NetNut",
"Oxy Labs"
],
"proxy_confidence_score": 99,
"proxy_last_seen": "2026-07-18",
"is_residential_proxy": true,
"is_vpn": true,
"vpn_provider_names": [
"Nord VPN"
],
"vpn_confidence_score": 99,
"vpn_last_seen": "2026-07-17",
"is_relay": false,
"relay_provider_name": "",
"is_anonymous": true,
"is_known_attacker": true,
"is_bot": false,
"is_spam": false,
"is_cloud_provider": true,
"cloud_provider_name": "Packethub S.A."
}
}
Read the fields together. A vpn_confidence_score of 99 with a last-seen date from this quarter is a strong, current classification; a score of 40 with a last-seen from two months back is a hint, not a conviction. The is_anonymous flag rolls VPN, proxy, Tor, and relay into one summary when that is all you need, while is_residential_proxy isolates the hard case so you can give it a policy of its own.
Several flags on one address is normal, not a contradiction. Anonymization infrastructure gets reused heavily, so an address that serves as a VPN exit for one provider can appear in another provider's residential proxy pool while sitting in hosting address space. Read the flags together rather than in isolation.
What to do when you detect a VPN
Treat the result as one input to a decision, not the decision. The threat score bands documented on the API page map cleanly onto actions: under 20 usually means standard controls, 20 to 44 means combine the flag with other context before acting, 45 to 79 justifies friction such as OTP, CAPTCHA, or rate limiting, and 80 and above is block-or-review territory.
Blanket VPN blocking is usually lazy policy. Privacy-conscious consumers, corporate remote workers, and travelers all tunnel legitimately, and relay adoption bakes anonymization into default browsing. Challenge flows keep those people as customers; hard blocks send them to a competitor with better judgment.
Run checks where money and accounts move: signup, login, password reset, checkout, promo redemption. Not every pageview. Pair the IP signal with velocity, device, and behavioral context, and when you shortlist providers, our guide on how to evaluate a VPN and proxy detection API gives you the working checklist.
FAQs
Most VPNs can be detected. Datacenter exit nodes and Tor produce multiple corroborating signals, while residential proxies and brand-new servers are the weak spots. Accuracy also decays with stale data, so confidence scores and last-seen dates matter more than a bare boolean. No honest vendor claims 100%.
Only as long as the classification keeps getting confirmed. Serious databases refresh daily and attach a last-seen date to every flag, so an address a provider dropped last week reads differently from one seen yesterday. The gap to watch is reassignment: an IP released by a VPN provider and handed back to a broadband customer can carry a stale flag for roughly a day. That is why last-seen dates matter as much as the boolean.
Yes, for anything already known about the address. An IP lookup returns VPN, proxy, residential proxy, Tor, and relay flags with provider names, confidence scores, and last-seen dates, which covers enumerated infrastructure. What it cannot do is inspect the session, so timezone mismatches, DNS and WebRTC leaks, and MTU anomalies need request-time analysis running in the browser. Most teams start with the lookup and add live checks on high-value actions.
Yes, but only with live analysis layered on top of lists. A residential proxy exits through a real ISP address, and a new VPN server is on no list yet, so both slip past database checks. Request-time signals such as leaks, fingerprint mismatches, and connection behavior catch much of what enumeration misses.
Usually not. VPN use signals anonymization, not intent, and plenty of legitimate users tunnel by default. A better pattern is risk-based response: allow low scores, add verification or rate limits at moderate scores, and reserve hard blocks for high scores backed by corroborating fraud signals or strict compliance requirements.
Try it on a real address
The fastest way to make this concrete is to score an address you already distrust. Run it through the Proxy & VPN Detection API and read the flags, confidence scores, and last-seen dates against what you just learned. Comparing vendors first? Start with the best VPN and proxy detection APIs.
