If you run a public or lightly-authenticated API, you have a standing invitation that not everyone uses politely. Pricing endpoints get scraped by competitors. Search endpoints get mined. Free tiers get drained by someone running a business on top of your generosity. And your rate limits, the usual defence, have a weak spot.
Why rate limits leak
Most rate limits count requests per IP. That works right up until someone routes their traffic through a pool of proxies. Each request arrives from a fresh address, so each one looks like a brand-new, well-behaved caller, and your per-IP counter never fills up. The abuser gets effectively unlimited throughput while every honest user shares the same cap.
Count by network, not just by address
The fix is to look one level up. Requests rotating through a proxy pool still share traits: they come from datacenter and proxy networks, not home or mobile connections, and often from the same provider even as the individual IPs change. Screening on that lets you:
- Apply a tighter limit, or a challenge, to calls from datacenter and proxy networks.
- Rate-limit by network and provider so address rotation stops resetting the count.
- Keep generous limits for genuine callers on normal connections.
Do not punish your real integrators
A caveat: some legitimate users will call your API from a server, which is a datacenter connection by definition. That is why network type should adjust the limit or add a key requirement, not slam the door. The combination of an unauthenticated call, from a rotating proxy pool, at machine speed, is the real abuse signature, not datacenter traffic by itself.
Fraudex returns the network and datacenter verdict for any IP in under a millisecond, so you can enrich your own rate limiter with a signal that proxy rotation cannot wash out.