173.245.58.0 is owned by cloudflare (https://www.cloudflare.com/ips/). You're probably tracking the IP address of cloudflare's reverse proxy that hits your application instead of true source IP (which cloudflare will copy into X-Forwarded-For header).
Likely you pulled this IP from your application's logs? If you're trying to track bot traffic, use Cloudflare's built-in analytics tool.
Also a single source IP can be hosted in geographically distinct locations - that's called anycasting, which cloudflare does use, however I don't think that's the issue here.
It’s possible, but I think it’s typically used for ingress (ie same IP, but multiple destinations, follow BGP to closest one).
I don’t think I’ve seen a similar case for anycast egress. Naively, doesn’t seem like it would work well because a lot of the internet (eg non-anycast geographic load balancing) relies on unique sources, and Cloudflare definitely break out their other anycast addresses (eg they don’t send outbound DNS requests from 1.1.1.1).
So reading the article you’re right, it’s technically anycast. But only at the /24 level to work around BGP limitations. An individual /32 has a specific datacenter (so basically unicast). Ina hypothetical world where BGP could route /32s it wouldn’t be anycast.
I wasn’t precise, but what I meant was more akin to a single IP shared by multiple datacenters in different regions (from a BGP perspective), which I don’t think Cloudflare has. This is general parallel of ingress unicast as well, a single IP that can be routed to multiple destinations (even if on the BGP level, the entire aggregate is anycast).
It would also not explain the OP, because they are seeing the same source IP, but from many (presumably) different source locations whereas with the Cloudflare scheme each location would have a different source IP.
Are you using Cloudflare in front of your site? If so, the IP you’re seeing is Cloudflare’s and not the bot’s IP. You’d need to log and check the headers that Cloudflare sends you, i.e. x-forwarded-for and cf-connecting-ip.
As to how one IP can originating from multiple locations: anycast.
I would have said that perhaps you are getting requests from people using their WARP proxy product - which isn't that wild. The reverse DNS on that page though suggests that the range is mainly full of name-servers, which would be strange to get requests from but I have no idea what cloudflare does on its network.
As for the multiple datacentre thing - one IP address can be Anycast-ed to multiple actual hosts in different physical locations.
For example, if I ping 173.245.58.0, I get a response in 11ms from my location here in Helsinki. At the speed of light this means travelling 3,300KM (0.011s * 3x10^8m/s) which doesn't get me anywhere near the States. So again, nothing exciting about 1 IP address coming from different locations. If you look at your raw logs - you might see some headers from cloudflare with more clues.
It's interesting, but as others have mentioned, not worth worrying about.
That specific IP is detected as anycast by bgp[dot]tools , which is likely as it is announced from AS13335, so backbone routers will choose the best route back to the multiple places it is announced from. If you traceroute such an IP from multiple geographic locations, you'll probably notice that the RTT is implausibly low from all locations (assuming a unicast announcement) - which is the benefit to anycast.
Does this matter? I can handle hundreds of requests per day with no issue on a home cable modem connection and my desktop pc running nginx. In fact I do and have since the 56k days. With an actual server or VPS with a big pipe in a datacenter this should literally be below noticing in terms of cost.
I would characterize this response to normal public website traffic as more harmful than the "problem". There's no need to be upset that web spiders are visiting your public website. That is what public websites are for.
Anyway, if you really do want to persue this silly thing start by looking up the ASN the IP is in and go from there. Don't rely on cloudflare to interpret the internet for you. I wrote an offline geo-ip and whois db dump world map visualizer in 2025 and these are the resources I use:
173.245.58.0 is owned by cloudflare (https://www.cloudflare.com/ips/). You're probably tracking the IP address of cloudflare's reverse proxy that hits your application instead of true source IP (which cloudflare will copy into X-Forwarded-For header).
Likely you pulled this IP from your application's logs? If you're trying to track bot traffic, use Cloudflare's built-in analytics tool.
Also a single source IP can be hosted in geographically distinct locations - that's called anycasting, which cloudflare does use, however I don't think that's the issue here.
It’s possible, but I think it’s typically used for ingress (ie same IP, but multiple destinations, follow BGP to closest one).
I don’t think I’ve seen a similar case for anycast egress. Naively, doesn’t seem like it would work well because a lot of the internet (eg non-anycast geographic load balancing) relies on unique sources, and Cloudflare definitely break out their other anycast addresses (eg they don’t send outbound DNS requests from 1.1.1.1).
Cloudflare actually does anycast for egress too, if that is what you meant: https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-...
So reading the article you’re right, it’s technically anycast. But only at the /24 level to work around BGP limitations. An individual /32 has a specific datacenter (so basically unicast). Ina hypothetical world where BGP could route /32s it wouldn’t be anycast.
I wasn’t precise, but what I meant was more akin to a single IP shared by multiple datacenters in different regions (from a BGP perspective), which I don’t think Cloudflare has. This is general parallel of ingress unicast as well, a single IP that can be routed to multiple destinations (even if on the BGP level, the entire aggregate is anycast).
It would also not explain the OP, because they are seeing the same source IP, but from many (presumably) different source locations whereas with the Cloudflare scheme each location would have a different source IP.
Since it hasn't been mentioned, my first thought is valid users browsing on iOS with iCloud Private Relay enabled.
https://support.apple.com/en-us/102602
I have this enabled on my iPhone and websites that report my IP show the block is owned by Cloudflare or Akamai.
Found the list! It might be worth checking if your suspect traffic is from any of these subnets: https://mask-api.icloud.com/egress-ip-ranges.csv
Are you using Cloudflare in front of your site? If so, the IP you’re seeing is Cloudflare’s and not the bot’s IP. You’d need to log and check the headers that Cloudflare sends you, i.e. x-forwarded-for and cf-connecting-ip.
As to how one IP can originating from multiple locations: anycast.
That IP address you shared is a CloudFlare IP address: https://bgp.tools/prefix/173.245.58.0/24#asinfo
I would have said that perhaps you are getting requests from people using their WARP proxy product - which isn't that wild. The reverse DNS on that page though suggests that the range is mainly full of name-servers, which would be strange to get requests from but I have no idea what cloudflare does on its network.
As for the multiple datacentre thing - one IP address can be Anycast-ed to multiple actual hosts in different physical locations.
For example, if I ping 173.245.58.0, I get a response in 11ms from my location here in Helsinki. At the speed of light this means travelling 3,300KM (0.011s * 3x10^8m/s) which doesn't get me anywhere near the States. So again, nothing exciting about 1 IP address coming from different locations. If you look at your raw logs - you might see some headers from cloudflare with more clues.
It's interesting, but as others have mentioned, not worth worrying about.
As others mentioned, look at observability logs in your CloudFlare, check user agent, x-forward-address and asn.
Then block the ip/asn/service that’s causing the bot traffic if you deem useless.
Some bots can be related to SEO tools, these will have Search Engine Optimization category in CloudFlare
That specific IP is detected as anycast by bgp[dot]tools , which is likely as it is announced from AS13335, so backbone routers will choose the best route back to the multiple places it is announced from. If you traceroute such an IP from multiple geographic locations, you'll probably notice that the RTT is implausibly low from all locations (assuming a unicast announcement) - which is the benefit to anycast.
VPNs, proxies/relays, crawlers, etc
Set up fail2ban and just forget about it. Or do like me and watch the bans roll by in the log file while having your morning coffee.
That is a Cloudflare IP address.
Have a look at the request HTTP headers and see what they say.
> hundreds of requests per day
Does this matter? I can handle hundreds of requests per day with no issue on a home cable modem connection and my desktop pc running nginx. In fact I do and have since the 56k days. With an actual server or VPS with a big pipe in a datacenter this should literally be below noticing in terms of cost.
I would characterize this response to normal public website traffic as more harmful than the "problem". There's no need to be upset that web spiders are visiting your public website. That is what public websites are for.
Anyway, if you really do want to persue this silly thing start by looking up the ASN the IP is in and go from there. Don't rely on cloudflare to interpret the internet for you. I wrote an offline geo-ip and whois db dump world map visualizer in 2025 and these are the resources I use:
## RIR whois/peering db # RIPE NCC https://ftp.ripe.net/ripe/dbase/split/ripe.db.aut-num.gz # ARIN https://ftp.arin.net/pub/rr/arin.db.gz # APNIC https://ftp.apnic.net/apnic/whois/apnic.db.aut-num.gz # LACNIC https://ftp.lacnic.net/lacnic/dbase/lacnic.db.gz # AFRINIC https://ftp.afrinic.net/dbase/afrinic.db.gz ## RIR Delegation files # https://www-public.telecom-sudparis.eu/~maigron/rir-stats/ # https://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-... # https://ftp.apnic.net/stats/apnic/delegated-apnic-extended-l... # https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-... # https://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-ext... # https://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-ext...