How to Detect VPN and Proxy Users: 6 Proxy Detection Methods That Stop Fraud

Introduction

If you run fraud or risk for an online business, you have probably seen it: a signup that looks normal, a checkout that passes card checks, and then a chargeback two weeks later. When you trace it back, the IP address belonged to a VPN exit server, a proxy pool, or a rented cloud machine.

VPNs and proxies are not bad by themselves. Plenty of people use them for privacy on public Wi-Fi or for work. The problem is that fraudsters lean on the same tools to hide their real location, rotate identities, and slip past simple IP rules.

This guide walks through six proxy detection methods that actually hold up in production, what each one catches, where each one breaks, and how to combine them into a policy that stops fraud without punishing honest users.

Automated traffic made up 51% of all web traffic in 2024, and bad bots alone accounted for 37%. Imperva also found that 21% of bot attacks routed through ISPs used residential proxies to look like real home users. Imperva 2025 Bad Bot Report

Why VPN and Proxy Detection Matters for Fraud Teams

Most fraud controls lean on location in some way. You compare billing country to IP country, flag logins from a new region, or limit promotions to certain markets. A VPN or proxy quietly breaks all of those checks.

Here is where masked IPs tend to show up:

• Account takeover: attackers replay stolen credentials from IPs near the victim so the login looks familiar.
• Fake account creation: one person spins up dozens of accounts, each from a fresh proxy IP, to farm signup bonuses.
• Card testing and payment fraud: bots cycle through proxies so velocity rules never see the same IP twice.
• Geo restriction abuse: users pretend to be in a cheaper market or a region where your offer applies.

If account takeover and multi-accounting are your main pain points, the account takeover use case and the fake accounts use case show how IP signals fit into those flows.

Anonymous vs Transparent Proxies (and Why the Type Matters)

Not every proxy hides the user in the same way, so it helps to know what you are dealing with.

A transparent proxy forwards the request but still tells you the original client IP, usually in headers like X-Forwarded-For or Via. Corporate networks, schools, and some ISPs use these. They are rarely a fraud signal on their own.

An anonymous proxy hides the original IP but still reveals, through headers or behavior, that a proxy sits in the middle. An elite or high anonymity proxy goes further and tries to look like a direct connection.

VPNs behave like high anonymity proxies from your point of view. The connection arrives from the VPN server, and nothing in the request points back to the real user. That is why header checks alone are not enough, and why the methods below focus on the IP itself.

Method 1: IP Intelligence Lookups Against Known VPN and Proxy Ranges

The most reliable starting point is checking the connecting IP against an intelligence source that tracks VPN servers, public proxies, and anonymizer networks.

The old approach was a static blocklist you downloaded once a month. That does not work anymore. Commercial VPN providers add and retire servers constantly, and proxy pools churn even faster. A list that was accurate last quarter will miss a big share of today's exits.

A good IP intelligence source updates continuously and tells you more than "yes or no". You want to know whether it is a VPN, a proxy, Tor, a hosting provider, or a privacy relay, because each one deserves a different response.

Greip's VPN and proxy detection service returns all of these as separate flags in a single lookup, which we will use in the API section below.

Method 2: Datacenter and Hosting IP Detection

Real customers browse from home broadband, mobile networks, and office connections. Very few of them shop from an AWS, DigitalOcean, or Hetzner server.

That is why hosting detection is one of the strongest signals you can add. If an IP belongs to a datacenter or cloud provider, the traffic is often a bot, a scraper, a self-hosted VPN, or a fraudster's remote machine.

The usual way to spot this is by the network that owns the IP. Every IP range is announced by an Autonomous System, and that ASN tells you whether the owner is an ISP, a business, or a hosting company. Greip's network intelligence and ASN data gives you that context.

Method 3: Tor Exit Node Detection

Tor routes traffic through several volunteer relays and exits from a public exit node. The list of exit nodes is public, which makes Tor one of the easier things to detect.

The bigger question is what to do about it. For a news site, Tor users may be journalists or people in restrictive countries. For card checkout or account creation on a fintech app, Tor traffic carries a very high abuse rate, and many teams block it outright on those flows.

Decide per flow. Blocking Tor on your blog makes little sense. Blocking it on payment capture often does.

Method 4: Residential Proxy Detection

Residential proxies are the hardest category, and the one fraud teams worry about most right now.

Instead of exiting from a datacenter, traffic exits from real home devices, often through apps or SDKs that quietly sell the device's bandwidth. To a basic IP check, the connection looks like a normal person on a normal ISP.

You catch residential proxies by combining signals rather than relying on one:

• IP intelligence that specifically tracks residential proxy exits, since the same home IPs get reused across many unrelated sessions.
• Velocity patterns, such as one IP touching many accounts or many cards in a short window.
• Mismatches between the IP location and other data, like browser timezone, language, or billing address.
• Device signals that do not match the claimed network, for example a desktop browser fingerprint on what should be a mobile carrier IP.

No single check is perfect here. The goal is to raise the cost for the attacker until the residential pool stops being worth it.

Method 5: Browser Timezone vs IP Geolocation Mismatch

This one is simple and surprisingly effective. The browser reports the device's configured timezone, and the IP address resolves to a location with its own expected timezone. When they disagree, something is worth a second look.

For example, the browser says America/New_York, but the IP geolocates to Frankfurt with timezone Europe/Berlin. That user might be traveling, or they might be routing through a German VPN server.

You can read the browser timezone in JavaScript and compare it to the timezone module from an IP lookup:

// In the browser: read the device timezone and send it with the form
const browserTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
// On the server: compare it to Greip's timezone for the client IP
async function timezoneMismatch(customerIp, browserTimezone) {
  const url = new URL(
    `https://v2.greipapi.com/lookup/ip/${encodeURIComponent(customerIp)}`
  );
  url.searchParams.set("params", "security,timezone");
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${process.env.GREIP_API_KEY}` },
  });
  const body = await res.json();
  return {
    mismatch: body.data.timezone.name !== browserTimezone,
    ipTimezone: body.data.timezone.name,
    security: body.data.security,
  };
}

Method 6: DNS and Port Signals

These two are older techniques, and they are worth understanding even if they play a supporting role today.

DNS Resolver Mismatch

When a user's DNS requests resolve through a server in a different country or network from their connecting IP, it can hint at a VPN or proxy. Some privacy tools route web traffic through a tunnel while DNS leaks out through the user's real ISP, and that gap is detectable with a DNS leak style check.

This needs extra setup, such as serving a unique hostname per session and logging which resolver asks for it. It is useful for deep investigations but rarely necessary for everyday screening.

VPN Protocol Ports

VPN protocols have well known default ports. OpenVPN commonly uses UDP 1194, PPTP uses TCP 1723, L2TP uses UDP 1701, and IPsec uses UDP 500 and 4500.

Here is the catch. Many VPN services deliberately run over TCP 443, the standard HTTPS port, and some over TCP 80, the standard HTTP port. They do this precisely because those ports carry ordinary web traffic and are almost never blocked. So seeing port 443 tells you nothing on its own.

Also, your website only sees the port a visitor connects to on your server, which is almost always 443. Port signals are really gathered by intelligence providers that scan IPs for open VPN services, which is one reason an API usually beats a homegrown port check.

How to Detect VPN and Proxy Users with the Greip API

Now let's put the IP side together. Greip returns VPN, proxy, Tor, bot, relay, and hosting signals in the security module of the IP Lookup endpoint. You request it by adding params=security to the call.

The Request

Authentication uses a Bearer token in the Authorization header. Put the IP you want to check in the path:

curl --request GET \
  --url 'https://v2.greipapi.com/lookup/ip/165.227.149.217?params=security' \
  --header 'Authorization: Bearer <token>'

If you want Greip to check the IP of the current caller instead, the VPN/Proxy Detection docs show the same module on the IP Geolocation endpoint.

The Response

Here is the sample response from the docs for a DigitalOcean IP in Frankfurt:

{
  "success": true,
  "data": {
    "ip": {
      "address": "165.227.149.217",
      "version": 4,
      "numeric": 2783155673,
      "bogon": false
    },
    "geo": {
      "continent": "Europe",
      "continent_code": "EU",
      "country": "Germany",
      "country_code": "DE",
      "region": "Hessen",
      "city": "Frankfurt am Main",
      "postal": "65931",
      "latitude": 50.11552,
      "longitude": 8.68417
    },
    "security": {
      "vpn_or_proxy": true,
      "vpn_or_proxy_type": "VPN",
      "tor": false,
      "bot": false,
      "relay": false,
      "hosting": true,
      "is_blacklisted": false
    }
  },
  "execution_ms": 4
}

This IP is flagged as a VPN and as hosting. That is a classic pattern for a self-hosted or commercial VPN running on cloud servers.

Turning Signals into a Decision

The checkout guide in the Greip docs maps these flags to allow, challenge, or block. Here is its Node.js example:

const GREIP_TOKEN = process.env.GREIP_API_KEY;
async function checkoutIpDecision(customerIp) {
  const url = new URL(
    `https://v2.greipapi.com/lookup/ip/${encodeURIComponent(customerIp)}`
  );
  url.searchParams.set("params", "security");
  const res = await fetch(url, {
    headers: { Authorization: `Bearer ${GREIP_TOKEN}` },
  });
  const body = await res.json();
  if (!body.success) {
    throw new Error(`Greip error: ${JSON.stringify(body)}`);
  }
  const s = body.data.security;
  if (s.is_blacklisted || s.tor || s.bot) {
    return { action: "block", security: s };
  }
  if (s.vpn_or_proxy || s.hosting) {
    return { action: "challenge", security: s };
  }
  if (s.relay) {
    return { action: "allow", security: s, note: "relay_detected" };
  }
  return { action: "allow", security: s };
}

Want to see the result for a single IP before writing any code? Try the free Proxy/VPN Checker.

Challenge vs Block: Building a Fair Policy

The biggest mistake teams make with VPN detection is turning every flag into a hard decline. That stops some fraud, but it also turns away privacy-conscious customers who would have paid you.

A more balanced starting policy looks like this:

• Block when the IP is on your own blacklist, when it is a Tor exit on a payment flow, or when it is clearly a bot.
• Challenge when the IP is a VPN, a proxy, or a hosting provider. Step up with 3-D Secure, an email or SMS code, or manual review.
• Allow privacy relays like Apple Private Relay in most cases. Many of those users are genuine.
• Escalate when several weak signals stack up, such as a proxy flag plus a timezone mismatch plus a brand new account.

Then watch your numbers. If challenge rates climb and conversion drops without a matching drop in fraud, loosen the rules. If chargebacks keep arriving from flagged traffic, tighten them.

Common Mistakes to Avoid

A few patterns come up again and again:

• Relying on one signal. Timezone alone, headers alone, or a blocklist alone will either miss a lot or block a lot.
• Using stale lists. Proxy and VPN exits change daily. Static lists age badly.
• Trusting forwarded headers. Read the client IP your edge infrastructure verified, not whatever the request claims.
• Checking only at signup. Attackers often switch to a proxy after the account is created, so check again at login and checkout.
• Not logging the signals. Store the security flags with each decision so analysts can review disputes and tune rules later.

Frequently Asked Questions

Can websites detect if I am using a VPN?

Yes, in most cases. Websites check the connecting IP against intelligence that tracks VPN servers, proxies, Tor, and hosting providers. They can also compare browser timezone and language to the IP location. Detection is not perfect, but commercial VPN servers are widely catalogued.

How does IP-based VPN and proxy detection work?

The site takes the IP address of the incoming connection and checks it against a continuously updated intelligence source of known VPN servers, proxy exits, Tor nodes, and datacenter ranges. If the IP matches, it is flagged with the type of anonymizer so the site can decide whether to allow, challenge, or block.

What is the difference between anonymous and transparent proxies?

A transparent proxy forwards your request but still passes your real IP in headers such as X-Forwarded-For. An anonymous proxy hides your real IP but may still reveal that a proxy is in use. High anonymity proxies and VPNs try to look like a direct connection.

How do you detect residential proxies?

Residential proxies exit from real home devices, so you need several signals together: intelligence that tracks residential proxy exits, velocity patterns like one IP touching many accounts, timezone or language mismatches, and device fingerprints that do not fit the network.

Are ports 80 and 443 a sign of VPN use?

No. TCP 80 and 443 are the standard web ports used by ordinary HTTP and HTTPS traffic. Some VPNs run over them to blend in, which is exactly why port numbers alone are a weak signal.

Should I block all VPN and proxy users?

Usually not. A better approach is to block high risk signals like Tor on payment flows, bots, and your own blacklisted IPs, and to challenge VPN, proxy, and hosting traffic with extra verification. That keeps fraud down without losing legitimate privacy-minded customers.

How do I check VPN and proxy signals with Greip?

Call the IP Lookup endpoint with the security module enabled. The response includes flags for VPN or proxy, the proxy type, Tor, bot, relay, hosting, and blacklist status, which you can map to allow, challenge, or block in your own logic.

Conclusion

VPNs and proxies will keep getting easier to use and harder to spot, especially with residential proxy networks growing. The answer is not a single magic check. It is a layered approach.

Start with a solid IP intelligence lookup that separates VPN, proxy, Tor, hosting, and relay traffic. Add context like timezone mismatches and velocity. Then map those signals to a policy that blocks the clear abuse and challenges the gray areas.

If you want to try this on your own traffic, start with the Greip VPN and proxy detection service and the IP Lookup docs, and see how much hidden risk shows up in your signups and checkouts.