What an IP lookup can say about VPNs

An IP address names the last network hop of a connection. If a person routes traffic through a relay, the address you see belongs to the relay. A lookup can tell you who runs that network and whether the range is published as belonging to a known service. It cannot tell you why the connection was relayed, or whether the person behind it means harm.

Two cases are easy to spot because the operators publish the data. Cloud providers publish their address ranges so customers can filter traffic; Amazon, for one, says its file is for identifying traffic from AWS, covers only services customers commonly use for egress filtering, and leaves out ranges customers bring to AWS themselves ¹. The Tor Project publishes a list of exit relays ². Everything else, such as a commercial VPN that rents ordinary data center space or a proxy running on a home connection, shows up only if someone has catalogued it.

The ip product has no proxy or VPN verdict. It returns facts that bear on the question, taken from open data:

The score is simple arithmetic: a Tor exit adds 70 points and an address in a hosting range adds 25, so the possible values are 0, 25, 70 and 95. Each factor appears in risk_factors with its points and a description, so you can see exactly why a number came out as it did.

1curl -X POST https://YOUR_API_HOST/v1/ip \
2  -H "Authorization: Bearer $LOOKVALID_API_KEY" \
3  -H "Content-Type: application/json" \
4  -d '{"ip":"8.8.8.8"}'

Private, loopback and carrier-grade NAT ranges are not public addresses, so the product answers with an invalid-input error for them. A public address that none of the datasets cover returns not found, which is different from a clean result.

• Residential and mobile proxies. Traffic leaves from a home or phone connection, so the address looks like any subscriber and no hosting or Tor flag appears.
• Shared addresses. Carrier-grade NAT puts many subscribers behind one public address, and geolocation systems then identify the NAT server rather than the end host ³. A flag on such an address says little about one person.
• Lists lag. Providers change their ranges, and a published file only covers what the provider chooses to publish ¹. Tor exit lists change as relays come and go ².
• Location is a hint. Operators who publish location feeds say consumers may treat the data as a hint only and that errors occur at many levels ⁴.

Treat a flag as evidence that raises a question, not a ruling. Blocking an exit relay address affects every person routed through it, including people who did nothing wrong ².

• Do not make is_hosting alone a reason to refuse an account. Add a step instead, such as an email confirmation or a short wait before a first action.
• Read is_tor and is_hosting together with signals that do not depend on the address, such as the billing country, the email domain and how fast the form was filled in.
• Never read a null is_vpn as a pass. If your policy needs VPN status, plan for a second source and keep the null as unknown in your own records.
• Log the whole risk_factors list with the decision so you can review misfires later.
• Offer a way through. A legitimate user on a corporate or privacy network should be able to continue after one extra check.

To wire the lookup into a server, see check an IP in Express middleware. For what a location can and cannot tell you, read how accurate IP geolocation is. You can try one address in the free IP address lookup.