DEV Community: Kaspar Tomson

How to detect VPN and proxy users at signup (and why an IP lookup isn't enough)

Kaspar Tomson — Wed, 23 Sep 2026 10:46:50 +0000

Most "is this visitor on a VPN?" tutorials do the same thing: take the visitor's IP, send it to a lookup API, get a yes or no. It works for the obvious cases. It falls short exactly where fake signups, trial abuse and card testing come from.

This post covers what an IP can and can't tell you, why checking in the browser alone doesn't work either, and the pattern that does: collect evidence in the browser, decide on your server.

What an IP address can tell you

An IP tells you who owns the address. It doesn't tell you how the visitor got there.

Question	IP lookup alone
Is it a Tor exit node?	Yes, the exit list is public
Is it a cloud or datacenter range (AWS, GCP, Hetzner…)?	Yes, providers publish their ranges
Is it a commercial VPN exit?	Sometimes, depending on how fresh the list is
Is it a residential proxy?	Hard: the address belongs to a real home ISP
Is the browser automated or an antidetect browser?	No, that lives in the browser, not the IP

Residential proxies are the problem case. They route traffic through real home connections, so the IP looks like an ordinary broadband customer. And the tools people use for multi-accounting (antidetect browsers like GoLogin, AdsPower, Multilogin) change the browser, not just the network.

Why checking in JavaScript alone doesn't work

The classic browser-side tricks:

Timezone vs IP country. Compare Intl.DateTimeFormat().resolvedOptions().timeZone with the IP's country. It flags VPN users, but also everyone travelling, working remotely or with a misconfigured laptop.
WebRTC leaks. This used to expose the real local IP. Modern browsers hide local addresses (mDNS), and most VPN apps block the leak.

Both run in code the visitor controls. Anything your frontend decides can be edited in DevTools. So the browser should collect evidence, and your server should decide.

The pattern: evidence in the browser, decision on the server

A script on the signup page collects network and browser evidence and adds it to the form as hidden fields.
The form posts to your backend as usual.
Your backend sends that evidence (plus your secret API key) to a detection API and gets a verdict back.
Your code decides: continue, ask for one more step, or stop.

Here's what that looks like with Maskbreak (the API I build; it was called Sentinel until August). The same shape works with any provider that evaluates a live visit.

The page with the form:

<script async src="https://maskbreak.com/assets/sentinel.js"></script>

<form class="monocle-enriched" method="POST" action="/signup">
  <!-- your existing inputs; the script adds two hidden fields -->
</form>

Your server (Express):

app.post('/signup', async (req, res, next) => {
  const token = req.body.monocle;                 // network evidence
  const fingerprintEventId = req.body.sentinel_fp; // browser evidence
  let result = null;

  try {
    const r = await fetch('https://maskbreak.com/v1/evaluate', {
      method: 'POST',
      signal: AbortSignal.timeout(5000),
      headers: {
        Authorization: 'Bearer ' + process.env.MASKBREAK_API_KEY,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({ token, fingerprintEventId })
    });
    if (r.ok) result = await r.json();
  } catch {
    // evidence unavailable: record it, don't guess
  }

  console.log('signup check', result?.decision, result?.reasons);
  req.fraudCheck = result; // week one: watch only, never block
  next();
}, existingSignupHandler);

The key stays on the server. Never put it in frontend code.

A response looks like this (a VPN visit):

{
  "decision": "review",
  "risk_score": 65,
  "country": "NL",
  "network": {
    "vpn": true,
    "proxy": false,
    "datacenter": true,
    "tor": false,
    "service": "PROTON_VPN"
  },
  "reasons": ["vpn_detected", "datacenter_asn"]
}

network.service names the VPN or proxy when it's known; otherwise it's null.

Treat a VPN as "review", not "block"

Plenty of legitimate people use VPNs: privacy-minded users, people on hotel Wi-Fi, whole companies. Blocking every VPN costs you real signups.

A better default:

allow: continue your normal checks.
review: ask for one more step (an email code, a phone check, manual approval).
block: stop. Keep this for strong evidence: residential proxies, Tor, automation, tampered browsers.

In code, once you're happy with what you've seen in the logs:

const d = req.fraudCheck?.decision;
if (d === 'block') return res.status(403).json({ error: 'Request declined.' });
if (d === 'review') return res.status(409).json({ next: 'verify_email' });

Start by watching, not blocking

Turn it on in log-only mode for a week. Look at what would have been reviewed or blocked, check a few by hand, then switch the two lines above on. You'll find out how much of your traffic is VPN (often more than you'd guess) without locking out a single real user.

Also decide up front what happens when evidence is missing, for example when an ad blocker stops the script. For a newsletter signup, let it through. For a payout, hold it.

Testing without real traffic

You don't need a VPN to test your branches. Maskbreak has a public sample endpoint and sandbox tokens:

curl 'https://maskbreak.com/v1/evaluate/sample?scenario=vpn'

curl https://maskbreak.com/v1/evaluate \
  -H 'Authorization: Bearer sk_test_sandbox' \
  -H 'Content-Type: application/json' \
  -d '{"token":"test_proxy"}'

Token	Decision
`test_clean`	allow
`test_vpn`	review
`test_proxy`	block
`test_tor`	block

These are contract tests for your code paths, not a measure of detection quality.

Wrap-up

An IP lookup is good for Tor and cloud ranges. It can't see residential proxies or what the browser is doing.
Browser-only checks are easy to fake. Collect evidence in the browser, decide on the server.
VPN on its own means review, not block.
Watch first, enforce later.

Maskbreak is free during its open beta: 1,000 visitor checks an hour per API key, no card. There's a live check of your own visit on the homepage: https://maskbreak.com. Docs: https://maskbreak.com/api

How to Detect VPNs, Proxies and Tor in Node.js (Free API, No Card)

Kaspar Tomson — Thu, 27 Aug 2026 14:27:22 +0000

Someone signs up for your free trial, burns the credits, and comes back an hour
later as a new account. Or 400 accounts claim the same referral bonus. Or your
"unique visitors" number is 30% datacenter traffic.

All three start the same way: the request came from an IP the user does not
actually live behind. Here's how to check that in Node, in one call, for free.

Why the obvious approaches don't work

Blocking by ASN. You grab a list of hosting ASNs, block AWS, DigitalOcean,
Hetzner. This catches the laziest 20% and nothing else. Commercial VPNs
increasingly exit through leased residential IPs, and residential proxy
networks are literally other people's home connections — real ISPs, real
cities, clean reputation.

Rate limiting by IP. Attackers rotate through pools of hundreds of
thousands of IPs. Rate limiting is a speed bump for volume, not a signal about
identity.

GeoIP mismatch. "Card is French, IP is Dutch" produces enough false
positives from ordinary travellers and corporate VPNs that most teams turn the
rule off within a month.

What you actually want is a direct answer to: is this IP a tunnel, and what
kind? That's a different question from "where is this IP," and it needs a feed
of live tunnel data, not a geolocation database.

One call

curl -X POST https://maskbreak.com/api/lookup \
  -H 'Content-Type: application/json' \
  -d '{"ip":"185.220.101.1"}'

{
  "ip": "185.220.101.1",
  "known": true,
  "verdict": "block",
  "risk_score": 90,
  "signals": {
    "vpn": false,
    "proxied": false,
    "tor": true,
    "dch": false,
    "anon": true
  },
  "network": { "asn": null, "org": "Tor exit node", "country": null, "city": null }
}

A clean IP comes back small and boring:

{"ip":"8.8.8.8","known":false,"verdict":"allow","risk_score":0,"signals":null,"network":null}

known: false means nothing flagged it. That's the answer you want for the
overwhelming majority of your real users, and it's the reason this doesn't have
to be a scary thing to put in front of signup.

The signals, and what they actually mean

Signal	Meaning	Weight
`vpn`	Commercial VPN exit	+60
`proxied`	Proxy, including residential proxy networks	+60
`tor`	Tor exit node	floor of 90
`dch`	Datacenter / hosting range	+40
`anon`	Anonymised, method not otherwise classified	+30

Score is clamped to 100, and the verdict follows: >=80 block, >=40 review,
else allow.

Note that dch alone is 40 — a review, not a block. That's deliberate.
Datacenter traffic is your own monitoring, someone's corporate egress, a
security researcher, an AI crawler. It's worth a second look and it is not
worth a hard block on its own. The hard blocks are tunnels.

Also note dch and vpn are independent, and this is the part naive
implementations get wrong: VPN exits live in datacenters. If your logic is
if (datacenter) return block, you never learn which datacenter IPs are
tunnels, and you've collapsed two different decisions into one bad one.

Express middleware

const express = require('express');
const app = express();

app.set('trust proxy', true); // behind a proxy/CDN, or req.ip is your LB

async function ipRisk(ip) {
  const r = await fetch('https://maskbreak.com/api/lookup', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ ip }),
    signal: AbortSignal.timeout(1500)
  });
  if (!r.ok) throw new Error(`lookup ${r.status}`);
  return r.json();
}

async function riskCheck(req, res, next) {
  try {
    const result = await ipRisk(req.ip);
    req.risk = result;

    if (result.verdict === 'block') {
      return res.status(403).json({ error: 'Signup unavailable from this network.' });
    }
    if (result.verdict === 'review') {
      req.requireEmailVerification = true; // friction, not a wall
    }
    next();
  } catch (err) {
    // FAIL OPEN. A dead risk check must never take down signup.
    console.error('[risk]', err.message);
    next();
  }
}

app.post('/signup', express.json(), riskCheck, async (req, res) => {
  // ...create the account, honouring req.requireEmailVerification
});

Three things in there are the whole lesson:

Fail open. Your fraud check is a third-party network call in the hot path of
your most important conversion funnel. If it times out, users sign up. A risk
service that can 500 your signup page is a worse problem than the fraud it
prevents.

Set a timeout. AbortSignal.timeout(1500) — Node's default fetch has no
timeout at all, so without this a hung connection hangs the request until the
socket dies.

Two outcomes, not one. block and review are different. review means
add friction — email verification, a hold on payout, manual approval — not a

Most of your fraud lives in the review band, and most of your false positives do too, which is exactly why it should cost the user a step rather than the account.

Persist the result. Store signals and risk_score next to the account
row. In a month you can query which signals actually preceded chargebacks in
your product and re-tune from data instead of from a blog post, including
this one.

The keyed endpoint

The keyless POST /api/lookup above is rate limited for casual use. With a
free key you get GET /v1/lookup/{ip} at 1,000 requests/hour:

const r = await fetch(`https://maskbreak.com/v1/lookup/${ip}`, {
  headers: { Authorization: `Bearer ${process.env.SENTINEL_KEY}` }
});

Or the SDK, which is zero-dependency and runs anywhere fetch exists — Node
18+, Bun, Deno, Workers, Vercel Edge:

npm install @sentinelsup/sdk

The key is free, there's no card, and it doesn't expire — Maskbreak
is free at 1,000 req/hour with every signal included. Full docs at
maskbreak.com/api.

Where IP checks stop working

Be honest about the ceiling: IP intelligence catches tunnels. It does not catch
a determined attacker on a clean residential IP using an antidetect browser to
farm accounts. For that you need device-level signals — the fingerprint that
survives a new IP and a cleared cookie jar.

IP is the cheapest, fastest layer, it's one call, and it removes most of the
volume. It's the right first thing to ship. It just isn't the last thing.