How to Block VPN, Proxy and Tor Traffic Without Losing Real Customers

This is about refusing anonymised visitors to a website you run. It is a different job from stopping people using VPN software on a network you administer, which is a schools-and-offices problem solved with DNS filtering and packet inspection. If that is what brought you here, this is the wrong page.

Should I block VPN users? The request usually arrives as one instruction — block anonymised traffic — but four separate populations sit inside that phrase. Commercial VPN users, datacenter proxies, residential proxies and Tor exits have almost nothing in common except that none of them shows you a home address. Treating them as one category is why so many sites block their own customers.

This guide separates the four, gives each one a sensible default, explains which one defeats every address-based check you could write, and covers what a blanket block actually costs — including the possibility that your hosting provider is already doing it without telling you.

Author: Robert Harrison OSINT & Network Utility Expert

The request I get is almost never the problem. Somebody says "block VPN users" and what they actually have is fifty fake trial signups a week. That is a registration problem, and a rule on the signup form solves it while leaving every reader alone. Blocking anonymised traffic across the whole site would have solved it too, and cost them a slice of their audience they would never have measured.

My honest position is that a VPN block is the most over-prescribed rule in this whole subject. The people it stops are overwhelmingly ordinary — remote workers, travellers, anyone who reads privacy advice. The ones you actually wanted are on residential proxies that look exactly like home broadband. You are aiming at the wrong crowd, and the crowd you hit does not complain, it just leaves.

What Are You Actually Blocking?

Four different things wearing the same label. A commercial VPN routes one person through a provider's server, while a datacenter proxy routes automation through rented infrastructure. A residential proxy routes traffic through somebody's real home connection, often without that household knowing, and Tor routes through three volunteer relays before exiting from a publicly listed address. Only the last two are meaningfully unusual, and only one of them is genuinely hard to see.

Row three carries the whole problem. The categories you can see easily are the ones full of ordinary people; the category full of the traffic you actually want gone is the one you cannot see at all. If the mechanical differences between these routes are unfamiliar, our comparison of how Tor and a VPN move your traffic differently covers the plumbing.

Before choosing a policy for each, the assumption underneath the request is worth examining.

Are VPN Users a Risk or a Customer Base?

Both, and the ratio is not close. VPN usage growth tells the story: global adoption grew 31% between 2020 and 2024, driven by remote work, travel and ordinary privacy awareness rather than by fraud. Payment platforms are blunt about the consequence: blocking anonymized traffic outright produces false declines and lost revenue, because you will see VPN use from real, paying customers. The fraudsters are in there too, and they are the minority.

There is a worked example of getting this exactly wrong. A US state motor vehicle agency refused a citizen's registration payment because he was on a VPN — after he had entered his date of birth, licence number and the last four digits of his social security number, passed two-factor authentication, and been shown private vehicle records. The block fired at the one moment he was trying to give them money, and after his identity was already established beyond doubt.

Which is why the useful question is never whether to block, but what to do with each of the four.

Which Category Deserves Which Policy?

Match the response to the population, not to the label on it. Commercial VPN traffic is mostly customers, so it deserves ordinary treatment with friction added only where money moves. Datacenter proxies are mostly machines and can take a firmer hand, while Blocking Tor exit nodes outright is rarely worth it, because the population is small enough that a challenge costs nothing. Residential proxies need a different kind of signal entirely, because no address rule reaches them.

Row two overlaps directly with hosting traffic, and the same reasoning applies — our guide to refusing server traffic without losing your integrations covers that side in full. For Tor specifically, the detect-and-challenge approach and the official exit-list method are already documented on our Tor tool page, so treat this as the policy and that as the implementation.

Three of those four rows are straightforward. The third one deserves its own section, because it is the reason none of this works as well as vendors imply.

Can You Detect a Residential Proxy?

Not from the address, no — and this is the limit that shapes every proxy policy. A residential proxy routes through somebody's genuine home connection, so at the network layer it carries a consumer ISP name, a residential classification and an ordinary reputation. It passes a proxy check, a hosting check and a reputation check, because there is nothing wrong with the address. The household whose router is being used usually has no idea.

This is also where header-based detection ends. Reading forwarded headers catches transparent and careless proxies, and it misses clean tunnelled traffic entirely — which is most of what you are worried about. Vendors quoting high detection accuracy are almost always measuring against known commercial exits, the easy category.

What remains is behaviour. Timing, interaction patterns, and whether the client software matches the browser it claims to be all survive an address change, because they describe the session rather than the network. This is where device fingerprinting earns its place: checking whether a client's own signals agree with each other catches things no address list will, and it is the honest endpoint of this topic.

Why Detection Accuracy Figures Flatter Themselves

VPN detection vendors quoting ninety-something percent accuracy are usually measuring against commercial VPN exits, which is the category anyone can identify because the providers publish their ranges. Score the same system against residential proxy traffic and the number collapses, because there is nothing distinctive to score. The headline figure is real; it just answers an easier question than the one you have.

That matters when you are choosing how much to trust a verdict. Any claim to detect VPN traffic reliably is really a claim about one of the four categories, not all of them. A high-confidence proxy flag on a datacenter address is worth acting on. The absence of a flag proves very little, and building a policy that treats "not detected" as "safe" inverts the actual risk — the cleanest-looking sessions are the ones a serious operator paid for.

Detection settled, the more consequential decision is where the rule sits.

Which Action Should the Rule Sit On?

The one you are actually protecting, which is almost never page loads. Most VPN and proxy rules end up in the wrong place for exactly this reason. Nearly every stated reason for blocking anonymised traffic turns out to be about a specific event — a signup, a login, a checkout, a withdrawal. Attaching the rule to that event solves the problem completely while leaving readers untouched, and it is the single highest-value change most sites can make here.

Run the check server-side, on your own machine rather than in the browser where anyone can edit it. Feeding the result into a single combined risk score for an address is easier to tune than a growing pile of separate conditions, and easier to explain to whoever inherits it.

Every row above is cheap to implement. The blanket version is expensive, and the bill arrives somewhere you are not looking.

What Does Blocking Actually Cost You?

Customers you never hear from. A blocked visitor sees an error, assumes the site is broken, and leaves — they do not email support, they do not post about it, and they do not come back tomorrow to check whether you fixed it. Every other cost in this article is visible in a dashboard somewhere. This one is invisible by construction, which is exactly why it goes unmeasured for years.

Support load is the visible half. Blocked customers who do get in touch arrive confused and annoyed, usually at the worst point in the funnel, and every one of them costs staff time to unpick. Travellers meet this constantly, and our roundup for people who work while moving between countries describes the experience from their side of the error page.

None of which means the answer is always no. There is a category where a hard block is correct.

When Is a Hard Block Actually Correct?

When a contract requires it, or when your category carries fraud risk severe enough to change the maths. Licensing agreements for streaming, iGaming and regulated financial products frequently oblige you to refuse anonymised access, and in those cases the block is a compliance control rather than a security one. Ticketing and online gaming sit close behind, because VPN chargebacks in those categories genuinely outweigh the traffic you lose.

Outside those, the calculation inverts. For an ordinary business every refused visitor is a visitor you wanted, and the fraud you prevent is a fraction of the revenue you decline. That is the whole argument, and it is why the same advice keeps appearing from payment platforms rather than from security vendors.

Geography is often the real requirement hiding behind a VPN rule, since licensing terms are usually written about territories rather than about tunnels — and that is a different instrument with a different failure mode, covered in our guide to restricting access by nation and what it costs.

One more consideration belongs in this section. In 2023 a VPN provider's chief executive faced criminal proceedings in Greece after fraudsters routed an attack through one of its servers, a case eventually dismissed in 2025. The episode is a reminder that providers are infrastructure rather than accomplices, and that treating an entire category as hostile is a position with consequences beyond your own traffic.

With the decision made, deployment is a ladder rather than a switch.

How Do You Deploy This Without Breaking Things?

Climb the ladder in order and stop as soon as the problem does, whatever category of proxy traffic prompted it. Allow, log, challenge, add friction, then block — most sites solve their actual complaint on the third rung and never need the fifth. Starting at the top is what produces the outcomes described above, and it is also the version that takes the least work, which is why it happens.

Step three changes more minds than any argument in this article. Teams who expected to find fraud usually find readers, and the rule they were about to write quietly stops making sense.

That is the full picture across all four categories. Here is what to keep.

The Short Version

Stop treating anonymized traffic as one category, because four different populations are hiding inside that phrase. Commercial VPN users are mostly customers and deserve ordinary access with verification only where money moves. Datacenter proxies are mostly machines and can take a challenge, and Tor is small enough that a challenge costs you nothing. Residential proxies are the ones you actually wanted, and no address rule will ever reach them.

Put the rule on the action rather than the visit. Fake signups are a registration problem, credential stuffing is a login problem, and chargebacks are a checkout problem — none of them is a browsing problem. Solving them at the event leaves your readers untouched and takes less work than a site-wide policy.

Reserve hard blocks for licensing obligations and genuinely high-chargeback categories. Everywhere else, the visitors you refuse do not complain, they simply disappear, and that cost never shows up in any dashboard you own. Test your own site through a VPN before you start, and choose the layer deliberately — our guide to where a blocking rule belongs works through that decision in full.