Most IP lookup tools return a location. Modern IP intelligence returns a dossier. This post breaks down the full data surface — what each layer contains, where it comes from, and which decisions it supports.
Layer 1: Geolocation
The foundational layer. Every IP address belongs to a network that is registered in one country, announced from a particular region, and typically used in a particular city. Geolocation data maps IP ranges to physical locations using a combination of registry records (RIPE, ARIN, APNIC, LACNIC, AFRINIC), network topology analysis, and active measurement.
What a geolocation lookup returns:
{
"ip": "91.108.56.1",
"country": "NL",
"country_name": "Netherlands",
"region": "North Holland",
"city": "Amsterdam",
"latitude": 52.374,
"longitude": 4.8897,
"timezone": "Europe/Amsterdam",
"geo_confidence": 0.9
}
Accuracy varies significantly by IP type. Residential ISP IPs are typically accurate to the city level. CDN edge nodes and anycast IPs (like Cloudflare's 1.1.1.1) geolocate to network infrastructure locations, not users. Mobile IPs geolocate accurately to country and region, less reliably to city. VPN IPs geolocate to the VPN server location, not the user's real location — which is the first reason geolocation alone is not enough.
Layer 2: ASN and Network Ownership
Every IP is announced by an Autonomous System (AS) — a network with a unique ASN that controls a set of IP ranges. The ASN tells you who operates the network the IP belongs to, which is one of the most informative single data points available.
{
"asn": 13335,
"asn_org": "Cloudflare, Inc.",
"asn_type": "cdn",
"ip_range": "104.16.0.0/12"
}
ASN types:
- ISP / residential: Comcast, Deutsche Telekom, Jio — traffic from real people
- Mobile carrier: AT&T Mobility, Vodafone — phones behind CGNAT
- Datacenter / cloud: AWS, Google Cloud, Azure, OVH — server infrastructure
- CDN: Cloudflare, Akamai, Fastly — content delivery edge nodes
- Hosting / colocation: typically rented servers, not cloud scale
- VPN ASN: autonomous systems with documented VPN server history
The ASN type is a prior probability before any behavioral evidence is considered. A request from AS7922 (Comcast) is almost certainly from a real person. A request from AS16509 (Amazon) is almost certainly from a server or automated process. That one piece of data changes what you should expect and accept from the connection.
Layer 3: Infrastructure Classification
Going deeper than the ASN, infrastructure classification identifies the specific type of network context the IP operates in:
- Residential: assigned to a home broadband connection by a consumer ISP
- Mobile: assigned via CGNAT to a phone on a cellular network
- Datacenter: running in a cloud provider, dedicated server, or colo facility
- Business: assigned to a commercial entity's office infrastructure
- CDN edge: traffic exits from a content delivery network's edge node
- Satellite: assigned by satellite ISPs (Starlink, Viasat)
{
"ip_type": "datacenter",
"is_datacenter": true,
"is_residential": false,
"is_mobile": false,
"datacenter_name": "Amazon Web Services",
"datacenter_region": "eu-west-1"
}
This layer matters for fraud and access control because most real users on most consumer products connect from residential or mobile IPs. A datacenter IP accessing your consumer product is structurally unusual. Not always malicious — developers, automated pipelines, and business users legitimately connect from datacenters — but unusual enough to weight in a risk calculation.
Layer 4: Anonymization Detection
Anonymization detection determines whether the apparent IP is the user's real IP or a relay they are routing through. Three primary types:
VPN (Virtual Private Network): The user's traffic exits through a VPN server. The geolocation shows the VPN server location, not the user's real location. Detection draws on published provider server lists, active protocol probing (OpenVPN, WireGuard, IKEv2 handshakes), and ASN history. Commercial VPN providers like NordVPN, ExpressVPN, and Mullvad maintain published infrastructure that is reliably detectable.
Proxy (HTTP/SOCKS): Traffic relayed at the application layer rather than the network layer. Detectable through port probing — SOCKS5 and HTTP proxies respond to their respective greeting sequences on characteristic ports.
Residential Proxy: The most sophisticated anonymizer. Traffic exits through a real residential IP — usually harvested from a malware-infected device or a paid peer-to-peer proxy network. The IP itself belongs to a home ISP, so ASN-based detection fails. Detection requires behavioral signals: the same IP appearing in proxy network advertisements, abnormal churn patterns, or UA diversity inconsistent with a single-household connection.
Tor: The Tor anonymization network routes traffic through a series of encrypted relays before exiting at a Tor exit node. Exit node IPs are published in the Tor consensus directory, making detection reliable and complete.
{
"is_vpn": true,
"vpn_provider": "NordVPN",
"is_proxy": false,
"is_residential_proxy": false,
"is_tor": false,
"detection_methods": ["vpn_provider_list", "protocol_probe"]
}
Layer 5: Threat Intelligence
Threat intelligence aggregates external evidence of malicious behavior: reports from network abuse desks, honeypot captures, botnet sinkhole data, scanning activity logs, and spam trap triggers.
Key signals:
- Blocklist presence: how many independent blocklists include this IP, and which categories
- Abuse reports: volume and recency of ISP and abuse-desk complaints
- Botnet history: association with known malware command-and-control infrastructure
- Scanner fingerprints: evidence of port scanning, vulnerability probing, or credential stuffing
{
"on_blocklist": true,
"blocklist_count": 3,
"blocklist_categories": ["spam", "scanner", "brute_force"],
"abuse_reports_30d": 7,
"is_known_scanner": false,
"is_bot": true,
"bot_type": "spam_bot"
}
Threat intelligence is inherently time-sensitive. Blocklist entries age out as IPs change hands; abuse reports from three months ago are weak evidence; yesterday's scanner activity is strong evidence. Effective threat intelligence refreshes continuously rather than updating on a monthly batch cycle.
Layer 6: Risk Score
All of the above compresses into a single 0–100 risk score — the number you route decisions on.
{
"risk_score": 73,
"risk_factors": [
"vpn_verified_by_handshake",
"datacenter_asn",
"abuse_reports_recent"
],
"reputation": "low",
"confidence": 0.88
}
The score is only as useful as its explainability. A black-box number that rises and falls inexplicably cannot be tuned, defended in a chargeback dispute, or audited for bias. The risk_factors array names the contributing evidence — so when a risk score of 73 blocks a legitimate customer, you can identify which signal produced it and adjust the threshold or the weight.
What a Full IP Intelligence Response Looks Like
Pulling all layers together in one lookup:
curl "https://api.geoiphub.com/v1/lookup?ip=103.21.244.0" \
-H "Authorization: Bearer YOUR_API_KEY"
{
"ip": "103.21.244.0",
"country": "AU",
"city": "Sydney",
"latitude": -33.8688,
"longitude": 151.2093,
"timezone": "Australia/Sydney",
"asn": 13335,
"asn_org": "Cloudflare, Inc.",
"ip_type": "cdn",
"is_datacenter": true,
"is_residential": false,
"is_mobile": false,
"is_vpn": false,
"is_proxy": false,
"is_residential_proxy": false,
"is_tor": false,
"on_blocklist": false,
"abuse_reports_30d": 0,
"risk_score": 22,
"risk_factors": ["cdn_edge_node", "datacenter_asn"],
"reputation": "neutral",
"confidence": 0.95
}
This IP is a Cloudflare CDN edge node in Sydney — not a person, not malicious, not hiding anything. The risk score of 22 reflects the datacenter context with no abuse history. The right action depends on the use case: for a consumer checkout flow, this warrants a note in the session log; for a B2B API client, it is exactly what you would expect.
Which Layers Matter for Which Use Cases
| Use case | Primary layers | Notes |
|---|---|---|
| Fraud prevention at checkout | Anonymization, Risk score, Threat intel | Block/challenge on anonymizers + abuse history |
| Login risk scoring | Anonymization, Infrastructure, Risk score | Datacenter + VPN at login is elevated risk |
| Geo-restriction / compliance | Geolocation, Anonymization | VPN detection prevents geo bypass |
| Ad fraud / IVT filtering | Infrastructure, Bot fingerprints | Datacenter + bot = invalid traffic |
| Content localization | Geolocation, ASN | Country + ISP drives language/CDN decisions |
| API abuse prevention | Infrastructure, Threat intel, Rate signals | Datacenter IPs on blocklists warrant rate limits |
| Security traffic triage | All layers | Full picture for incident investigation |
The Gap Geolocation Leaves
To make the difference concrete: if a user in Moscow connects through a NordVPN server in Amsterdam, a geolocation lookup returns country: NL, city: Amsterdam. IP intelligence returns country: NL, city: Amsterdam, is_vpn: true, vpn_provider: NordVPN, risk_score: 41. The location data is identical. The intelligence is not.
In a geo-restriction context — say, a streaming service with Netherlands rights — the geolocation alone approves the request. IP intelligence flags that the location cannot be trusted. Whether to block or allow is a product decision; but without the intelligence layer, you cannot even make the decision consciously.
That is the practical boundary between IP geolocation and IP intelligence: geolocation tells you what the address claims. Intelligence tells you how much to believe it.
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
What is IP intelligence?
IP intelligence is the full set of data derivable from an IP address — not just the country and city, but the autonomous system that owns it, whether it is residential or datacenter infrastructure, whether it is running a VPN, proxy, or Tor relay, its abuse history, its threat classification, and a risk score synthesizing all of the above. The term distinguishes comprehensive IP analysis from basic geolocation, which typically returns only location fields.
What is the difference between IP geolocation and IP intelligence?
IP geolocation answers: where is this IP? Country, region, city, coordinates, timezone, ISP name. IP intelligence answers: what is this IP and how trustworthy is it? It adds infrastructure type (datacenter, residential, mobile), anonymization detection (VPN, proxy, Tor), threat classifications (scanner, botnet, spam source), abuse history, and a synthesized risk score. Geolocation is one layer inside IP intelligence.
What can IP intelligence tell you that geolocation cannot?
Whether the IP is a VPN or proxy hiding the real location (making the geolocation fields meaningless), whether it is a datacenter IP with no real user behind it, whether it has been on abuse blocklists recently, whether it is actively running a proxy or scanner service, and a probability estimate of how risky a request from this IP is. Basic geolocation returns coordinates; IP intelligence tells you whether to trust them.
How is IP intelligence used in practice?
Fraud teams use it to score risk at checkout, login, and signup. Security teams use it to triage inbound traffic and identify scanning or automated abuse. Ad platforms use it to filter invalid traffic before it charges a campaign. Compliance teams use it for geo-restriction enforcement and jurisdiction detection. Content platforms use it for geo-licensing and paywall decisions. The use case determines which layers of intelligence matter most.
Is IP intelligence accurate for mobile users?
Partially. Mobile users share IPs through carrier-grade NAT (CGNAT), so the geolocation is typically correct at the country and region level but imprecise at the city level. Infrastructure classification (mobile carrier vs datacenter) is reliable. Anonymization detection is reliable — a mobile user on a VPN looks very different from a native mobile connection. Risk scoring for mobile should be calibrated differently than for residential IPs because CGNAT makes per-IP blame diffuse.
