IP Geolocation Is Wrong — Why VPN Detection Fails 90% Of Us

security, #api, #cybersecurity, #webdev Last Tuesday, a paying customer in Austin couldn't finish checkout. Our fraud engine had flagged her IP as a "high-risk VPN." She was on Spectrum. At home. Watching Netflix on the same connection. The blacklist we paid $400 a month for had her entire /24 range marked as "datacenter" because a hosting company once leased part of that range three years ago, and nobody had bothered to refresh the entry. That single false positive cost us a $2,100 annual contract. It also exposed something uglier: most VPN detection is astrology with better marketing. Our tools struggle to separate a Tor exit node from a corporate VPN, a residential proxy, or a phone tethering through a coffee shop. We dump them all in one bucket labeled "risky" and move on. Why geolocation alone is a broken fraud signal IP geolocation databases are snapshots. They map an address to a city, an ISP, maybe an ASN. That works for CDNs and weather widgets. For fraud prevention, it is not enough. A fraudster in Lagos can rent a clean residential IP in Ohio for $3 an hour. The geolocation says Ohio. The transaction looks normal, and the merchant loses the chargeback. Traditional checks ask two questions: where is this IP, and is it on a blacklist? By the time you read the answers, they are often stale. Worse, blacklists decay. IPs rotate. A "VPN" range last month is a family on fiber this month. A "clean" range today is a compromised IoT botnet tonight. Static databases are fighting a dynamic war, and we're bringing a phone book to a knife fight. I learned this the hard way running payments for a small SaaS. We blocked entire countries because chargeback rates spiked. Then legitimate users in those countries signed up with stolen US cards, and our real US customers got blocked on mobile hotspots. Every filter we added just created a new way to insult a real customer. What worked was richer context, not a bigger blacklist. What a modern IP check should actually look like A useful IP API doesn't stop at "where," because location is the easy part. It should tell you what the IP is, what else lives on it, and how it has behaved. At minimum, that means: Reverse-IP discovery: domains hosted on the same address, because fraud infrastructure reuses IPs while residential users don't VPN/proxy/Tor flags built from live behavior, not stale lists Country metadata for routing, pricing, and compliance decisions Most services give you one. A few give you two, typically behind a paywall. Getting all three in a single call without an enterprise invoice is rare. I started testing the IP Geolocation API after the Austin false positive. Its reverse-IP layer pulls from crt.sh certificate transparency logs, PTR records, and HackerTarget passive DNS. Those three signals triangulate whether an IP is shared infrastructure or a single residential endpoint. A fraud IP hosting forty phishing domains lights up immediately. A grandma in Austin does not. The code: one request, three fraud signals Here's the helper I built. It takes an IP and returns geolocation, reverse-IP data, VPN/proxy/Tor flags, and country metadata. import os import requests RAPIDAPI_KEY = os.getenv("RAPIDAPI_KEY") BASE_URL = "https://ip-geolocation44.p.rapidapi.com" def check_ip(ip: str) -> dict: headers = { "X-RapidAPI-Key": RAPIDAPI_KEY, "X-RapidAPI-Host": "ip-geolocation44.p.rapidapi.com" } url = f"{BASE_URL}/ip/{ip}" resp = requests.get(url, headers=headers, timeout=10) resp.raise_for_status() return resp.json() def batch_check(ips: list[str]) -> dict: if len(ips) > 100: raise ValueError("batch limit is 100 IPs per request") headers = { "X-RapidAPI-Key": RAPIDAPI_KEY, "X-RapidAPI-Host": "ip-geolocation44.p.rapidapi.com", "Content-Type": "application/json" } resp = requests.post( f"{BASE_URL}/batch", headers=headers, json={"ips": ips}, timeout=30 ) resp.raise_for_status() return resp.json() The response shape matters. You get location, isp, asn, security with VPN/proxy/Tor booleans, reverse_ip with domains, and country with currency, calling code, languages, and flag in one JSON document. That beats stitching six services together. Every extra integration is a place where latency, stale data, or mismatched schemas can turn a normal customer into a fraud case. Where the old approach breaks I compared our legacy geolocation service against the IP Geolocation API using a sample of flagged IPs from our logs. The legacy tool loved to overcall. It flagged mobile carriers, university dorms, and shared office egress points as "high-risk VPN" because their IP ranges appeared on old blacklists. The new approach was quieter but sharper. It caught Tor exit nodes, known residential proxy services, and hosting providers running anonymized exit infrastructure. The edge came from combining certificate transparency logs with live hosting behavior. A blacklist can't see that an IP is hosting forty VPN landing pages, but reverse-IP can. That old blacklist cost us real money beyond the subscription fee. Every false positive became a support ticket. Some turned into delayed checkouts. A few turned into customers wondering if our platform was worth the friction. Professional fraud doesn't use NordVPN. It uses bespoke residential proxies and infected routers that geolocate exactly where you expect legitimate users to be. A simple "is this a VPN?" boolean misses both the real threat and the innocent user. The UK anonymity angle nobody is talking about The UK wants platforms to verify identity and strip anonymity. That pressure is crossing the Atlantic. American fraud teams are already being asked to "do more" with IP and device signals. There is a trap in that pressure. If you build KYC that treats every VPN as suspicious, you punish journalists, abuse survivors, remote workers, and anyone on a hospital network. You also miss the real threat, because the scariest actors don't show up as VPNs at all. Stop asking "is this a VPN?" Start asking "does this IP's behavior match its claimed identity?" That requires more than a boolean flag. You need the full picture, not a label. The edge case that almost fooled me I almost shipped a rule that auto-blocked any IP with more than five reverse-IP domains. It seemed logical. Shared hosting equals suspicious. Then I tested our own office IP. Twelve domains. Our marketing site, docs subdomain, staging environment, three customer demo instances, and a handful of old landing pages. We looked like a fraud farm. I killed the rule before it reached production. A pure detection score would have missed that. You need the raw data, not just a verdict, and the API returns both. How to use IP Geolocation API Sign up at https://rapidapi.com/On13uka/api/ip-geolocation44 and grab a key. The free tier covers prototyping. curl example: curl -X GET "https://ip-geolocation44.p.rapidapi.com/ip/8.8.8.8" \ -H "X-RapidAPI-Key: YOUR_RAPIDAPI_KEY" \ -H "X-RapidAPI-Host: ip-geolocation44.p.rapidapi.com" Python example with real error handling: import os import requests def geolocate(ip: str) -> dict: key = os.getenv("RAPIDAPI_KEY") if not key: raise RuntimeError("RAPIDAPI_KEY not set") headers = { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "ip-geolocation44.p.rapidapi.com" } response = requests.get( f"https://ip-geolocation44.p.rapidapi.com/ip/{ip}", headers=headers, timeout=10 ) response.raise_for_status() data = response.json() # Surface the signals that matter for fraud decisions security = data.get("security", {}) reverse = data.get("reverse_ip", []) country = data.get("country", {}) return { "is_vpn": security.get("vpn", False), "is_proxy": security.get("proxy", False), "is_tor": security.get("tor", False), "domains_on_ip": len(reverse), "country_code": country.get("code"), "currency": country.get("currency") } For bulk checks, use the POST /batch endpoint. It accepts up to 100 IPs per request. That's the difference between hammering an API 10,000 times and making 100 calls. Your rate limit and your wallet both notice. The GitHub repo has more examples and a Postman collection: https://github.com/On13uka/ip-geolocation-api. What I'll do differently next time Next time, I won't score IP reputation in isolation. I'll combine reverse-IP density, VPN/proxy/Tor flags, ASN history, and country metadata into one risk model. I'll also log every false positive by hand for a month, because the most expensive mistakes hide in the cases where your API quietly got it wrong. I'm still not sure whether reverse-IP count should be a hard feature or just a soft signal. Our office IP taught me to treat reverse-IP count as a soft signal only. The real win is blocking the right fraud while letting real customers through. That Austin customer should have checked out in thirty seconds. Instead, she called support, waited twelve minutes, and nearly left. Stop trusting IP astrology Most VPN detection is a legacy blacklist sold as machine learning. It overblocks, underprotects, and punishes innocent customers. A better approach is cheaper than you think. One API call gets you geolocation, reverse-IP discovery from three independent sources, VPN/proxy/Tor detection, and country metadata. You stop guessing and start seeing. The source code and more examples are on GitHub at https://github.com/On13uka/ip-geolocation-api. If you're building fraud detection, geo-restricted content, or analytics that respect your users, start with data that doesn't pretend to be magic. How many of your current fraud checks will pass a real customer on a mobile hotspot, a university WiFi, or a small office shared IP?