Research Question: when you look up a well-known IP's location, are you learning where a server physically sits, or something else? We queried four real, independently verifiable addresses and compared the results against public facts about each.
| Test date | August 13, 2026 |
| Tool | NetRiskScan public IP Risk Check API (/api/public/ip/query) |
| Sample | 4 real, independently identifiable IPs |
The results
| IP | Known as | Reported location | ASN / network owner | Network type flags |
|---|---|---|---|---|
1.1.1.1 | Cloudflare Public DNS | Sydney, Australia | AS13335, Cloudflare, Inc. | Hosting, Datacenter |
8.8.8.8 | Google Public DNS | Mountain View, California, US | AS15169, Google LLC | None set |
104.210.140.135 | Microsoft Azure block | San Antonio, Texas, US | AS8075, Microsoft Corporation | Hosting, Datacenter |
191.222.208.203 | This session's own connection | Brasília, Brazil | AS906, DMIT Cloud Services | Hosting, VPN |
Reading the interesting one: 1.1.1.1 in Sydney
Cloudflare is headquartered in San Francisco, and 1.1.1.1 is a global anycast address — the same address is announced from Cloudflare points of presence in dozens of countries simultaneously, and whichever one is network-closest to a given requester answers. There is no single "real location" for an anycast address to report; a GeoIP database has to pick something, usually based on where the address block is registered or where its provider's routing data points for a given resolution context. Sydney is a real, working Cloudflare edge location — it's a legitimate answer, just not "the" location in the way a single, non-anycast server has one.
8.8.8.8 (also anycast, run the same way by Google) resolved instead to Mountain View — Google's actual headquarters and a real Google datacenter market. Both answers are internally consistent for their respective providers' data; they simply illustrate that two anycast resolvers, geolocated by the same tool, don't necessarily land on the "same kind" of answer (one lands on network infrastructure geography, the other on corporate/datacenter geography).
The other two: registration matches operation
104.210.140.135 (a real Microsoft Azure address) geolocated to San Antonio, Texas — a real, documented Azure region. 191.222.208.203, the connection this research session itself was run from, geolocated to Brasília, Brazil, and is correctly flagged as hosting/VPN infrastructure rather than a residential connection. Both are non-anycast, single-operator address blocks, and their reported locations line up with plausible, checkable facts about who operates that space.
What this means practically
IP geolocation is reliably good at telling you which network operates an address and roughly which region that operator's infrastructure serves. It is not GPS, and for anycast or large multi-region cloud providers specifically, "location" describes a network-topology answer more than a physical pin — a distinction worth knowing before treating a single geolocation result as precise ground truth. See Why My IP Location Is Wrong for the mechanics of geolocation accuracy generally.
Limitations
Four addresses is a small, purpose-picked sample chosen specifically because each is independently verifiable — it is not a random or representative sample of IP space generally, and it should not be read as a statement about geolocation accuracy across all address types. Results reflect NetRiskScan's configured provider data on the test date and can change as provider databases update.
Conclusion
Run your own connection through the IP Risk Check and compare what it reports against what you know to be true about your network — for most non-anycast residential and business connections, the match is considerably tighter than the anycast cases above.