“Block VPN users” sounds like a simple feature request. In reality it’s one of the most nuanced security decisions you’ll make. Done well, it reduces abuse, fraud, and bot traffic. Done badly, it locks out legitimate paying customers and drives engineers to public Twitter rants.

This post walks through how VPN/proxy detection actually works, the techniques that hold up in production, and — equally important — when you shouldn’t block.

Why People Block VPNs

The legitimate reasons:

Fraud reduction. Most fraudulent transactions don’t come from the buyer’s real home connection.
Geo-licensing compliance. Streaming services, gambling sites, and some SaaS products have contractual obligations to restrict access by country.
Abuse prevention. Free-tier abuse (one user creating many accounts) is harder over residential IPs and easier over VPN/proxy infrastructure.
Bot mitigation. Scrapers, credential stuffers, and inventory hoarders frequently use VPN/proxy networks.

The illegitimate ones (worth calling out):

“VPN users are suspicious by default” — most VPN users are privacy-conscious people who pose no threat.
“Our security team said so” — without a specific threat model, this is cargo-culting.
“Compliance” — only valid if there’s a specific regulatory or contractual requirement.

If you’re blocking VPNs, be honest with yourself about which category you’re in. The next sections assume you’ve decided the answer is yes for a real reason.

How VPN/Proxy Detection Actually Works

There’s no protocol-level “I am a VPN” flag on a connection. Detection is statistical, based on layered evidence.

1. Known IP Lists

Commercial VPN providers exit through known IP ranges. Threat-intel providers maintain lists of these ranges and update them continuously. The major IP geolocation APIs (Ip2Geo included) embed VPN/proxy flags in every response.

Coverage isn’t perfect — small or new VPN providers fly under the radar, and providers occasionally rotate their exit IPs faster than lists update. But for the top 50 commercial VPNs, list-based detection catches 80–95% of traffic.

2. ASN Classification

Every IP belongs to an autonomous system. Each ASN can be classified by use case:

Residential (Comcast, BT, Vodafone) — real homes.
Mobile (T-Mobile, Verizon Wireless) — mobile data.
Business (corporate ISPs, small fiber providers) — offices.
Hosting / Cloud (AWS, GCP, Hetzner, OVH) — datacenters.
VPN / Proxy (NordVPN, ExpressVPN, Mullvad, etc.) — known anonymization services.

If an IP belongs to a hosting ASN, the user is “almost certainly not at home.” That’s not the same as “almost certainly a VPN user,” but it’s the same signal for most fraud purposes. A genuine residential user does not appear from AWS IPs.

3. Behavioral Fingerprinting

More advanced: the connection’s characteristics themselves. VPN traffic exhibits patterns — TCP window sizes, MTU values, latency profiles, browser fingerprints inconsistent with the claimed location — that direct connections don’t.

Most teams don’t build this themselves. Bot-management products (Cloudflare Bot Management, Akamai Bot Manager, DataDome) bundle it.

4. Tor Detection

Tor is a special case and much easier. The Tor project publishes an official, real-time list of exit nodes. If a connection’s source IP is in that list, it’s a Tor user. Period.

The list is small (a few thousand IPs at any time) and updates frequently — refresh hourly from the Tor project’s exit-addresses endpoint or use an IP enrichment provider that includes it.

5. Latency Triangulation

If a user’s IP geolocates to Tokyo but their measured round-trip latency from your Tokyo server is 250ms, they’re not really in Tokyo. They’re terminating a VPN session through a Tokyo exit node from somewhere else.

This is the kind of check that only works at scale (you need ground-truth latency data from your own servers in many cities), but it’s one of the most accurate signals when you have it.

Implementing Detection

For most teams, the practical implementation is:

Look up the visitor’s IP via an IP geolocation API that includes VPN/proxy/Tor flags in the response.
Get back fields like is_vpn, is_proxy, is_tor, plus asn, asn_type, country.
Apply your policy (block, warn, step-up auth, allow with logging).

The whole thing is a single HTTP call at the edge of your request. Latency is in the 5–50ms range, depending on where the API runs and where your servers are. Cache the result per-IP for at least 60 seconds so you’re not re-querying for the same user on every request.

Example pseudocode at a reverse proxy or middleware:

on request:
    ip = request.client_ip
    
    cached = cache.get('geo:' + ip)
    if cached:
        geo = cached
    else:
        geo = api.lookup(ip)
        cache.set('geo:' + ip, geo, ttl=60)
    
    if geo.is_tor:
        # Hard block — Tor traffic on this app is not legitimate
        return 403
    
    if geo.is_vpn and request.path in sensitive_paths:
        return require_step_up_auth()
    
    if geo.asn_type == 'hosting' and is_signup_request:
        return require_captcha()
    
    proceed()

The exact policies are yours. The pattern — enrich at the edge, branch on the enrichment — is the same everywhere.

The False-Positive Problem

VPN/proxy detection has structural false positives that you cannot eliminate. Plan for them:

Mobile network gateways

Some mobile carriers route traffic through CGNAT gateways that, from the geo-data perspective, look exactly like commercial VPN exit nodes. Don’t be surprised if 5–10% of your mobile traffic is flagged.

Corporate VPNs

Employees of large companies often have their internet traffic forced through a corporate VPN. They’re real users; they look like VPN users to your detection system.

Privacy tools (Apple Private Relay, Cloudflare Warp)

Apple’s iCloud Private Relay routes traffic through a two-hop proxy. Cloudflare Warp does similar. Both will appear as proxies to most detection systems. Both are growing in adoption.

Browser-built VPNs (Opera, Brave Tor mode)

Built-in browser VPNs aren’t always detected by IP lists but show up as obvious traffic patterns. Users may not even realize they have it enabled.

If you hard-block on any VPN/proxy flag, expect to alienate a meaningful share of legitimate users. The mitigations:

Don’t hard-block. Use VPN detection as one signal in a risk score, not a kill switch.
Provide a clear error path. “We’ve detected unusual traffic. Please disable your VPN and try again.” not just “Access Denied.”
Allow appeal. A support contact for users who think they’re wrongly blocked.
Whitelist your own customers. If a user’s account is in good standing for a year, the VPN flag matters less.
Step up, don’t block. A CAPTCHA or 2FA challenge resolves most legitimate users while still catching automated abuse.

When You Shouldn’t Block

A few cases where the answer is “leave VPN users alone”:

You sell to consumers in privacy-conscious markets (Germany, Netherlands, Scandinavia — places with high baseline VPN usage). Blocking VPNs there cuts a significant chunk of your addressable market.
You sell developer tools. Developers run VPNs and use cloud servers constantly. The user looking at your docs from a Hetzner box is your highest-intent prospect.
You’re a content site. Blocking VPNs on a marketing site, blog, or documentation hurts SEO and drives away exactly the audience you want.
Your fraud rate is already low. If you’re not seeing fraud, blocking VPNs solves a problem you don’t have, at a cost you will have.

If you can’t articulate the specific threat the block is mitigating, don’t add the block.

A Layered Strategy

The most common production setup that actually works:

Layer 1 — Edge enrichment. Every request hits a small middleware that looks up the IP and attaches geo, is_vpn, is_tor, asn, asn_type to the request context. Cached per-IP for 60–300 seconds. Total latency cost: <10ms at the edge.

Layer 2 — Per-action policy. Different endpoints have different policies. Read-only stuff (browsing, public APIs) lets everything through. Signup, password reset, payment requires more checks. The middleware in Layer 1 has done the work; this layer is just if statements.

Layer 3 — Risk scoring. For high-stakes actions, the VPN/proxy flag is one input into a scoring function that also considers device fingerprinting, behavior history, IP velocity, and account age. The block decision is made on the score, not on any single signal.

Layer 4 — Manual review. For the highest-stakes actions (large withdrawals, account changes for established customers), a soft block routes to a human review queue rather than just rejecting.

This layering gives you the benefits of VPN detection (catching the bulk of automated/fraudulent traffic) without the costs (random legitimate users hitting a 403).

The Detection-As-Service Question

You can detect VPNs yourself from a list, or you can outsource it to an IP-intelligence provider. Outsourcing has clear benefits:

The provider maintains the IP-to-classification mapping across all the major VPN/proxy services.
Updates are continuous, not “next weekly download.”
You get other enrichments — country, city, ASN — in the same call.

The downside: you’re paying per-lookup or per-month, and adding a network hop. Most products are willing to accept that trade-off because the engineering cost of maintaining VPN detection in-house is real and ongoing.

Ip2Geo returns VPN, proxy, and Tor flags inline with every geo response. The free tier covers 1,000 lookups/month, which is plenty to wire it into your auth flow and see what your traffic looks like before committing to a paid plan.

TL;DR

Detection isn’t a binary flag — it’s layered evidence from IP lists, ASN classification, behavior, and (sometimes) latency.
Don’t hard-block. Use it as one signal in a risk score. Step up auth instead of denying access.
Plan for false positives. Mobile carriers, corporate VPNs, Private Relay, Warp — none of those are fraud.
Match policy to action. Strict on signup/checkout, loose on browsing.
Outsource the detection layer. It’s cheaper to pay for an enrichment API than to maintain VPN IP lists yourself.

If your goal is genuine abuse reduction (not security theater), this approach catches the traffic that matters while leaving real users alone.

How to Block VPN and Proxy Users Server-Side Without False Positives