Detecting VPNs and proxies is not enough

November 1, 2025 · 5 min read

Blocking users by IP address used to be a reasonable security measure. If a known bad address hit your login endpoint, you blocked it. If traffic came from a datacenter range, you challenged it. The assumption was that IP addresses carried reliable identity information: where the user was, what kind of network they were on, and whether their connection was legitimate.

That assumption is falling apart. Residential proxies route malicious traffic through real household internet connections, making attackers look identical to genuine users at the IP level. Apple Private Relay mixes legitimate iCloud+ traffic with potential abusers behind shared Akamai and Cloudflare exit IPs, so blocking one bad actor punishes hundreds of real customers. Mobile carriers share addresses across many devices by design. Meanwhile, commercial VPN usage among ordinary users has grown to the point where a VPN connection tells you very little on its own.

IP intelligence is still valuable, but only as one signal among many. The path forward is combining connection data with behavioral context: login patterns, device consistency, account history, and session behavior. That combination requires a security framework, and the framework should run on your infrastructure.

Why IP blocking breaks down

The problem is structural, and it gets worse as each category of connection infrastructure evolves.

Residential proxies are the most serious challenge. They route traffic through IP addresses assigned by consumer ISPs to real households. At the IP level, a residential proxy connection is indistinguishable from a legitimate user. These proxies often originate from developers who monetize their user base by embedding SDKs or offering free VPN apps, turning real users into unwitting relays for fraudulent traffic. Sophisticated attackers rotate residential IPs frequently, making static blocklists unreliable. Blocking a residential IP that happens to be proxying malicious traffic also blocks the real household behind it.

Apple Private Relay demonstrates the problem from the opposite direction. Private Relay routes iCloud+ traffic through shared exit IPs from Akamai and Cloudflare. Dozens or hundreds of legitimate users appear behind the same address. If one of those users is abusive, blocking the IP restricts access for everyone sharing it. The legitimate users have no idea why your product stopped working. From a fraud prevention perspective, Private Relay traffic could be treated as a positive or negative signal depending on your environment, but the decision should never rest on the IP alone.

Mobile carriers share addresses across many devices because of how mobile network addressing works. A mobile IP that appears in your abuse logs may belong to thousands of legitimate users on the same carrier. Blocking it is a blunt instrument that causes collateral damage far exceeding any security benefit.

Datacenter proxies are the one category where IP-level detection still works reliably. Their ranges are well-documented and easy to flag. But precisely because they are easy to detect, sophisticated fraud operations have moved away from them. The traffic that still comes from datacenter IPs tends to be low-sophistication automation, which matters but is not where the hard detection problems are.

Commercial VPNs fall somewhere in between. Major provider IP ranges are known and maintained in databases, but VPN usage among ordinary users is widespread enough that a VPN connection alone carries little signal. A developer protecting their traffic on public wifi, a remote worker on a corporate VPN, and an attacker masking their location all look the same at the IP level.

TOR connections emerge from publicly listed exit nodes, so detection is reliable. But TOR represents a small fraction of overall proxy traffic, and its users include journalists, activists, and privacy-conscious individuals alongside malicious actors.

Connection signals need behavioral context

The value of connection detection increases substantially when combined with account-level behavioral monitoring. Considered alone, a VPN connection is ambiguous. Considered alongside the user's login history, device profile, session behavior, and established patterns, it becomes part of a coherent risk picture.

A first-ever login from a TOR exit node warrants different treatment than the same login from a commercial VPN the user has used before. A proxied connection that precedes an immediate account change (a new email address, a modified payment method) is more concerning than one followed by normal browsing. Multiple distinct accounts logging in from the same VPN exit IP in a short window is a credential stuffing signal. The connection type sets the context. The behavior tells the story.

This is especially important for Apple Private Relay and residential proxy traffic, where the IP itself carries almost no discriminating information. The only way to separate legitimate users from abusive ones sharing the same exit infrastructure is behavioral: login consistency, device stability, account history, session patterns. A framework that combines connection intelligence with these signals can score risk accurately. A blocklist cannot.

How tirreno handles connection intelligence

tirreno is an open-source security framework that processes behavioral events on your own infrastructure. IP intelligence, including datacenter range identification, TOR exit node detection, commercial VPN classification, and abuse list lookups, is resolved through the enrichment API. The enrichment API returns classification results to your instance but does not store your requests. Your users' IP addresses and connection metadata stay on your systems. The intelligence flows inward.

The enrichment pack starts with 2,000 API requests per month free. That is enough to evaluate the quality of your traffic and see what connection infrastructure your users are actually on before committing to anything.

The built-in IP-category rules cover the primary scenarios: TOR exit node connections, commercial VPN providers, datacenter IP ranges, IPs appearing in abuse and spam lists, shared IPs across multiple distinct user accounts, and addresses belonging to relay services and satellite networks. These rules contribute to a score that also reflects login behavior, device consistency, session patterns, and account history.

The auto-blacklisting and manual review thresholds let you define what level of combined risk triggers automatic action versus investigation. This prevents both the over-blocking of legitimate VPN users and the under-blocking of high-risk connections that happen to come from residential proxies rather than known VPN ranges.

Getting started

Install. Deploy a tirreno instance on any server or container you control. The administration guide covers setup and configuration.

Start with the free enrichment tier. The enrichment pack includes 2,000 API requests per month at no cost. Connect it to your tirreno instance and start resolving IP intelligence for your traffic. The developer guide has the integration details.

Send login and session events. Instrument your application to send events to tirreno with username, timestamp, IP, user agent, and event type. For non-logged-in visitors, use the visitor's IP with .* replacing the last octet as the identifier.

Browse the activity page. See what connection infrastructure your users are actually on. Look for datacenter IPs hitting your authentication endpoints, commercial VPN concentrations, and shared IPs across multiple accounts.

Tune the rules. Adjust the IP-category rule weights to fit your product. If your user base includes many legitimate VPN users, lower the VPN weight and let behavioral signals carry more of the score. If datacenter traffic is never legitimate for your product, raise that weight.

Download at tirreno.com/download.