Rate limiting is one of the most powerful DDoS mitigation tools and one of the most frequently misused. It enforces a maximum request rate for a given identity — usually an IP address or a session — and applied well it turns a flood into a trickle. Applied badly it blocks your own customers, generates support tickets, and teaches your team to distrust the very control that should be protecting them. The difference between the two outcomes is almost entirely about granularity and thresholds.
What to Rate-Limit On
- Per IP address: the simplest dimension, but weak against distributed botnets that send one request per IP across thousands of addresses.
- Per IP + User-Agent: adds a dimension, though the User-Agent is trivially spoofed.
- Per session token: accurate for authenticated endpoints, but irrelevant for anonymous public pages.
- Per ASN: a broad brush useful when an attack is concentrated in one network you do not serve.
- Per endpoint: different limits for /search, /login and /checkout based on how expensive each is to serve.
The Threshold Problem
Thresholds are where most rate limiting fails. Set them too low and you block legitimate users behind shared carrier NAT, where many real people share one mobile IP — a single limit treats them as one abuser. Set them too high and a bot pacing itself just under the ceiling sails straight through. There is no single safe number, because the right threshold depends on what normal traffic actually looks like for that endpoint. The answer is thresholds derived from observed baseline behaviour rather than a guessed global figure — you measure what normal looks like, and flag what departs from it.
A two-tier approach works best
Use a hard block only at extreme rates (say, over 1,000 requests per minute per IP) where no real user could plausibly be, and a soft challenge — a JavaScript check or CAPTCHA — at moderate rates (say, over 50 per minute per IP). Block at the extreme tier; challenge, never hard-block, at the moderate one, so a false positive costs a real user a second, not access.
Endpoint-Specific Rules
The biggest single improvement most teams can make is to stop using one global limit. A product-listing page can absorb 500 requests a minute without blinking; a password-reset form seeing five a minute from one IP should already be raising alarms. Rate limits should reflect what each endpoint does and costs — generous on cheap, cacheable, public pages, and tight on expensive or sensitive ones like login, checkout and search.
How Akarguard Applies It
Akarguard lets you set per-domain rate and connection limits from the panel and enforces them at the reverse-proxy edge, in front of your origin, so abusive sources are throttled before they reach your server. Because the edge sees your traffic continuously, limits can be tuned against your actual baseline rather than a blind global number, and the two-tier model comes naturally — extreme rates are dropped or banned in the kernel (via the edge's fail2ban integration), while moderate anomalies get a challenge that real browsers clear invisibly. The result is flood mitigation that does not punish the mobile user sharing a carrier IP with a thousand others.