VPN and Proxy Detection for Fraud Prevention: A Technical Guide

Fraudsters use VPNs, proxies, and anonymization networks to mask their true location and identity when conducting attacks. For fraud prevention teams, the ability to detect and classify these connections is a foundational capability. This guide covers the technical mechanisms behind VPN and proxy detection, the different proxy types you will encounter, and the practical challenges of maintaining accurate detection at scale.

Why Fraudsters Use VPNs and Proxies

The motivations are straightforward and overlapping. First, fraudsters need to hide their real geographic location. A credential stuffing attack launched from a country known for fraud would be trivially blocked by geo-based rules. By routing traffic through a VPN endpoint in the victim's home country, the attacker appears to be a legitimate local user. Second, they need to bypass geo-restrictions that prevent access to services not available in their region. Third, they use proxies to avoid IP blacklists. Once an IP address is flagged for abuse, the attacker simply rotates to a new exit node. A single attacker can cycle through thousands of IP addresses in a day using a proxy network.

Fourth, and most critically, proxies allow attackers to distribute attacks across many IP addresses, making rate-limiting ineffective. A credential stuffing attack sending one request per IP address per minute from 10,000 residential proxies looks indistinguishable from normal traffic when viewed at the individual IP level. Only by detecting the proxy infrastructure itself can you identify the coordinated attack.

Types of Proxies

Datacenter proxies are the easiest to detect. They originate from IP addresses allocated to cloud providers and hosting companies (AWS, Google Cloud, DigitalOcean, OVH). These IPs belong to ASNs registered to datacenter operators, not ISPs. No legitimate consumer browses the internet from an AWS IP address, so datacenter proxy detection has high precision with minimal false positives.

Residential proxies are the most challenging category. These are real consumer IP addresses, typically from devices infected with malware or from users who have opted into proxy-sharing applications (often bundled with free VPN apps). Because the IP address genuinely belongs to a residential ISP, simple ASN-based detection fails completely. The traffic exits from a real home connection.

Mobile proxies route traffic through mobile carrier networks. Due to carrier-grade NAT (CGNAT), thousands of legitimate users share the same public IP address. This makes mobile proxies extremely difficult to block without collateral damage. Blocking a mobile proxy IP could block thousands of legitimate users on the same carrier.

TOR (The Onion Router) provides multi-layered encryption and routing through volunteer-operated nodes. TOR exit nodes maintain published lists, making detection straightforward. However, TOR bridges (unpublished entry nodes) are designed to be undetectable, and detecting bridge usage requires deeper traffic analysis.

SOCKS5 proxies operate at the transport layer, proxying any TCP connection. Unlike HTTP proxies, they do not add identifying headers. They are commonly used for credential stuffing tools because they support arbitrary protocols and are widely available on underground markets for as little as $0.10 per IP.

Detection Methods

IP database lookups are the first line of defense. Commercial IP intelligence databases (MaxMind, IP2Location, ipinfo.io) maintain catalogs of known VPN, proxy, and TOR IP addresses. These databases are compiled from multiple sources: scanning for open proxy ports, analyzing BGP routing data, identifying datacenter ASN ranges, and incorporating user reports. The limitation is that databases are inherently retrospective. A new proxy endpoint is undetected until it is cataloged, which can take hours to weeks.

DNS leak detection exploits a common VPN misconfiguration. When a user connects through a VPN, their DNS queries should route through the VPN tunnel. However, many VPN clients leak DNS queries to the user's actual ISP DNS resolver. By forcing the browser to perform a DNS lookup for a unique tracking domain, the server can observe which DNS resolver made the query. If the resolver belongs to a different ISP than the one associated with the user's apparent IP address, a VPN is likely in use.

WebRTC leak detection targets another browser-level vulnerability. WebRTC, used for peer-to-peer communication, can expose the user's real local and public IP addresses even when a VPN is active. By creating an RTCPeerConnection and gathering ICE candidates, JavaScript code can extract the user's actual IP address and compare it to the apparent IP. This technique is highly reliable for browser-based detection but requires JavaScript execution.

MTU and TTL analysis examines packet-level characteristics. VPN tunnels add encapsulation headers that reduce the Maximum Transmission Unit (MTU) below the standard 1500 bytes. A packet with an MTU of 1400-1450 bytes strongly suggests VPN tunneling. Similarly, the Time-To-Live (TTL) value in IP headers decrements with each hop. Unusual TTL values, or TTL values inconsistent with the expected hop count for the apparent network path, indicate routing through an intermediary.

Latency and RTT measurement compares the network latency to the apparent geographic location. If a user's IP geolocates to New York but their round-trip time to a New York server is 200ms (consistent with a transatlantic connection), they are likely connecting through a proxy in a different geographic region. This technique provides a probabilistic signal rather than definitive detection.

TOR exit node detection is straightforward because the TOR Project publishes a list of all exit node IP addresses, updated hourly. Checking incoming connections against this list provides near-perfect detection of standard TOR usage. The challenge is detecting TOR bridge users, where the exit appears as a normal IP but the traffic has been routed through the TOR network internally.

Datacenter ASN identification maps the IP address to its Autonomous System Number and checks whether the ASN belongs to a hosting provider rather than an ISP. This technique has extremely high precision for datacenter proxy detection. Major cloud providers (AS14618 for Amazon, AS15169 for Google, AS13335 for Cloudflare) are well-documented, and smaller hosting ASNs can be identified through WHOIS data and RIR registrations.

Residential Proxy Detection: The Hardest Problem

Residential proxies defeat IP-level detection because they use genuine consumer IP addresses. Detection must rely on behavioral and connection-level signals instead. Connection characteristics provide the first set of clues. Residential proxy traffic often exhibits inconsistent TCP parameters: the TCP window size, MSS (Maximum Segment Size), and TLS fingerprint may not match the expected values for the claimed operating system and browser. A connection claiming to be Chrome on Windows but presenting a TLS fingerprint consistent with a Python requests library is suspicious.

Behavioral patterns offer additional signals. Residential proxy users tend to have unusually short session durations (the proxy connection is rented by the minute), no return visits (the IP address rotates with each request), and access patterns inconsistent with organic browsing. A real user has a browsing session with page views, scrolling, and interaction. A proxy user typically makes a single targeted request.

Advanced detection combines these signals into a proxy probability score rather than a binary decision. An IP address with a high port diversity (many different source ports used in a short time window), inconsistent TLS fingerprints across connections, and no associated organic traffic history receives a high proxy probability score even if the IP itself appears residential.

Mobile Proxy Detection: The CGNAT Challenge

Carrier-grade NAT means that a single public IP address is shared by thousands of mobile subscribers. This creates a fundamental tension: blocking a mobile proxy IP blocks all users behind that NAT. Detection strategies must focus on identifying individual proxy connections rather than blocking entire IPs.

Techniques include analyzing the connection fingerprint (proxy connections often have different TCP/TLS characteristics than native mobile browser connections), checking for header anomalies (mobile carriers inject specific headers like X-MSISDN or X-WAP-PROFILE that proxy connections may strip or forge), and using device attestation (a legitimate mobile app can verify the device's network state through platform APIs, while a proxy connection cannot).

Accuracy vs Privacy: Finding the Balance

Aggressive proxy detection risks blocking legitimate users. Corporate VPN users, privacy-conscious individuals using consumer VPN services, and users in countries with internet censorship all have valid reasons for using VPNs. A detection system that blocks all VPN traffic will generate significant false positives and customer complaints.

The solution is contextual policy enforcement. Rather than binary block/allow decisions based on proxy detection, apply graduated responses. A VPN-detected login from a recognized device might receive a standard authentication flow. A VPN-detected login from an unknown device attempting a high-value transaction should trigger step-up verification. TOR usage during account creation warrants elevated scrutiny. The proxy detection signal feeds into a broader risk engine rather than serving as a standalone gatekeeper.

When to Block vs Flag: Graduated Policies

Effective proxy policies operate on a spectrum. Hard blocks should be reserved for TOR exit nodes on financial services (near-zero legitimate use case), known botnet command-and-control IPs, and IPs with confirmed recent abuse history. Step-up authentication is appropriate for datacenter proxies, VPN connections from unrecognized devices, and residential proxies with high probability scores. Logging only is suitable for commercial VPN services (NordVPN, ExpressVPN) when the user has a trusted device and account history.

The policy should also account for the user's historical behavior. A user who has always connected from a VPN (consistent with corporate usage) should not be penalized for their next VPN connection. Anomaly detection should focus on changes in proxy usage rather than proxy usage itself.

How Deep ID Detects VPN/Proxy as a Smart Signal

Deep ID's device intelligence SDK includes VPN and proxy detection as one of its Smart Signals, returned alongside device fingerprinting and other fraud indicators. The detection operates at multiple layers simultaneously: IP-level checks against continuously updated threat intelligence databases, network-level analysis of connection characteristics and latency patterns, and device-level verification of the actual network interface state.

The SDK can detect VPN connections even when the VPN app is configured to exclude the banking app from its tunnel (split tunneling), by comparing the device's reported network state with the observed connection characteristics. The result is returned as a structured signal with a confidence score, allowing the integrating application to apply its own risk policies based on the detection certainty.