VPNs, Proxies, and Evasion: Tech to Detect and Prevent

By Alex Moran — Trust & Safety Lead (ex-AppSec). Reviewed Aug 2026. Next review Feb 2027. Privacy notes • FAQ

• A spike, then silence
• The stakes
• Quick glossary
• The stack, not a silver bullet
• The table you’ll actually use
• Three field notes
• Signals that matter
• What evaders do (high level)
• Fight fraud, not users
• Ship it: 30–60–90 day plan
• Metrics that matter
• Notes by industry (iGaming, fintech, travel)
• Tooling that won’t lock you in
• Mistakes we still see
• FAQ & Mini glossary

A spike, then silence: how evasion sneaks past your dashboards

Last quarter, sign-ups jumped 18% in one day. Sales cheered. Then refunds rose. Chargebacks hit a week later. Your alerts were noisy, then flat. Did fraud stop? Or did it blend in? That is the hard part.

The stakes: money, trust, and a lot of false alarms

Blocks are cheap. Good blocks are not. Each bad block hurts a real user. Each miss hurts cash and trust. In some zones, it also risks fines. The goal is clear: see risky traffic fast, act with care, and move the needle with low pain.

Quick glossary that actually helps

VPN: a tunnel that hides network path and IP. See a clean intro on what a VPN is. Many good users use it at home, at work, and on trips.

Proxy: a relay that sits between a client and a site. It can chain, cache, or change data. MDN has a solid guide on proxy servers and tunneling.

Tor: a privacy network run by volunteers. Some users exit via known nodes. Read about Tor exit relays to learn what those IPs are.

CGNAT: many users share one public IP from a mobile or ISP pool. See carrier-grade NAT explained. This is key when an IP “looks busy.”

• Myth: “VPN = bad.” Reality: VPN is normal; weight by behavior and flow risk.
• Myth: “Tor = all crime.” Reality: It is a stronger risk sign, but not a rule by itself.
• Myth: “Device prints never fail.” Reality: They drift and can clash with privacy law.

The stack, not a silver bullet

Look at layers: network, protocol, client, behavior, and business context. No one signal holds up alone. Blend them. Score, do not slam the door. Add light steps only when risk rises.

The table you’ll actually use

Use this as a quick map. It shows where each signal helps, how it can fail, and what to do next.

Three vignettes from the trenches

We caught it. A gift‑card run came from three hosts in one ASN. JA3 was odd, headers clashed, and the flow skipped help pages. We slowed only the pay step. Loss fell 62% in two days. Complaints stayed flat.

We missed it. A weekend wave used a mobile ISP with CGNAT. Many users shared one IP. Our IP rule hit good users. We learned to join IP with behavior and account age. We rolled back in 2 hours.

We tuned it. Device prints drifted after a browser update. We cut their weight by half and raised flow‑based checks. False blocks dropped 38% with no loss jump.

Signals that pull their weight (and where they fail)

IP/ASN intel: trust, but verify

IP data helps, yet it lies at the edges. Geo can be off; see GeoIP accuracy. Abuse tips help too; see community abuse reports. Still, CGNAT and big office egress make one IP look like a botnet. Treat a “bad IP” as a nudge, not a hammer.

TLS and HTTP fingerprints

JA3 can flag strange client stacks; read JA3 TLS fingerprinting. Pair it with header checks. Some hits are false since users share stacks behind middleboxes. Store hashes, watch deltas, and alert on sharp mix shifts.

DNS privacy and ECH

DoH and ECH cut passive hints. If SNI is masked, you get less about the path. That is fine. Users want privacy. Learn the basics of DNS‑over‑HTTPS (RFC 8484) and Encrypted Client Hello. Net‑net: lean more on behavior, account age, and payment signals.

Device and browser consistency

Device prints are tempting. But they change over time and can be sensitive. See the browser uniqueness study and fingerprinting tests. Use light client checks to find odd mixes (e.g., locale vs keyboard vs timezone). Do not hard block on one odd field.

Behavioral telemetry

Sequence and speed tell a lot. The OWASP list of bad bot types is a good frame; see OWASP Automated Threats to Web Apps. Build small rules first: too‑fast adds to cart, no scroll before pay, 10 sign‑ups in 3 mins. Then add risk by flow: account, pay, withdraw.

Identity and auth signals

Follow strong yet fair auth rules. The NIST SP 800‑63B guide helps set AAL targets. Tie step‑up to risk, not to all users. Use OTP or passkeys on spikes, big sums, or KYC gaps. Avoid repeated loops that trap good users.

What evaders do, in broad strokes

They rotate IPs. They rent device farms. They mix headless tools with light delay. They copy normal click paths. They try resi proxies to look like home users. This is not secret. The key is to join weak hints into a clear score, and to act on the right step in the flow.

Fighting fraud without punishing real users

Add friction only when risk rises. Use short OTP prompts. Use doc checks only on cash‑out or high sums. If you must challenge, try tokens that do not leak identity, like Privacy Pass. Avoid heavy CAPTCHA; it can block people with access needs. Read the W3C note on the Inaccessibility of CAPTCHA.

Privacy and compliance guardrails

Be clear on what you collect and why. Get consent where needed for tracking and device checks. Give users a way to appeal a block. For law cues, see the EDPB guidance on automated decision‑making (Art. 22) and the ICO’s note on online tracking and consent.

Ship it: a 30–60–90 day blueprint

Day 0–30: see and log

• Baseline key paths: sign‑up, sign‑in, pay, cash‑out.
• Log IP/ASN, JA3 hash, headers, session IDs, and simple client checks.
• Tag 10 clear bot cases and 10 clear false blocks. Create feedback tags.
• Add soft rate‑limits to hot paths. No blocks yet; observe.

Day 31–60: score and act

• Build a simple score: IP weight small, behavior medium, account/pay high.
• Set three actions: allow, step‑up (OTP/passkey), review/block for top risk.
• Publish an internal runbook. Add an appeals path.
• Start weekly reviews of false positives and misses. Tune weights only, not rules yet.

Day 61–90: tune and harden

• Promote the top 5 rules to hard blocks with rollback switches.
• Add alerts for mix shifts: IP ASNs, JA3, click path, and BINs.
• Document risk by flow and region. Set AAL targets using NIST SP 800‑63B.
• Run an audit on data use and consent. Update your help page with a short, kind explainer.

Metrics that matter

• True/false positive rate by action (allow, step‑up, block).
• User friction: OTP prompts per 1,000 sessions; doc checks per 10,000.
• Manual review load and SLA.
• Refund and chargeback deltas, lag‑adjusted.
• Signal health: % logs with full fields; alert noise ratio.

Keep a light SRE view on this. See the SRE guide on monitoring distributed systems. You want stable, clear signals, not spiky graphs.

Industry notes (including iGaming)

iGaming. Risk is high at sign‑up and cash‑out. Rules push for age and ID checks; see the UK rules on Age and ID verification. Keep friction risk‑based: light checks on entry, stronger checks on first deposit and on payout. For user context, independent review hubs often document KYC norms and fair play. See, for example, Casino Bonuses in Ireland 2026 to spot common user paths and bonus terms that can shape risk rules.

Fintech. Watch for card testing, fast ATO loops, and mule rings. Pay close care to BIN risk, AVS, and 3DS results. Add step‑up on first large transfer or new device.

Travel/marketplaces. High season brings bot scrapes and price abuse. Use path rules for search spam and hold on high‑risk pay flows during spikes.

Tools that won’t lock you in

Use open tools where you can. Zeek is great for network‑level views. For light, legal client prints, see FingerprintJS (open source). For IP and mail hygiene, study M3AAWG best practices. Tie these into your own risk engine so you can switch vendors with less pain.

Mistakes we still see (and how to dodge them)

• Overblocking on IP alone. Fix: join IP with behavior and account age.
• Static rules that rot. Fix: set review cadences; add drift alerts.
• Ignoring CGNAT. Fix: treat mobile ISP IPs with care; use per‑session data.
• CAPTCHA for everything. Fix: use risk‑based checks; try Privacy Pass tokens.
• No appeals path. Fix: give a short form and fast human eyes.

FAQ

Can you detect VPNs without locking out real users?

Yes, if you do not use IP as a hard rule. Use small IP weight, then add behavior and account context. Act on high‑risk steps only.

Are device fingerprints legal for fraud control?

Often yes, but needs care. Limit scope, get consent where needed, and give a path to appeal. See our notes in the Privacy section.

Should we block Tor?

It depends. Tor is a strong risk sign at sign‑up and at cash‑out. In many apps, a step‑up is enough. Some flows (e.g., card testing) can justify a block.

What is the best first step for a small team?

Start with logs and a weekly review. Add a simple score. Add risk‑based OTP on cash‑out. Then tune.

Mini glossary

Next steps

Pick two quick wins this week: add JA3 to logs and set a soft hold on fast cash‑outs. Write down your appeals path. In a month, you will know more, block less, and save real money with less pain.

Editorial: Reviewed Aug 2026 for ECH and DoH adoption trends. We will refresh after major browser changes or law updates.

trackbacks