VPN Detection Limits: What a Network Flag Can Tell You
A VPN, Tor, or datacenter flag from Watch-IP is a match against a maintained list, not a live behavioral analysis — it tells you the connection's IP matched a known network in that category as of the list's last refresh. False means no match in the currently loaded list, not a verified-clean connection, and coverage differs meaningfully between IPv4 and IPv6.
How list-based detection works
Watch-IP checks a connecting IPv4 or IPv6 address against separately maintained lists for Tor exit nodes, commercial VPN providers, datacenter/hosting networks, known-threat ranges or ASNs, and state-sanctioned network operators. A match sets the corresponding field (isTor, isVpn, isDatacenter, isThreat, isSanctionedNetwork) true. This only works for networks that appear on a list Watch-IP has loaded — it cannot detect a VPN or proxy service that isn't on any list, however well it works technically.
False, omitted, and true mean different things
An omitted security object means your plan doesn't include this data at all — not that the connection was checked and found clean. A false value on an included field means no match in the currently loaded lists, which is a weaker claim than “safe”: list coverage is inherently incomplete, and a brand-new or small VPN provider may not be listed yet. Never render an unevaluated or false result as “Clean,” “Safe,” or “Verified” — those words claim more certainty than a list match can support.
IPv6 has a real coverage gap
IPv4 connections are checked against all five categories. IPv6 connections are checked against everything except Tor — there is currently no free IPv6 Tor exit-list source, so isTor is always false for an IPv6 connection whether or not it's actually a Tor exit. If your review logic branches on isTor, an IPv6 visitor gets a structurally different (weaker) check than an IPv4 visitor, not just a different result.
What these lists don't cover
Residential proxy services — which route traffic through real consumer IP addresses rather than a datacenter — are a materially harder detection problem than commercial VPN or Tor, and current lists don't cover them. The arbitrary-IP lookup endpoints (GET/POST /v1/lookup) don't return this block at all; it's a GET /v1/geo capability tied to the connecting browser, not something you can request for a stored or supplied IP.
A cautious review policy
Treat isVpn or isDatacenter as one input to a manual-review queue alongside account history and other signals — not a sole basis for an automatic block. Legitimate users route through VPNs and shared networks for ordinary reasons (privacy preference, corporate network, travel), so a policy that blocks outright on a single flag will reject real customers. Pairing a network flag with a second signal on the same event, such as a disposable-email match, is a more defensible basis for routing to review than either signal alone.
What this article does not claim
This describes Watch-IP's own list-based implementation, not a general claim about what VPN detection can achieve industry-wide. Watch-IP does not detect residential proxies, does not verify identity, and its lists are refreshed on a schedule (stored in our own storage) rather than continuously — a slow or failed refresh degrades to stale or empty data, which reads the same as “no match.”
Sources
Written by Watch-IP editorial, 2026-09-06. Reviewed against apps/api/src/lib/threat-store.ts and apps/api/src/lib/threat-sources.ts.