VPN, Proxy, and Tor Detection: Methods and Limits

How detection actually works

No system can cryptographically prove that traffic passed through a VPN. Detection is inference from circumstantial evidence, and every method has a blind spot. The main techniques, roughly in order of reliability: known exit lists (Tor publishes its relay directory; commercial VPN ranges are enumerated by scanning and community effort), ASN and ownership context (an address announced by M247 or a bulletproof hosting provider is statistically likely to be an exit), reverse DNS naming (hostnames like "vpn-gateway" or "exit-node" are operator-written confessions), behavioral signals (thousands of disjoint destinations from one address), and port or protocol fingerprints from active probing.

Because every one of these signals is indirect, providers combine them and still disagree. One database flags an address as VPN because it appears on a community exit list; another cleared it last month after the range was sold to a university. Both are "right" relative to their own data. Treat any single boolean "VPN: yes" as a hypothesis with a confidence level, not a measurement.

Why false positives happen

The most common false positive is recycled infrastructure. Cloud providers constantly reassign addresses; a VPS that ran a VPN exit in March may serve a bakery’s website in June, while stale lists still flag it. Enterprise security gateways are the second major source: when an employer routes all staff through Zscaler or a corporate VPN concentrator, the exit address behaves exactly like a proxy—thousands of users, one IP—because it structurally is one.

Mobile and carrier-grade NAT exits trigger a third class of false positives: enormous user counts per address trip the same heuristics designed to catch proxies. Finally, some databases inherit errors from each other by mirroring feeds, so one bad listing can echo across multiple "independent" checkers. If your own clean home IP shows a proxy flag, stale data or CGN sharing is a far more likely explanation than an actual compromise—though running a quick malware scan and checking for unknown devices on your router is still cheap insurance.

Why false negatives happen

False negatives are the structural weakness of the entire detection industry. A private WireGuard server on a rented VPS, used by one person, generates almost none of the signals detectors rely on: it is not on any list, its hostname is generic, and its traffic volume is indistinguishable from any other small server. Residential proxies are harder still—the traffic exits through genuine home connections, so every infrastructure signal says "normal user".

New exits also enjoy a detection lag. A VPN provider that deploys fresh ranges this week will look clean until enumeration catches up, which can take days to months. This is why a "no VPN detected" result is weak evidence of absence: it proves the address is not a known exit, not that it is not an exit. For high-stakes decisions, combine the IP evidence with behavioral and account-level signals, which is exactly what sophisticated platforms do.

Tor is a special case

Tor is uniquely transparent: the network publishes its relay list, so exit-node detection is close to exact for current exits. Two subtleties remain. First, the list reflects the moment it was fetched; a node that left the network hours ago may still appear, and one that joined may not. Second, being a Tor exit says nothing about intent—the same address carries whistleblowers, journalists, abuse, and ordinary privacy-conscious browsing simultaneously. Platforms that block Tor exits are making an access policy, not an accusation.

How to interpret a detection result responsibly

When a report flags VPN or proxy on an address you control, work the checklist before concluding anything: Is the flag sourced and dated? Do independent providers agree? Does the ASN or reverse DNS plausibly match an exit? Has the address changed hands recently? A single stale flag on a dynamic residential address deserves a note, not a network rebuild.

When you need detection for your own service—fraud screening, access control—never hard-block on one signal. Score the combination (known exit + hosting ASN + behavioral anomalies is actionable; one inherited flag is not), offer a verification path for the false positives you will inevitably create, and log the evidence behind each decision so you can explain it later. Blocking a real customer because a database said "proxy" without provenance is a self-inflicted wound that no accuracy claim on a vendor’s website will heal.

• Known exit + hosting ASN + high connection diversity: strong combined signal.
• Single flag, no date, residential dynamic address: weak, likely stale.
• Enterprise or security-vendor exit (Zscaler etc.): proxy flag is expected, not suspicious.
• "No VPN detected" on an unknown private server: weak evidence of absence.

References and source material

These sources are provided so readers can verify the technical background. Inclusion does not imply endorsement of TrustIP.

• Tor Project — relay and exit list specifications
• M4493 Collected IP Intelligence (IETF draft context)
• PeeringDB documentation