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.
How Spur determines location
Spur measures IPs directly from its own network of probes in known locations. An IP that responds very quickly to a probe is physically close to it. Spur also uses location files that network operators publish for their own ranges (known as geofeeds), from a reviewed list of operators. Routing data (whether and where an IP range is announced on the internet) adds more context. Registration records are the weakest signal. They're treated as background information, never as proof of where an IP is located.
Why results can differ from other sources
- Anycast. An anycast IP is announced from many locations at the same time, sometimes across dozens of countries, and each user reaches whichever location is nearest. There's no single correct location for these IPs, so Spur labels them as anycast. Other sources often show the registrant's headquarters instead, which is wrong for most of the traffic on that IP.
- Registration and measurement disagree. An IP can be registered in one country and used in another, for example a cloud or proxy provider whose registration lists one office while the service runs from a data center elsewhere. Spur reports the measured location.
- Not routed. If an IP range isn't announced on the internet, it isn't reachable and has no real location. Spur doesn't assign one based on registration data alone.
If you think Spur's location is wrong
Spur decides most locations per /24 range (256 consecutive IPs), and each IP in the range shares that answer. Some providers locate each IP individually, so a single IP can occasionally differ between the two. If you believe a location is incorrect, select the Report button (the warning-triangle icon) on the IP's page (or the ASN's page) in the Spur app. See "How do I dispute an incorrect IP or ASN geolocation?" for what to include. The most useful evidence is your own measurements, such as traceroute or latency results from a known location, or first-hand knowledge of where the network is hosted. A different provider's result or a registration record on its own isn't enough to change a measured location.
If you operate the network in question and publish a geofeed for it, include the geofeed URL in your report so our team can review it.
If anycast IPs are causing problems for your rules, such as location-based access controls, handle anycast traffic as its own case rather than forcing a single location onto it.
Similar questions
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.
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.
How can Spur help organizations identify fraudulent remote workers without creating unnecessary friction?
The most effective approach is to use multiple signals rather than relying on any single indicator. Organizations can combine IP intelligence, identity verification, onboarding controls, and behavioral analytics to identify suspicious infrastructure patterns while minimizing disruption for legitimate candidates and employees. Spur intelligence can help identify infrastructure patterns, anonymization tools, proxy services, and geographic inconsistencies that may be associated with certain remote-work fraud schemes. Most organizations combine Spur data with additional identity, behavioral, and investigative signals.
Why isn't traditional IP geolocation enough to enforce geographic restrictions?
Traditional geolocation only identifies where an IP address appears to be located. It does not reveal whether traffic is being routed through a VPN, residential proxy, mobile proxy, or other anonymization service. As a result, users can appear to originate from approved locations while actually operating elsewhere.
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.
Related guides & explainers
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.
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.
Why Residential Proxy Classifications Can Appear on Legitimate Infrastructure
Residential proxy networks recruit real consumer devices to relay traffic, so a legitimate ISP's own IP ranges can show a residential-proxy classification without the ISP's knowledge or involvement.
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.