Fraud through VPNs, proxies, and Tor is growing. Bad actors use these tools to create fake accounts, commit payment fraud, and scrape content while hiding their identity. Detecting these connections is essential for protecting signups, payments, and content.
This guide explains how VPN detection works and what to consider when implementing it.
How VPN Detection Works
VPN detection identifies whether an IP address belongs to a VPN provider, proxy server, Tor exit node, or datacenter. When a user connects to your application, you check their IP against known anonymization services.
Detection typically covers commercial VPNs (NordVPN, ExpressVPN), proxy servers (HTTP, SOCKS), Tor exit nodes, and datacenter IPs (AWS, GCP, Azure). More sophisticated detection also provides risk scores from 0-100 with recommendations on whether to allow, verify, or block the request.
Common use cases include preventing fake account signups, adding friction to high-risk payment attempts, enforcing geographic content restrictions, and identifying bot traffic from datacenter IPs.
Implementation Options
You can build detection in-house using IP blocklists, or integrate with a detection API. Here is how the two approaches compare:
| Factor | In-House | API |
|---|---|---|
| Accuracy | 60-80% | 99%+ |
| Maintenance | Weekly updates needed | None |
| Coverage | Known providers only | VPN, proxy, Tor, datacenter |
| Risk Scoring | Yes/No only | 0-100 scale |
| Response Time | Varies | Under 50ms |
| Setup Time | Days to weeks | Under 1 hour |
| Annual Cost | $30K+ in engineering | $350-$3,600 |
| Dependencies | None | External service |
Maintenance Considerations
VPN providers add hundreds of new IP addresses every week. NordVPN alone runs thousands of servers across 60+ countries. Any blocklist-based approach requires regular updates to stay effective.
Outdated lists create two problems. False positives block legitimate users, which costs $15-25 per support ticket to resolve. False negatives let fraudsters through because they actively seek providers not on common blocklists.
Engineering time adds up. Four hours per week on maintenance equals 200+ hours per year. At typical engineering costs, that represents $30,000 or more annually.
Integration Example
Here is how a typical API integration looks:
const response = await fetch('https://api.vpnsignal.io/v1/check', {
method: 'POST',
headers: {
'Authorization': 'Bearer YOUR_API_KEY',
'Content-Type': 'application/json'
},
body: JSON.stringify({ ip: '8.8.8.8' })
});
const result = await response.json();
if (result.recommendation === 'block') {
requirePhoneVerification();
} else if (result.recommendation === 'verify') {
requireCaptcha();
} else {
allowAccess();
}The response includes detection flags (VPN, proxy, Tor, datacenter) and a risk score. This lets you make nuanced decisions based on your risk tolerance rather than binary allow/block choices.
Choosing the Right Approach
In-house detection works well for low-traffic applications or when you only need to detect specific providers. It gives you full control with no external dependencies.
An API makes sense when accuracy matters, you want to minimize engineering overhead, or you need features like risk scoring. The tradeoff is adding an external dependency, which you can mitigate with response caching.
For most production applications handling signups, payments, or sensitive content, the total cost of ownership favors using a dedicated service. You can try VPN Signal free to see how it works for your use case.