How do I dispute an incorrect IP or ASN geolocation?
If you believe an IP, CIDR, or ASN is geolocated incorrectly, open it in the Spur app and select the Report button (the warning-triangle icon) on its IP or ASN page. Choose Incorrect Labels, and under Additional information give the location Spur reports, the location you expect, and the evidence behind it. For a range, report one IP from it and list the full CIDR in your message. Your own measurements, such as traceroute or latency results from a known location, are the most useful. Registration records and other providers' results are helpful context, but Spur locates IPs from observed network measurement, so our research team reviews each report against that before making any correction. If you don't have access to the Spur app, email support@spur.us with the same details.
Similar questions
Why doesn't Spur's IP location match other geolocation sources?
Many geolocation providers fall back to registration data, which is the address on an IP's WHOIS or regional registry record. That address shows where the network was registered, not where the IP is actually used. Spur geolocates IPs from active network measurement and from location data that network operators publish for their own ranges. So when the two disagree, Spur reports where the IP measures, not where it's registered. Anycast IPs, which are served from many locations at once, are labeled as anycast rather than assigned a single location.
Can organizations rely on country-level geolocation alone?
Country-level geolocation remains useful, but it should not be treated as a complete solution. Modern anonymization services allow users to appear in approved countries while operating elsewhere, making additional infrastructure context increasingly important.
How do I report a false positive or other error in feed data?
Search for the entity in the Spur Dashboard (https://app.spur.us) and use the Report button to submit a report.
What does "client count" mean in Spur's data?
It's Spur's count of instances or connections observed from a given IP. As a general signal, a high count often points to shared infrastructure such as carrier-grade NAT, where many users' traffic passes through the same address, while a low count is more consistent with dedicated, single-tenant infrastructure. Treat it as a supporting signal alongside other data rather than a definitive classification on its own.
What is CGNAT, and why does it complicate IP-based fraud detection?
CGNAT (Carrier-Grade NAT) lets a mobile carrier or ISP route many customers' traffic through a single public IP address. That means one IP can represent thousands of different devices and a mix of legitimate and malicious users, which makes IP-based signals alone less reliable — additional context is needed to distinguish individual users sharing that address.
Related guides & explainers
Quick Search: Finding an IP, ASN, or Service Tag
Use quick search to jump straight to any IP, ASN or service tag, a Monocle app, or a main area of the app, from anywhere, without navigating through menus.
What "Client Proxies" Means in Spur Data
"Client Proxies" in Spur data describes proxy-network activity Spur observed coming from an IP — it does not mean the IP is owned or operated by the listed provider.
Context API Chrome Extension
Install Spur's Context API Chrome Extension to look up IP enrichment data directly from any web page — highlight an IP and get results inline, without leaving your browser. This is a developer-mode tool, not a Chrome Web Store listing.
Why the Organization Field Isn't Available the Same Way Across Spur's Data Feeds
The Context API's per-IP organization field isn't guaranteed in every data feed. Each feed has a different schema and covers a different slice of IP space, so field availability varies by feed.