When one IP address is a thousand visitors
A growing share of real people reach your origin through a privacy relay or a consumer VPN. Their address looks like a cloud datacenter. If your WAF treats that as a bot, the site feels broken to them, and your logs still look like an attack.
A few years ago, the IP address seen at the origin was a reasonable stand-in for “who is this”. Home broadband, an office NAT, the occasional hotel Wi-Fi. Datacenter ranges were a useful hint: scrapers, scanners, cheap VPS boxes.
That shortcut is wearing out.
Apple iCloud Private Relay, WARP-style tunnels and ordinary consumer VPNs route the browser through a shared egress. The origin never sees the visitor’s ISP address. It sees an address from a pool used by thousands of strangers at the same time. Everything else looks normal: the User-Agent is Safari or Chrome, the request is for an ordinary page, a form or a login. Only the ASN points to a cloud provider.
A WAF that blocks or throttles “datacenter IPs” by default will punish that visitor. A 429 or a tarpit on a shared proxy address isn’t precise. It hits everyone behind it.
The opposite mistake is just as real. Allowlist the whole pool, and every scraper hiding in the same range walks straight in. So the rule at the origin is neither “trust the cloud” nor “ban the cloud”. It is: never treat a shared egress as if it were a single client.
What still works
- Looking at the request itself. Unusual parameters, injection payloads, spoofed crawler identities and known-bad bots all give themselves away without a unique home IP.
- Recognising relay ranges for what they are. Some relays, including Apple Private Relay, publish their egress ranges. Label them as shared proxies, not as hosting.
- Per-site allowlists for staff and office networks you actually know.
- Rate limiting with care. Slow down a visitor’s behaviour when you can tell visitors apart. If the only identifier is the shared egress address, do not pile a rate limit on it. You would be charging everyone behind it for one person’s requests.
What doesn’t
- Treating a privacy relay range as if it were a botnet on rented servers.
- Hard-blocking on ASN alone when the browser and the request are otherwise ordinary.
- Calling the result “bot protection” when someone on their phone just tried to open your site.
How ONX handles it
ONX makes the decision at the origin, in the EU. ONX keeps a profile of each URL (typical methods, parameters and pace) and scores a request against that, not against a worldwide IP reputation.
Shared proxy ranges come from ONX’s own list. They are treated as shared pipes, not as a single hosting botnet, so a datacenter-style ASN check is not applied to them, and we do not pile an IP-keyed rate limit on that address. Request shape and the URL profile are still checked.
Your cloud DDoS protection at the edge can stay exactly where it is. But the origin still needs to tell the difference between an address shared by many people and a machine in a rack.
We would rather let a scraper through for a second than shut the door on a real visitor whose only “offence” is using a privacy network. The scraper usually gives itself away in the request. The visitor doesn’t.
Back to the journal