NexIP官方博客
IP geolocation accuracy depends on the criterion hierarchy: database lookup only reflects the operator's static declaration, while active RTT ranging combined with ASN verification can falsify remote spoofing at the physical topology level.
What Exactly IP Geolocation Accuracy Measures
Commercial IP geolocation results are not real-time mapping of physical locations; they are a combination of WHOIS registration information, operator self-declared Geofeed files, and inferences from various databases' proprietary data. This means that an IP actually located in a European data center, if its upstream operator incorrectly declares or deliberately mislabels it as a city in the United States in Geofeed, all third-party libraries syncing that data will show the same "US" result. This phenomenon of "collective misjudgment by the majority" reveals the limitation of pure lookup: what you see is a summary of static declarations, not the physical fact of light signal propagation.
Why City-Level Results Are Prone to Error
Accuracy decays stepwise as geographic scope narrows. Country-level determination is generally reliable, but city-level accuracy typically ranges from 20% to 75% (this is an observed range from public evaluations; specific intervals vary with region, database, and prefix type), and is constrained by confidence radius; public services cannot precisely pinpoint streets or house numbers. The Geofeed mechanism defined by RFC 8805 allows network operators to autonomously fill in geographic locations, lacking mandatory physical audit at the specification level. Since entities like MaxMind and IPinfo pull and process these self-declared files on different cycles, the same IP may show divergent city fields across different sites for weeks. When encountering conceptual confusion like the fundamental difference between native and non-native IPs, understanding the self-declared nature of data sources is crucial.
Key Differences Between Database Lookup and RTT Measurement
To more clearly determine the authenticity of an IP, we need to compare passive lookup and active ranging. The table below shows core differences in evidence strength, falsifiability, and applicable scenarios, and introduces controllable items from the procurement side as a reference.
| Dimension | Database Lookup (Passive) | RTT Active Ranging + ASN Verification (Active) |
|---|---|---|
| Evidence Source | Others' declarations (WHOIS/Geofeed) | Measured latency under physical constraints of light speed |
| Falsifiability | High (data centers can falsify CSV files) | Low (limited by the lower bound of fiber propagation speed) |
| Conclusion Granularity | Country/City (with confidence radius error) | Falsify remote spoofing / Verify local ISP attributes |
| Tool Cost | Very low (online query is sufficient) | Medium (requires multiple probe nodes and scripts) |
| Applicable Objects | Initial screening, batch rapid labeling | In-depth acceptance of single points, review of disputed IPs |
| Procurement Controllables | Can only discover deviations afterward | Can specify region/city/ASN; NexIP provides session stickiness to prevent attribution drift |
If you need to understand why certain IPs are flagged as high-risk, refer to the specific metric definitions in How to detect whether a residential IP is a real dual ISP.
How to Perform Active RTT Ranging
To replicate this process, you need to send ping or traceroute requests from multiple probe points with known geographic locations to the target IP. The key is to record the stabilized round-trip time (RTT). Based on the signal propagation speed in fiber optics of approximately 200,000 km/s, every 1,000 km of physical distance corresponds to an RTT lower bound of about 10 ms. For example, if an IP claimed to be in the US measures an RTT of less than 10 ms from a European node, while actually measuring over 100 ms from North America, this is physically impossible and directly confirms false broadcast or remote data center masquerading. During operation, multiple samples are needed to avoid congested periods and to exclude interference from transit nodes, thereby obtaining a credible location interval conclusion.
ASN Registration Entity Verification
The second criterion focuses on the registration entity attributes of the ASN to which the IP belongs. It is crucial to distinguish between local broadband operators for home users (Residential ISP) and data center/hosting entities. It is recommended to check in order: first, look at the ASN registration entity name and its main business type; second, check the prefix's usage annotation in public registration information; third, analyze reverse DNS naming characteristics. These three corroborate each other; if conflicts arise, defer to the ASN registration entity name and main business type. A combination labeled "residential" but with an ASN pointing to "Hosting" often corresponds to data center masquerading. Compared to easily tampered city fields, the registered usage annotation and reverse DNS characteristics of ASN are harder to unilaterally alter. Understanding Why data center IPs are easily identified as high-risk IPs helps further grasp platform risk control preference logic for network types.
Meaning of Three Common Divergence Types
In practice, users often encounter three typical divergences. The first is when countries are consistent but cities differ, which usually falls within the error range of confidence radius and self-declared update cycles, mainly affecting address consistency for localized delivery; in this case, check whether the ASN registration entity matches the local mainstream ISP. The second is when even countries disagree across databases, indicating that upstream declarations have been recently changed or the broadcast segment is disputed; verify WHOIS registration information and the latest Geofeed submission records. The third, and most dangerous, is when database results agree but RTT does not match the claimed location, directly pointing to false broadcast, and the IP must be discarded. For the first two cases, cross-verification via physical ranging and ASN attribute checks can be performed; the last case leaves no room for negotiation.
Choosing Method by Scenario
Different businesses have varying levels of IP geolocation accuracy requirements; it is recommended to select verification depth based on the specific scenario.
| Business Scenario | Verification Depth Requirement | Core Criterion Combination | Trigger for Re-verification |
|---|---|---|---|
| European/US local store | City-level + physical ranging | RTT ranging + ASN local ISP attributes | City field suddenly jumps or RTT is abnormal |
| Social media multi-account long-term login | Country-level + stability | ASN attributes + no attribution drift within session | Country/city changes mid-session |
| Public search/product selection | Country-level | Basic database query | Frequent CAPTCHAs or access restrictions |
Frequently Asked Questions
Why do different websites show different IP locations?
Because commercial IP databases have different processing cycles for syncing stale WHOIS and Geofeed self-declared data. If an upstream operator mislabels locations, different databases will show discrepancies due to different fetch times. This is a static declaration inconsistency from the data source, not a physical location change.
Why is the city shown by IP location incorrect?
City-level accuracy is only 20%-75%, heavily constrained by confidence radius. Additionally, data centers may make false declarations by modifying Geofeed CSV files. If RTT ranging shows physical distance significantly inconsistent with the claimed city, it confirms false broadcast.
How can US local stores confirm that the purchased IP is really in the US?
Ping the IP from nodes in Europe, Asia, and North America. If RTT measured from Europe is extremely low (e.g., <10ms) while from North America is normal (e.g., 100ms+), the IP is physically not in the US. Also check whether the ASN belongs to a real local broadband operator.
Can IP geolocation be precise to the city?
It can provide a city estimate, but not precise to street or house number. Public IP geolocation inherently has a precision ceiling; city-level results are for reference only and cannot serve as legal or absolute identity basis. It must be combined with other network fingerprints for comprehensive judgment.
If two databases disagree on the same IP, which should I trust?
Do not blindly trust a single database. When conflicts arise, prioritize sources with independent physical ranging data or clearly marked ASN attributes. If neither database has RTT corroboration, first perform active ranging and ASN registration entity verification, then decide to continue using or discard the IP based on the verification results.
It is recommended to confirm with the service provider whether you can specify region, city, and ASN before ordering. After delivery, perform a cross-verification of multi-point RTT and ASN registration entity as described. If you need to differentiate session stickiness requirements by business stage, refer to NexIP's dynamic residential and static residential solutions' region/ASN targeting descriptions before deciding on the procurement tier.
Comments(0)