Ask HN: One IP, multiple unrealistic locations worldwide hitting my website | Hacker News Reader

Ask HN: One IP, multiple unrealistic locations worldwide hitting my website

44 pointsnacho-daddy26 comments

Background: I manage an ecommerce website. Recent bot traffic is up. Most traffic can be traced to one or two IP addresses with hundreds of requests per day. These ip addresses don't have DNS records for reverse lookup, and when I map the requests in cloudflare, one address shows up as requesting from different data centers all over the US. What is going on here? Source IP example 173 . 245 . 58 . 0

Chicago, United States (ORD)

340 requests

San Jose, United States (SJC)

330 requests

Los Angeles, United States (LAX)

310 requests

Atlanta, United States (ATL)

310 requests

Dallas-Fort Worth, United States (DFW)

290 requests

Newark, United States (EWR)

280 requests

Washington, United States (IAD)

230 requests

Miami, United States (MIA)

210 requests

Boston, United States (BOS)

140 requests

Singapore, Singapore (SIN)

130 requests

Thanks for ideas.

View on HN

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). In a 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.

To my knowledge, any cast is very much a thing cloudflare uses.. It allows to split traffic per region, which, in the case of DDOS is a good thing.

To be clear, they definitely use ingress anycast (ie anycast on external traffic coming into Cloudflare). The main question was whether they (meaningfully) used egress anycast (multiple Cloudflare servers in different regions using the same IP to make requests out to the internet).

Since you mentioned DDOS, I’m assuming you are talking about ingress anycast?

It doesn't really matter if they're doing that for this purpose, though. Cloudflare (or any other AS) has no fine control of where your packets to their anycast IPs will actually go. A given server's response packets will only go to one of their PoPs. It's just that which one will depend on server location and network configuration (and could change at any time). Even if multiple of their PoPs tried to fetch forward from the same server, all but one would be unable to maintain a TCP connection without tunneling shenanigans.

Tunneling shenanigans are fine for ACKs, but it's inefficient and therefore pretty unlikely that they are doing this for ingress object traffic.

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.

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.

In my use case, woocommerce in WP, I have WordFence security plugin, and it has a selection to choose which header to pull ip address from. Since I used cloudflare, I selected the appropriate checkbox, and the IPs were properly posting.

So, hopefully you are able to check on which header your requests are being hit with.

Other comments already mentioned it, but that’s to figure out with your anti-ddos/reverse proxy headers setup

# AS13335 Cloudflare, Inc.:US San Francisco, California https://www.abuseipdb.com/check/

block from any to 173.245.58.0/24

# US https://www.abuseipdb.com/check/173.245.58.143

block from any to 173.245.58.140

# US https://www.abuseipdb.com/check/173.245.58.143

block from any to 173.245.58.143

# US https://www.abuseipdb.com/check/173.245.58.151

block from any to 173.245.58.151

# US https://www.abuseipdb.com/check/173.245.58.165

block from any to 173.245.58.165

That's a Cloudflare IP — 173.245.x.x is their range. You're seeing Cloudflare's edge servers, not actual visitor IPs.

The multiple locations are just showing which Cloudflare POP handled each request (ORD, SJC, LAX = their data centers). That's expected behavior when you're proxied through CF.

Check the CF-Connecting-IP header to get the real visitor IP. What you're logging right now is basically "which Cloudflare server talked to your origin," not "where the bot actually is."

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

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.

We’ve been experiencing the same thing. On further inspection, we discovered that the owner of the data centers was Tencent. So we blocked them at the ASN level across countries.

This was after web had to geo block China & Singapore some weeks earlier.

These AI scraping guys are destroying the web for normal folks in these countries where they run data scrapers.

Did they really have to geo-block entire countries? I think the blocks of unrelated users is what's really affecting normal folks and that's the choice of operators.

It's like if you had incidents with a few violent drunk Brovanians in your town, then saying it's those few peoples fault that Brovanians are now being discriminated against and are being banned from entering shops just because they come from the same place as the vandals.

Site operators arbitrarily blocking entire countries due to a few botters (albeit with a lot of bots) causing issues aren't without responsibility in the loss of an open web.

You have a choice in how to respond and where to draw lines. We can't just throw up our hands and blame the botters.

tirreno (1) guy here.

What you're seeing is normal bot behaviour, they constantly scan every website for different purposes. 100–500 requests per IP is nothing you should worry about or take any action against.

tirreno works on the backend, so sometimes we use it to analyze bot behaviour when they start doing something really suspicious, like massive requests (hundreds of thousands a day) or scanning all possible files/folder structures, which could easily result in half a million requests in short period of time.

1. https://github.com/tirrenotechnologies/tirreno

That is a Cloudflare IP address.

Have a look at the request HTTP headers and see what they say.

VPNs, proxies/relays, crawlers, etc

> 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...

> I can handle hundreds of requests per day with no issue on a home cable modem connection and my desktop pc running nginx.

And what kind of ecommerce site are you running on that nginx? First thing that get overwhelmed by bot traffic is DB. With a tiny one, with low total connection limit and bots hitting less common path like browsing 20th page of product search results, it is really easy to get DoS. I remember having to block Yandex user agent 20 years ago, surprising no one wanted to allocate additional resources so that crawler is happy.

If your ecommerce site cannot handle a hundred requests a day, I'm going to blame the "victim". I think it'd be time to take such a site and put it behind a login for the tens of users of it.

Yeah, I get hundreds of requests if not more per hour for some obscure personal but public servers that have ~0 legitimate other users. I guess once you're in some index that's just that. For an e-commerce shop, a few thousand irrelevant requests per day should just be part of the background noise that comes with being online these days? Cache is king.

Reply on news.ycombinator.com