How to Detect if a Visitor Is Using a Proxy or VPN

To detect if a visitor is using a proxy or VPN, compare their visible IP location with other network and browser signals. No single check is enough. A proxy or VPN can hide one signal, but it usually leaves another exposed. The most reliable method combines several signals into a confidence score.

Why Proxy/VPN Detection Matters for Advertisers and Site Owners

Proxy and VPN detection is not just a technical exercise. It protects money, data, and campaign performance. Many visitors who use a proxy or VPN are not real customers. They may be bots, scrapers, or ad fraud networks.

Advertisers lose a large part of their budget to invalid traffic. BotRefund reports that about 20% of ad traffic can be bots. When a bot clicks a paid ad, the advertiser pays for that click. If the bot uses a proxy or VPN, it is harder to prove the click was invalid.

Site owners also need to protect their conversion tracking. If bots trigger a pixel or conversion event, the ad platform starts optimizing toward bot behavior. This poisons the data and raises acquisition costs. Detection helps keep the signal clean.

There are other reasons to detect proxies and VPNs. A site may need to enforce regional licensing rules. A bank may need to block logins from high-risk locations. A premium service may need to stop users from bypassing regional pricing. In all these cases, detection is the first step.

Key Detection Signals

BotRefund lists several network and VPN evasion vectors that can expose a proxy or VPN. The most useful ones are WebRTC leaks, DNS routing mismatches, timezone evasion, latency mismatches, IP inconsistencies, OS/TCP TTL mismatches, and header mismatches. The table below summarizes them.

WebRTC Network Leak

WebRTC is a browser feature for audio, video, and data sharing. It can also reveal a local IP address. When a visitor uses a VPN or proxy, the public IP is masked. But WebRTC may still send the real local IP. If the local IP belongs to a different network or country, this is a strong signal.

DNS Tunnel and DNS Routing Leak

DNS translates domain names into IP addresses. A normal direct connection uses one route for DNS and for web traffic. When a VPN or proxy is in use, DNS may travel through a different tunnel. If the DNS resolver sits in another country or on another network, it suggests a proxy. BotRefund calls this a DNS tunnel leak or DNS routing mismatch.

Timezone Evasion

The browser knows the visitor's timezone. JavaScript can read it easily. Compare that timezone with the IP geolocation. A visitor in France should normally see a French timezone. If the IP says France but the browser timezone is Singapore, the connection is suspicious.

Latency Mismatch

A direct connection to a nearby server is fast. A VPN adds extra hops. If the IP location says London but the round-trip time is 300 ms, the traffic probably went through another country. Latency alone is not reliable, but it is useful when combined with other signals.

IP Address Inconsistency

Many proxy and VPN providers use known IP ranges. Commercial databases and blacklists can flag these ranges. However, residential proxies use regular home IPs, so they may not appear on any list. IP reputation is a good first check, but it is not enough.

OS/TCP TTL Mismatch

Each operating system has a default Time-To-Live value in network packets. For example, Windows and Linux use different default TTLs. If the TTL value suggests Linux but the user agent says Windows, the packet may have been modified or routed through a proxy.

Header Mismatches

HTTP headers contain metadata about the browser and connection. Common mismatches include an Accept-Language header that does not match the IP country, a user agent that does not match the browser engine, or an HTTP protocol version that is unusual for the claimed device. BotRefund tracks these as HTTP user-agent mismatch, Accept-Language mismatch, and HTTP protocol mismatch.

How to Combine Detection Signals into a Confidence Score

One signal can be misleading. BotRefund says no raw-signal scoring is enough. A prediction model looks at how 106 browser, network, hardware, and behavior signals fit together before classifying a visit. You can do the same on a smaller scale with a simple score.

Start each visitor at zero. Add points for each suspicious signal. Give more weight to strong signals. A WebRTC leak is strong because it directly shows the real local IP. DNS routing mismatch and OS/TCP TTL mismatch are also strong because they point to packet-level changes. Timezone and language mismatches are weaker because they can happen for innocent reasons.

Here is a concrete example. A visitor shows an IP located in London. The browser timezone is Europe/London. Accept-Language is en-GB. The WebRTC test reveals a local IP in Singapore. DNS queries go to a Singapore resolver. Latency to your server is 180 ms, which is high for London.

Score the signals like this. WebRTC leak adds 40 points. DNS routing mismatch adds 25 points. Latency mismatch adds 15 points. IP reputation adds 0 because the IP is not on a blacklist. Timezone and language consistency should subtract 10 points because they match the claimed location. The total is 70 out of 100.

What do you do with 70 points? That depends on your risk threshold. For a low-risk action like reading a public article, flag the visitor for review. For a high-risk action like changing a password or approving a payment, block the action and ask for additional verification. For a paid ad click, mark the visit as invalid and keep the evidence for a refund claim.

Residential Proxies and False Positives

Residential proxies are harder to detect than datacenter proxies. They use IP addresses assigned to real homes and mobile devices. Many residential proxy networks work through malware installed on regular computers and phones. From an IP reputation view, the traffic looks normal.

BotRefund notes that residential proxy botnets hide bot activity inside legitimate regional traffic. This is why advertisers see clicks from real cities and real internet providers. IP blacklists alone cannot catch them.

To detect a residential proxy, combine non-IP signals. Check DNS routing, TCP TTL, WebRTC, latency, and behavior. A real resident in London should have low latency to a London server and should use a nearby DNS resolver. A residential proxy user may show low latency to the proxy exit but high latency to your server, or DNS may leak through a different path.

False positives are a serious risk. Corporate networks route all employees through a central gateway. That gateway may be in another country. Mobile carriers also use shared IP addresses that can shift location. A user who travels for work may have a browser timezone that has not updated. These people are not cheating. They just look unusual.

The best answer is to use a confidence score, not a yes-or-no rule. Flag when uncertain. Block only when the risk is high and the evidence is strong. For ad fraud, do not block. Capture the signals and use them as proof that the click was invalid.

Step-by-Step Detection Workflow

1. Capture the visitor's IP address. Read it from the server request. Also capture X-Forwarded-For and other headers to spot proxy chains.
2. Check IP reputation. Look up the IP in a proxy or VPN database. Note whether it belongs to a datacenter, a known VPN provider, or a residential network.
3. Run a WebRTC leak test. Use JavaScript to request a local IP and compare it with the public IP. If they differ, record the mismatch.
4. Check the timezone. Read the browser timezone with Intl.DateTimeFormat().resolvedOptions().timeZone. Compare it with the IP geolocation.
5. Check language settings. Read the Accept-Language header and compare it with the IP country and browser language.
6. Measure latency. Send a lightweight request and time the response. If the round-trip time is far too high for the geolocation, add the latency mismatch.
7. Inspect headers. Look for unusual user agents, HTTP protocol mismatches, duplicate forwarded headers, or unexpected cache headers.
8. Check DNS routing. Compare the DNS resolver used by the client with the IP location. A different country or network is a red flag.
9. Combine all signals. Add weights and produce a confidence score. Then decide whether to allow, flag, challenge, or block.

Limitations and When to Block vs Flag

No detection method is 100% accurate. A sophisticated VPN can block WebRTC, match timezone and language, and use a clean residential IP. It may still leave traces in TCP TTL, DNS routing, or latency. But a determined attacker can reduce those traces too.

You also need to think about legitimate VPN users. A person may use a VPN to protect their privacy while doing normal banking or shopping. Blocking all VPN users can harm conversions. The correct policy depends on your goal.

For security-first sites, block high-risk actions after a strong confidence signal. For media sites, flag the visitor and show a captcha only if they try a restricted action. For advertising, do not block. Log the visitor, preserve the click ID, and use the evidence to request a refund from Google or Meta.

BotRefund uses this approach. It proves bot clicks and then negotiates directly with Google and Meta to recover wasted spend. Detection is the beginning. The end goal is protecting budget and conversion data.

Frequently Asked Questions

Can residential proxies be detected?

Yes, but not by IP reputation alone. Residential proxies use real home IP addresses. You need to look at WebRTC leaks, DNS routing, TCP TTL, latency, and behavior. A residential proxy can still leave a mismatch in network paths.

Should VPN users always be blocked?

No. Many VPN users are legitimate visitors who care about privacy. Blocking them can hurt your conversions. Use a risk score. Block only when the action is high risk and the proxy signal is strong.

Can a VPN hide itself from all detection methods?

Advanced VPNs can hide more signals than basic ones. They can disable WebRTC, match timezones, and use clean IPs. But they often leave traces in latency, DNS routing, or TCP headers. No VPN is invisible to every multi-signal check.

Is it legal to detect proxies and VPNs?

Yes, in most jurisdictions detection and blocking are legal for security, fraud prevention, or licensing reasons. Privacy laws like GDPR may require you to disclose what data you collect and why. Keep your detection data limited to what you need.

What is the simplest way to check for a proxy?

The simplest check is an IP reputation lookup against a proxy or VPN database. Many APIs offer this in one request. But this method misses residential proxies and modern VPNs. Use it as a first pass, not the final decision.

Do I need to install software to detect VPNs?

No. You can detect many proxy signals with client-side JavaScript and server-side checks. Services like BotRefund provide a script that handles the full signal collection and scoring.

What should I do after detecting a proxy or VPN?

It depends on your goal. For ad fraud, record the visitor and mark the click as invalid. For account security, require extra verification. For geo-restricted content, block access. In every case, base your action on the confidence score, not one signal.