How to Test if Your Proxy and VPN Detection Is Working

You test proxy and VPN detection by sending a labeled mix of known VPN traffic, known proxy traffic, and clean control traffic through your detector, then comparing the decisions with the labels you already know. A detection system is not “working” because it blocks a few suspicious IPs. It is working when it flags the right sessions, lets clean traffic through, and can show you why each decision was made.

The fastest first check is simple: take a known VPN address, a known proxy address, and a normal residential address, visit your test page through each one, and see whether the outputs match. That gives you one data point. The process below turns that into a repeatable test you can trust.

What you need before you test

Build a small test rig before you change anything. You do not need expensive equipment, but you do need to know what “correct” looks like.

• A detection endpoint. This is the page, API, or script that applies your proxy/VPN rules. Use a staging copy if you can; if not, use a real page you can afford to pollute with test traffic.
• Known VPN endpoints. Collect IPs from a VPN provider you control, or from a current list of provider ranges.
• Known proxy endpoints. Use datacenter proxies and, if possible, residential proxy sample IPs.
• Clean control IPs. These are your normal office, home, and mobile connections.
• Signal-level logs. Your detector should tell you which individual signals fired, not just “blocked” or “allowed.”
• A pass/fail rule. Decide in advance how many false positives and false negatives you can tolerate.

Step 1: Build a labeled test set

A labeled test set is a list of IPs with their correct answer attached. For each IP, write “VPN,” “proxy,” “datacenter,” “residential proxy,” “TOR,” or “clean.”

Start with at least 20 addresses per label. More is better, because IP reputation changes constantly and one VPN endpoint may behave differently from another.

Where to get test traffic

• VPN: Use a commercial VPN you can connect to and capture its public IP.
• Proxy: Use a proxy provider’s sample endpoint, or a current free proxy list, but remember free proxies are unreliable.
• Residential proxy: These are harder to get without paying. If you cannot get one, use a known provider’s trial or documented range.
• Clean: Your own ISP connection and mobile hotspot.

Label everything before you run the test. If you label after you see results, your judgment gets biased.

Step 2: Run traffic through the real detection path

Your detection system only matters if it sees the same signals a real visitor produces. Send test traffic through the same route that production traffic uses.

Use a real browser for client-side detection

Client-side detection looks at browser artifacts: WebRTC, timezone, language, fonts, screen metrics, and movement. A simple HTTP request does not contain those signals. Use a real browser, preferably one with no special flags, for each test session.

Use plain HTTP for server-side IP checks

If your detection only checks IP reputation and request headers, a command-line client like curl can work. But understand what you are losing: you will never see a WebRTC leak or a timezone mismatch.

Step 3: Add the control group you will forget

The most common mistake is testing only suspicious traffic. You also need clean traffic to prove the detector does not over-block.

From each clean IP, do the same actions a normal visitor would: load the page, scroll, move the mouse, and wait. If the detector flags those sessions as VPN or proxy, your false positive rate is a problem.

Also test legitimate VPN users if your policy allows VPNs. Many remote workers and privacy-conscious customers use VPNs. Deciding what to do with them is a policy choice, not just a technical test.

Step 4: Compare predictions with labels

For each test session, write down three things:

• The expected label (VPN, proxy, clean).
• The detector’s label.
• The detector’s confidence or reason, if available.

Then count the four outcomes:

• True positive: a VPN/proxy session was flagged.
• True negative: a clean session was allowed.
• False positive: a clean session was flagged.
• False negative: a VPN/proxy session was allowed.

Set a threshold in advance. For example, you might accept a false positive rate under 5% and a false negative rate under 10% for datacenter proxies. Residential proxies are harder, so a higher false negative rate there may be realistic. These are example thresholds, not universal guarantees.

Step 5: Inspect the signal-level logs

A label without evidence is not useful. If your detector flags a session, you should be able to ask “why?” and get a readable answer.

Useful signals come from many layers. Here is what a modern detector might check:

• WebRTC network leak: the browser reveals a local IP that conflicts with the apparent location.
• Timezone evasion: the IP says one timezone, but the browser reports another.
• Latency mismatch: the connection has a delay that does not match the IP’s physical location.
• IP address inconsistency: the same session uses multiple IPs or an incoherent routing path.
• DNS routing mismatch: DNS traffic and web traffic do not follow the same route.
• OS/TCP TTL mismatch: the operating system claimed by the browser does not match the network stack’s behavior.

Read more about these vectors on BotRefund’s detection-vectors page.

Step 6: Rerun the test on a schedule

VPNs and proxies change IPs constantly. A set of endpoints that works today will be stale in a few weeks. Put the test on a calendar.

A monthly run is a good baseline. Also rerun after:

• A browser update.
• A change to your detection provider or rules.
• A new campaign or landing page that attracts traffic.
• A security incident or a spike in suspicious activity.

Key facts to keep in mind

The table below shows example signals from a real detection approach. They are useful because they show that one signal alone is misleading.

Signal	What it checks	Why it matters in your test
WebRTC network leak	Whether browser network paths reveal conflicting locations.	A test page can force WebRTC to expose a false IP.
Timezone evasion	Whether location and language settings agree.	A mismatched timezone is a red flag for VPN users.
Latency mismatch	Whether connection and browser request details stay consistent.	High latency to a nearby IP suggests a relay.
IP address inconsistency	Whether the visitor’s network identity is coherent.	A session with multiple IPs is suspicious.
DNS routing mismatch	Whether DNS and web traffic follow the same route.	It catches split-tunnel VPNs and DNS tricks.
OS/TCP TTL mismatch	Whether the visitor’s network identity is coherent.	A Windows browser with a Linux TTL points to manipulation.

BotRefund, for example, evaluates 106 browser, network, hardware, and behavior signals together. It does not make a decision from one suspicious browser property. That is the standard your test should aim for: a decision with a pattern behind it, not a single checkbox.

Limitations of these tests

No test can prove your detection is perfect. There are always gaps.

• Residential proxies are hard. They use real ISP addresses, so they look like ordinary users. You may need behavioral analysis, not just IP reputation.
• VPN IPs are shared. Many users share one VPN exit IP, so blocking that IP can block hundreds of legitimate people.
• IP lists decay. Free lists and blocklists go stale quickly.
• Browsers change. WebRTC leaks can disappear after a browser patch, so a passing test today may not pass next quarter.
• Test traffic differs from attack traffic. A real attacker may use a newer evasion technique that your public test set does not include.
• Policy matters. Blocking every VPN may be correct for a bank, but wrong for a news site with privacy-conscious readers.

What is “working” depends on your risk tolerance. For an ad-funded site, false positives may be worse than false negatives. For a fraud-sensitive checkout, false negatives are the bigger cost. Define your own bar before you test.

FAQ

How many test IPs do I need?

At least 20 per label for a first pass, more if you want stable percentages. The exact number is less important than covering VPNs, datacenter proxies, and clean traffic.

What is a false positive?

A clean visitor is flagged as a proxy or VPN user. False positives matter because they send real customers to a block page or a CAPTCHA.

Can I test with only IP addresses?

Yes, but you only test IP reputation and header checks. You will miss browser-side signals like WebRTC leaks, timezone mismatches, and behavioral patterns.

Why does my detector keep missing residential proxies?

Because residential proxies use normal ISP IPs and do not appear on most proxy lists. Detecting them requires a pattern of behavior, not a single IP lookup.

How often should I retest?

Monthly is a reasonable baseline. Also retest after browser updates, detection rule changes, or a new wave of suspicious traffic.

Is a free proxy list good enough for testing?

Useful for a quick check, but not for a formal test. Free proxies are slow, often blocked, and do not represent commercial proxy services attackers actually use.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

• Proxy/VPN Check: Am I Using a Proxy or VPN? How IP Detection Works ...
• VPN Detection Test | nodedata.io
• VPN & Proxy IP Detection Tool

How BotRefund can help

BotRefund’s detection engine combines 106 browser, network, hardware, and behavior signals and evaluates them as a pattern, not as a single suspicious property. If you have run the steps above and you are not sure why a session was flagged, the free bot audit gives you a second opinion on your traffic. It can also show which signals a pattern-based detector would rely on, which is more useful than a raw IP check.

Note: a free audit is a snapshot, not a live firewall. You still need your own monitoring and testing schedule.