How to detect VPN, proxy and Tor traffic, and what to do about it.

A VPN detection API classifies the network address a request arrives from, so you can tell an ordinary connection from a VPN, a proxy, a Tor exit or a hosting network. The practical way to use it is to record the classification on every request, weigh it with other evidence, and reserve blocking for the cases where the network genuinely changes the answer.

This how-to covers what proxy detection and Tor detection can tell you, how Fingerly reports them, and how to build them into a decision without punishing the many people who use these networks for good reasons.

#What can IP intelligence tell you about a connection?

It tells you what kind of network the request came from, and whether that agrees with where the device says it is. The address is the one thing a visitor cannot edit in their own browser, which makes it a useful piece of evidence even when everything else is disguised.

On every identification, Fingerly classifies the address as a commercial VPN, a datacenter proxy, a residential proxy, a Tor exit node, a hosting network with no proxy or VPN label, or an address with a recorded history of abuse. It also reports a location mismatch when the device’s own region disagrees with the address’s country, and, in native apps, a VPN tunnelled over mobile data.

#How are VPNs, proxies and Tor different?

They are different routes with different meanings, so they deserve separate buckets rather than one “bad traffic” label.

• A commercial VPN is a known VPN endpoint. People use them for privacy, work and travel.
• A datacenter proxy runs on a hosting network. It is a stronger sign of automation, because real customers rarely browse from a server.
• A residential proxy runs on a consumer connection and is the hardest kind to tell from a real visitor, so it is weighted more cautiously.
• A Tor exit node is a known exit of the Tor network, and Fingerly reports it at high confidence.

The shipped default weights reflect that. A Tor exit scores 14 on the web and 16 or 17 in apps, a datacenter proxy 14, 12 or 15, and a commercial VPN only 4 or 5. The default high-risk threshold is 30 and medium begins at half of it, so a VPN alone keeps a score low, while a Tor exit alone sits just under medium on the web and at medium in apps.

#Should you block VPN traffic?

Usually not. A VPN is a reason to look, not a verdict. People use VPNs to protect their privacy, to reach a company network, or while travelling, and offices, campuses and mobile carriers put many real people behind one address. A connection indicator tells you nothing about why someone chose it.

What makes a VPN meaningful is company. A tunnelled connection beside automation, a modified browser or repeated incentive claims reads very differently from one beside a long-standing account on a familiar device. Weight network signals as context and combine them with device signals.

#How do you add network checks to a flow?

• Identify at the moment that matters, such as login, checkout or sending a one-time code, with a tag for that action.
• Send the request ID to your server and read the stored event with a secret key. The event lists which network groups fired, such as a VPN or a Tor exit, with their weights.
• Decide on your server. The browser or app is never told which signals fired, and the score it receives is a hint, not a decision.
• Set the weights per platform to what each network is worth to you, and zero out any signal you want to record but ignore.
• Log the decisions for a week or two before you enforce anything.

VPN and residential proxy findings can be weighted in two ways: separately for each detection method, or as one signal priced by how sure the detection is. Only one mode applies at a time, so a finding is never counted twice.

#What happens when the network lookup fails?

The response says so, and it never passes a guess off as a clean result. If the address cannot be looked up, the identification is still returned, marked unavailable with a short reason, and it carries no suspect score at all rather than a lower one computed from less.

Decide in advance what an unscored request means for each action. You might allow it for a newsletter signup, review it for a payout and refuse it for a withdrawal. A missing score must never be read as clean. Likewise, a device that reports no region, or an address with no known country, never produces a location mismatch.

#Where does network context change the answer?

• Account takeover: a known password from a Tor exit or a datacenter proxy, on a device the account has never used, deserves a second factor. The same login from a phone on mobile data does not.
• One-time passcodes: scripts that trigger text messages usually run from hosting networks, so check the session before the code is sent.
• Payments: a network country that differs from the billing country, or an anonymising network, is a reason to authenticate the cardholder, not to refuse the order.
• Account sharing: a location mismatch with many devices on one subscription is a better reason to offer a family plan than a block.