Every fraud, abuse, and compliance team eventually asks the same question: is this IP address hiding something? The honest answer is that no single check can tell you. A commercial VPN, a datacenter SOCKS proxy, a residential proxy rented from a botnet, and a Tor exit node all look different on the wire — and each one defeats a different naive detection method.
This guide walks through the eight signal layers that production-grade detection systems draw on — GeoIPHub builds its own verdicts from seven verification method families that cover this same ground — what each layer can and cannot see, and how the results get merged into the response fields you actually use: is_vpn, is_proxy, is_residential_proxy, and is_tor.
Layer 1: Provider Server Lists
The most reliable evidence is the most direct: VPN providers publish their server infrastructure. Apps need endpoint lists to connect, and many providers expose official APIs or config bundles listing every server hostname and IP.
Detection systems continuously crawl these sources. When an IP appears in NordVPN's or Mullvad's published server list, the verdict is not an inference — it is attribution. This is why a good API can return not just is_vpn: true but the provider name itself.
The limitation is coverage. Published lists only catch providers that publish, which means this layer is strongest for the large commercial VPNs that account for most consumer VPN traffic, and weakest for private or self-hosted VPNs.
Layer 2: ASN and Hosting Infrastructure
Every IP belongs to an Autonomous System (AS) — the network that announces it to the internet. The ASN tells you who operates the network, and that is a powerful prior:
- An IP announced by AS396982 (Google Cloud) is almost certainly a server, not a person on a couch.
- An IP announced by a residential ISP (Comcast, Deutsche Telekom, Jio) is probably an eyeball connection.
- A long-haul hosting or colocation ASN with a history of VPN endpoints raises the prior for every IP in its ranges.
Datacenter detection alone catches a huge share of VPNs and proxies, because most anonymizing infrastructure rents cloud servers. But it cannot distinguish a VPN endpoint from an ordinary web server — that requires the next layer.
Layer 3: Active Protocol Probing
This is the layer most lookup databases skip, and it is the difference between guessing and verifying. A VPN server has to answer VPN protocol handshakes — that is its job. So a detection system can knock on the door and see who answers:
- OpenVPN responds to a characteristic TLS or UDP handshake on its listening port.
- WireGuard answers a Noise-protocol initiation message.
- IKEv2/IPsec responds on UDP 500/4500 with identifiable payloads.
- SOCKS5 and HTTP proxies complete their respective greeting sequences.
If an IP completes an OpenVPN handshake, it is running OpenVPN — no statistical inference required. GeoIPHub probes across 11 protocols and records exactly which handshake succeeded, so the evidence behind is_vpn is named and auditable.
curl "https://api.geoiphub.com/v1/lookup?ip=185.220.101.34" \
-H "Authorization: Bearer YOUR_API_KEY"
{
"ip": "185.220.101.34",
"country": "DE",
"city": "Frankfurt am Main",
"asn": 60729,
"asn_org": "Zwiebelfreunde e.V.",
"is_datacenter": true,
"is_vpn": false,
"is_proxy": false,
"is_residential_proxy": false,
"is_tor": true,
"detection_methods": ["tor_exit_directory", "asn_hosting_profile"],
"risk_score": 88
}
Active probing has one cost: it takes infrastructure and time, which is why it runs continuously in the background rather than per-request. The probe results are cached and refreshed so the API can answer in milliseconds.
Layer 4: Port and Service Fingerprints
Even when a full handshake is not possible, the shape of an IP's open services is informative. A residential connection typically exposes nothing. A VPN endpoint exposes a small, characteristic set of ports. A proxy farm exposes management panels, SSH, and proxy ports across whole subnets.
Service fingerprinting also catches misconfigured or unbranded anonymizers: a server answering on TCP 1080 with a SOCKS banner is a proxy regardless of whether any list says so.
Layer 5: Latency and Location Consistency
Geography leaves fingerprints in physics. If an IP claims (via registration data) to be in São Paulo but its round-trip times from global vantage points triangulate to Amsterdam, something is relaying traffic. Latency-based checks are especially useful against:
- Geo-spoofed VPN servers — providers marketing "Brazil" servers that physically sit in Miami.
- GRE/tunnel relays that forward traffic to a hidden real location.
This layer rarely fires alone, but it is a strong corroborator when combined with hosting signals.
Layer 6: Residential Proxy Behavior
Residential proxies are the hardest class, because the exit IP genuinely belongs to a home ISP. List checks pass. ASN checks pass. Probing finds nothing listening, since the "server" is an SDK buried in someone's free mobile app.
Detection therefore shifts from infrastructure to behavior over time:
- The same residential IP appearing as an exit across known proxy marketplaces.
- Improbable session diversity — one household IP presenting dozens of device fingerprints per hour.
- Churn patterns matching proxy-network rotation rather than DHCP renewal.
- ISP-type mismatch: mobile-carrier IPs producing sustained datacenter-style request volumes.
This is why is_residential_proxy is a separate field from is_proxy — the evidence class is different, and so is the appropriate action. A residential proxy hit on a checkout flow is a much stronger fraud signal than a consumer VPN hit.
Layer 7: Tor Directory Data
Tor is the easy one — by design. The Tor network publishes its consensus of relays and exit nodes, refreshed continually. Cross-referencing the public exit list yields near-perfect is_tor accuracy with one caveat: timing. Exit nodes join and leave, so the directory needs to be re-ingested on a tight schedule, not weekly.
Layer 8: Cross-Signal Confidence
The final layer is the merge. Each preceding layer produces evidence with a different reliability profile:
| Signal layer | Catches | Confidence when it fires | Blind spot |
|---|---|---|---|
| Provider lists | Commercial VPNs | Very high (attributed) | Private VPNs |
| ASN / hosting | Datacenter anonymizers | Medium (prior, not proof) | Residential exits |
| Active probing | Live VPN/proxy daemons | Very high (verified) | SDK-based proxies |
| Port fingerprints | Unbranded proxies | High | Firewalled endpoints |
| Latency checks | Geo-spoofing relays | Medium | Nearby relays |
| Behavioral models | Residential proxies | Medium-high | Brand-new IPs |
| Tor directory | Exit nodes | Near-certain | Bridges |
A defensible verdict weighs these together. One medium-confidence signal should not flip a boolean; two independent high-confidence signals should. The output you want from a detection API is therefore three things: the booleans for routing decisions, the named detection methods for auditability, and a risk score that expresses how much the signals corroborate.
What This Means for Your Integration
Three practical takeaways:
- Do not treat
is_vpnas a block list by itself. Plenty of paying customers use consumer VPNs. Route on combinations: VPN + datacenter + abuse history is a very different situation from VPN alone. - Weight
is_residential_proxyheavily. Nobody rents residential exits for privacy; the legitimate-use base rate is tiny compared to VPNs. - Prefer verified detection over static lists. Ask any vendor how they know an IP is a VPN. If the answer is "a database we license," the data is already decaying. Active probing and continuously crawled provider lists keep pace with infrastructure churn.
You can see every layer's output yourself — run any IP through the free IP lookup tool or test your own VPN connection, no signup required.
Start Scoring Every IP in Real Time
GeoIPHub gives fraud, security, and engineering teams a single API for IP geolocation, VPN & proxy detection, threat intelligence, and an explainable 0–100 risk score.
Get Your Free API Key
Sign up in minutes — no credit card required. Upgrade only when you need more volume.
Frequently Asked Questions
Can VPN detection ever be 100% accurate?
No. Detection is probabilistic. Commercial VPNs with published infrastructure are detected with very high confidence, while small private VPNs on fresh cloud IPs are harder. That is why good APIs return per-signal evidence and a confidence level instead of a bare boolean.
What is the difference between a proxy and a VPN at the detection level?
A VPN tunnels all traffic at the network layer and usually answers specific protocol handshakes (OpenVPN, WireGuard, IKEv2) on its server. A proxy relays application-level traffic (HTTP, SOCKS) and exposes different ports and fingerprints. Detection systems probe for both families separately.
Why are residential proxies so hard to detect?
Because the exit IP genuinely belongs to a home ISP, list-based and ASN-based checks pass. Detection relies on behavioral evidence instead: the same IP appearing in proxy networks, abnormal reuse patterns, and mismatches between the ISP type and the observed traffic.
Does blocking every VPN user make sense for fraud prevention?
Usually not. Many legitimate users browse through VPNs for privacy. A better pattern is to treat VPN use as one weighted input to a risk score and only escalate when it co-occurs with other signals such as datacenter hosting, abuse history, or impossible travel.
How fresh does VPN detection data need to be?
Very fresh. VPN providers rotate servers daily and proxy networks churn IPs by the hour. Detection backed by continuous re-probing and re-crawled provider lists stays accurate; static datasets decay within weeks.