You tried to open a website, sign up for something, or place an order, and got shown a wall instead: *access via proxy/VPN/Tor is not permitted*, or *VPN detected*, or *we don't allow anonymous connections*. You are not using a VPN. You have never used a VPN. You are sitting at home on the same broadband you have had for six years.

The site is not lying to you, and you are not doing anything wrong. Both things are true at once, and the reason is that the message is describing something much narrower than it sounds.

TL;DR

• "VPN detected" is a statement about your IP address, not about your device. The site cannot see what software you run. It looked up the address you arrived on and found something in that address's profile it didn't like.
• The most common innocent cause is your ISP's own network classification. Large providers sell broadband *and* server hosting, often out of neighbouring address space under the same autonomous system, so the whole network gets labelled as both.
• We measured it: 4,532 of 92,518 analysed addresses (4.9%) sit on a network flagged hosting *and* residential at the same time — about one visitor in twenty.
• Only 71 of 99,737 autonomous systems carry both flags, but those 71 include Comcast, Cox, Verizon, BT, Deutsche Telekom, Vodafone, Korea Telecom and Reliance Jio.
• Sometimes the detection is right and you don't know it — proxyware bundled into a free VPN app or a "passive income" app turns your connection into a genuine residential proxy exit.
• The failure is systematic, not random. It concentrates on the largest consumer ISPs, which is why it survives so long before anyone notices it.

What the site actually saw

When you connect to a website, roughly one useful thing about you crosses the network before any page loads: your IP address. Everything a site claims to know about your connection in that first instant is derived from that number.

So the site did a lookup. That lookup returns things like which organisation the address is registered to, which autonomous system (AS) it belongs to, roughly where it is, and whether the address appears in lists of known VPN endpoints, proxy servers, Tor exit nodes or datacenter ranges.

Then a rule fired. And here is the important part: most of those rules are probabilistic, but almost all of the messages they produce are phrased as certainties. "VPN detected" usually means "this address has properties commonly associated with VPNs". Those are very different claims, and the gap between them is where you are standing right now.

Cause 1: your ISP is classified as a hosting provider (the big one)

This is the cause almost nobody outside the industry knows about, and in our data it is the largest single source of this false positive.

Autonomous systems are the large chunks the internet is divided into for routing — your ISP has one or more, identified by a number like AS2856. Detection vendors attach metadata to these: is this network a consumer ISP? A mobile carrier? A hosting company? A cloud provider?

The trouble is that a lot of big telecoms companies are all of those things at once. British Telecom sells home broadband and business hosting. Comcast and Cox sell you internet and also run commercial infrastructure. Deutsche Telekom operates consumer DSL and a cloud division. When the address ranges intermingle under one AS number, the network ends up flagged as hosting *and* residential simultaneously — and a naive rule that says "hosting means server means bot" now fires on every ordinary household on that network.

We measured how much of the real world this covers. Across 92,518 analysed addresses with network data:

Seventy-one networks out of nearly a hundred thousand — 0.07% — account for one visitor in twenty. That is not a coincidence. The dual-flagged networks are disproportionately the largest consumer ISPs on earth. These are the ones we see the most traffic from:

Comcast, Rogers, CenturyLink, Tele2, Starhub, SoftBank and Orange sit on the same list further down. If your provider appears here and a site told you that you were on a VPN, this is very probably why — and there is nothing wrong with your connection at all.

Why this failure is systematic rather than random

The important property of this false positive is that it is not evenly spread. It concentrates precisely on the networks with the most ordinary people on them.

A detection system that treats these labels as independent facts — *this network is hosting, therefore addresses on it are infrastructure* — produces a result that looks reasonable in testing and is badly wrong in production. It will pass every test written against a pure hosting provider like a cloud vendor, and against a pure consumer ISP. It only fails on the overlap, and the overlap happens to contain a large share of the residential internet.

That is why this kind of mistake tends to survive for a long time before anyone notices. It does not produce obvious errors. It produces a slow, invisible tax on exactly the visitors a site most wants to keep — and the affected people rarely report it, because from their side the site simply didn't work.

We wrote about the broader version of this problem in the real cost of blocking real customers and in ASN-based blocking explained.

Cause 2: you are sharing one address with hundreds of strangers

Under carrier-grade NAT (CGNAT), your ISP gives many households a single public address and multiplexes everyone's connections through it. This is standard on most mobile networks and increasingly common on fixed-line broadband, because IPv4 addresses ran out.

The consequence is unavoidable: you inherit the reputation of everyone else on that address. If one person behind your CGNAT pool ran a scraper, hammered a login form or sent spam, the address accumulates a bad reputation and everybody sharing it arrives pre-judged. Your own behaviour has no bearing on the outcome.

The tell is that the problem follows the network rather than the device. If your phone is blocked on mobile data but fine on home Wi-Fi, and your laptop is blocked on that same mobile hotspot, the address is the common factor, not the machine.

Cause 3: the address had a previous life

Addresses get reassigned. A block that hosted a VPN provider two years ago can be returned, resold and issued to a residential ISP — and the old classification can linger in databases built when that block genuinely was VPN infrastructure.

Detection feeds decay at very different speeds. Some are refreshed daily; others carry entries that have been stale for years. If a site is using a cheap or infrequently updated list, you can be flagged today for something that stopped being true long before you got the address.

This is also why "how do I get my IP unflagged?" has such an unsatisfying answer: there is no central registry. Every vendor keeps its own data, so there is no single place to appeal.

Cause 4: something on your network really is a proxy

This one is uncomfortable, and it is worth ruling out honestly, because when it applies the detection is simply correct.

There is an entire industry built on renting out residential connections. It reaches your network through:

• "Passive income" apps that pay you a small amount to share bandwidth. Sharing bandwidth is precisely the product: strangers' traffic exits through your connection.
• Free VPN apps, some of which fund themselves by enrolling their users as exit nodes for other users.
• Bundled SDKs inside otherwise ordinary free apps, where proxy participation is buried in the terms.
• Browser extensions offering free unblocking of geo-restricted content.

If any of these are running on any device in your household — a phone, a smart TV, a child's tablet — then your address genuinely is a residential proxy exit, and sites detecting it are not making a mistake. We covered the mechanics of that market in residential vs datacenter proxies.

Check every device, not just the obvious one. This is the only cause on this list you can fix directly and permanently.

Cause 5: you are using something you don't think of as a VPN

Several ordinary things route your traffic through infrastructure that looks exactly like a VPN to a detector:

• iCloud Private Relay on Apple devices, on by default for iCloud+ subscribers, egressing from partner networks in datacenter address space.
• Cloudflare WARP / 1.1.1.1 with WARP, often installed for the DNS and then left on.
• Corporate VPNs that stay connected in the background, especially on work laptops used at home.
• Antivirus and "security" suites that bundle a VPN or web-shield proxy and enable it quietly.
• Browser built-ins, such as Opera's free VPN or certain privacy-focused browser modes.

None of these feel like "using a VPN" to the person using them, but they change your egress address, and detectors act on the egress address. We wrote about how these specific services should be handled in Apple Private Relay and Cloudflare WARP detection — the short version is that treating them as fraud signals is a mistake, since their users skew towards paying customers on premium devices.

How to work out which one applies to you

Run these in order. It takes about three minutes.

1. Look up your own address. Check what the internet actually reports about your connection, including which AS you are on and which flags it carries. If your provider appears in the table above, you have your answer.
2. Switch networks. Try the same site on mobile data with Wi-Fi off, then on Wi-Fi with mobile data off. If one works and the other doesn't, the address is the problem, not your device.
3. Try a different device on the same network. If everything on your network is blocked, it is the address. If one device is blocked, look at that device's software.
4. Audit for proxyware. On every device, look for free VPNs, bandwidth-sharing apps and unfamiliar extensions. Remove them, then re-test.
5. Check for a silent VPN. Look at your VPN settings, your antivirus dashboard, and — on Apple devices — whether iCloud Private Relay is switched on.
6. Restart your router. Some ISPs will issue a new dynamic address; many will hand back the same lease. It costs a minute and occasionally solves it outright.

What you can actually do about it

If you have ruled out proxyware and a hidden VPN, your options are genuinely limited, and it is better to say so than to pretend otherwise.

• Contact the site. This is the highest-value action and the one people skip. The site owner is the only party who can let you in, most have no idea their rules are catching customers, and a specific report — "your site blocks me, my IP is X, I'm a Vodafone customer in Berlin" — often gets acted on quickly. It is a lost sale for them, not merely an inconvenience for you.
• Ask your ISP for a different address. Some will reassign on request; business lines sometimes offer a static address that can then be reviewed.
• Do not "fix" it with a VPN. It is the intuitive move and it usually makes things worse: commercial VPN endpoints are the single most reliably detected category of address there is. You would be swapping an ambiguous address for an unambiguous one.

If you run a website, this is the part that matters

Every one of these blocks is a person who wanted to give you money or attention and was turned away by a rule you probably enabled by accident. Two numbers from our own production data are worth sitting with:

• 30.7% of 99,939 observed addresses carry a datacenter flag.
• 1.1% score at or above a typical block threshold.

If you block on the datacenter or hosting flag alone, you are rejecting up to thirty percent of the internet to stop roughly one percent of it. That trade is almost never worth making, and the people it hits hardest are mobile users, people in countries where CGNAT is the norm, and customers of exactly the large ISPs listed above.

Four rules fix most of it:

1. Never treat hosting or datacenter as a verdict. It is one input among several, and it should never be able to reject a visitor on its own. Require at least one behavioural signal before you act on it.
2. Score, don't switch. A weighted risk score with a threshold lets you tune the trade-off. A boolean cannot.
3. Run every new rule in monitor mode first, and read the logs before enforcing. What you catch is rarely what you expected.
4. Log the reason for every block, and print it on the block page. If someone is turned away, they should be able to tell you why, and you should be able to audit it later.

The goal was never to block anonymous traffic. It was to block *abusive* traffic. Those two overlap far less than the marketing around this category suggests — and a rule that cannot tell a Comcast customer from a datacenter is not protecting you from anything.

---

*Predax classifies IP addresses for VPN, proxy, Tor, datacenter and crawler signals and returns a 0–100 risk score with the reasons behind it, so you can set your own threshold instead of accepting somebody else's boolean. You can look up any address to see exactly what we report, including whether its network is one of the dual-flagged ones described above.*