Detecting VPNs, proxies and datacenter traffic

Parneet Singh8 min read

"Is this a VPN?" sounds like one question. It is at least four, they have very different answer qualities, and conflating them is why so much VPN detection is unreliable.

Four different questions

Is this address in a datacenter? Answerable with high confidence. Cloud providers publish their ranges, hosting ASNs are identifiable, and the signal is factual rather than inferred.

Is this a Tor exit node? Answerable with certainty. The Tor Project publishes the exit node list; it is a lookup, not a guess.

Is this a commercial VPN? Answerable with moderate confidence, and only with a commercial feed. Someone has to maintain a list of which addresses belong to which VPN service, and keep it current.

Is this a residential proxy? Barely answerable. The whole product is genuine consumer addresses, which is exactly what they look like.

The confidence drops sharply across that list, and any service that reports one flat "VPN: true" is flattening four very different levels of certainty into one boolean.

What the datacenter signal actually buys

Most VPN traffic terminates in a datacenter, so datacenter detection catches a large share of it as a side effect — without needing to know which VPN.

Two ways to detect it, and you want both:

Published ranges. Seven major providers publish machine-readable lists. Loading them gives exact matches. We measured what this adds over ASN detection alone and the answer surprised us — AWS addresses were missed 15.3% of the time by ASN and keyword matching, because much of AWS's space sits under acquired ASNs with no hosting-related word in the name. The full measurement is here.

ASN and organisation matching. Covers everything that does not publish, which is most of the long tail — regional hosts, colocation, smaller providers.

Ranges first, ASN behind. A range match is proof; a non-match proves nothing.

What the datacenter flag does not mean

This is where most implementations go wrong.

It does not mean VPN. A datacenter address is a server. That includes legitimate API integrations, monitoring, CI pipelines, and anything anyone runs on a cloud instance. If you block all datacenter traffic you will block your own customers' backends.

It does not mean fraud. Plenty of people use a VPN because their employer requires it, or because they are on hostile public wifi, or because they would rather not be tracked. None of that is fraud.

It does not mean bot. Some bots are welcome. Search crawlers come from datacenters.

The flag is one input to a decision, and a decision built on it alone will have a false positive rate you will hear about from real customers.

Residential proxies, and why they defeat this

Residential proxy services route traffic through real consumer connections — sometimes rented with consent, sometimes through devices whose owners have no idea, often via SDKs bundled into free apps.

The exit address is a genuine residential address on a genuine ISP. There is no technical artefact distinguishing it from the household it belongs to, because it is that household.

No IP-based method reliably detects this. Anyone claiming otherwise is selling something. Detection, where it happens at all, comes from behavioural signals — timing, volume, patterns across many requests — not from the address.

Using the signals sensibly

The useful posture is graduated response, not binary blocking:

SignalReasonable response
Tor exit nodeExtra verification for sensitive actions; rarely an outright block
Datacenter addressDifferent rate limit; step-up auth for high-value actions
Known commercial VPNUsually nothing on its own
Nothing flaggedNot evidence of legitimacy

That last row matters. Absence of a flag is weak evidence. A residential proxy looks clean, so treating "no flags" as trustworthy inverts the actual risk.

Reading the response

{
  "privacy": {
    "hosting": true,
    "tor": false
  }
}

Note what is not here: there is no vpn or proxy field, because we do not have a data source that would let us populate one honestly. Commercial VPN detection needs a commercial feed, and we would rather omit the field than ship a guess dressed as a fact.

One implementation detail worth stealing: when a signal has not loaded — the Tor list has not been fetched yet, say — the field is absent rather than false. Absent means unknown. Reporting false for a signal you have not checked is a lie your caller cannot detect.

What actually reduces fraud

IP signals are cheap and worth having. They are not the answer.

The things that move the number are the boring ones: verifying email and phone, device fingerprinting, behavioural analysis, velocity checks, and payment-level signals. IP data is a useful input to those systems and a poor substitute for them.


Every lookup here returns the privacy block alongside location and ASN — see the API documentation. If you want to check addresses in bulk against your own ranges, the IP-in-range checker and bulk lookup are free and need no account.

More on privacy

All posts · RSS