How to Configure Rate Limits for Effective DDoS Mitigation

Despite advances in bot management and behavioral analysis, rate limiting remains one of the most reliable DDoS mitigation controls.

We say it in nearly every customer engagement, and we mean it literally. When we walk into an environment after a real attack, the difference between a clean mitigation and an outage is almost always in how the rate limits were configured.

But the same rule that mitigates an attack can also cause one. A rate limit set with the wrong incrementor, or at the wrong threshold, can block legitimate users alongside the attackers. Sometimes more of them.

This post covers what rate limiting can actually do, the configuration choices that matter most, and the patterns we recommend – including the one we recommend against.

Key takeaways

• Rate limits are empirical, not behavioral – they block traffic anomalies regardless of how clean the requests look
• Every rate-limit rule has a scope or condition (which requests it applies to) and an incrementor (what the counter is keyed on); they are independent decisions that affect the rule’s threshold and effectiveness.
• Rate Limit rules are valuable on L3/L4 traffic as well.
• The tighter the scope, the lower the threshold can safely go without false positives
• Multi-layer rate limiting outperforms any single rule
• Rate limiting in which the incrementor is the destination itself, is the most common misconfiguration we see in the field

Why Rate Limits Are the Native Mitigation for DDoS

Most DDoS attacks are characterized by traffic volume anomaly, not request content. A botnet can pretend to be Chrome, complete a real TLS handshake, present legitimate headers, and even solve a JavaScript challenge if it has to. What it cannot hide is that thousands of clients are each sending requests at a rate no legitimate user would sustain.

Behavioral controls, bot management scoring, WAF signatures, IP reputation measures – all try to figure out who the requester is. They work well against attackers who haven’t bothered to blend in. They struggle against attackers who have.

Rate limits don’t care who anyone is. They watch the rate. If requests against a defined counter cross a threshold, the rule is triggered. The decision is numerical, not interpretive – which is exactly why rate limits are the native mitigation for traffic anomalies.

The Anatomy of a Rate-Limit Rule

A rate-limit rule has four independent components:

• Scope – the conditions the rule evaluates traffic against (which requests it applies to)
• Incrementor – the property the counter is keyed on (what counts as “the same client”, or “All requests with the same API key”)
• Threshold – the request rate that triggers the rule
• Action – what happens when the rule fires

Most teams pay attention to threshold and action. Scope and incrementor are where the configuration usually succeeds or fails.

Scope

The scope defines which requests the rule even looks at. Examples:

• All requests to the site
• Requests to a specific URI path (e.g., /login)
• Requests with a specific HTTP method (e.g., POST)
• Requests that match a header value, geo-location, or ASN

Scope can be broad or tight. The tighter the scope, the more precisely the rule can be tuned – because the legitimate traffic floor inside that scope is lower and better understood.

Incrementor

Incrementor defines what the counter is keyed on – meaning what the rule treats as a single client for rate-counting purposes. Common choices:

• Source IP
• ASN
• JA3 / JA4 TLS fingerprint
• A header value (User-Agent, Referer, custom application header)
• Combinations (Source IP + URI path, ASN + User-Agent, JA4 + URI path)

The incrementor is the dimension along which the rate is measured. A rule with the same scope but different incrementors behaves very differently. A 300 RPS rule scoped to /login and incrementing on source IP throttles individual attacking sources. The same rule incrementing on URI path counts every request to /login against the same counter, no matter where it came from – which is the failure mode in the anti-pattern section below.

Action

When the rule is triggered, the action determines what happens to the request. Common available actions for L7 rate-limit rules are:

• Block – drop the request or return a 4xx. Cheap to evaluate, but binary.
• JS challenge – return a JavaScript puzzle the client must solve. Transparent for real browsers, expensive for headless attackers.
• Cookie challenge – require a session-state cookie issued on first interaction, filtering out tooling that doesn’t maintain state.
• CAPTCHA – explicit human verification. Significant friction; reserved for high-value endpoints under sustained pressure.
• Tarpit – where supported, deliberately slow the response so the attacker’s connection pool fills up without giving a clean failure signal.

Threshold

The rate that triggers the action – covered in its own section below.

Rate Limits at L3/L4

L7 rules can’t help if the attack saturates the link before traffic reaches the application. That’s where L3/L4 rate limits do the work, usually at the scrubbing center, cloud DDoS protection, or on-prem L3/4 DDoS protection appliances.

At L3/L4, scope is typically defined by port, protocol, source/destination IP range, or traffic type. Thresholds are usually expressed in Mbps or PPS rather than RPS.

The same principle applies as at L7: scope and incrementor are separate decisions, and the incrementor matters most.

A rule scoped to port 443 with a flat PPS threshold across all traffic has the same problem as the L7 destination anti-pattern below – it shuts down the port for everyone during a volumetric attack. The correct pattern is to scope by port or protocol but increment by source IP (or another per-client attribute), so the rule throttles individual attacking sources without affecting legitimate clients sharing the same port.

Setting Thresholds Without Causing False Positives

The threshold is what most teams get wrong. Too high and the rule never fires when it matters. Too low and it fires constantly on legitimate users.

Red Button’s calibration target depends on the action:

• For block-mode rules, the threshold should produce no more than 0–1 false positives per 30 days. Blocking a real user has a visible cost, so the bar for triggering needs to be high.
• For challenge-mode rules on services where users have JavaScript-capable browsers, the tolerance is wider – 30–40 legitimate trips per 30 days is acceptable, because a real browser solves the challenge transparently.

The other principle is the relationship between scope and threshold: the tighter the scope, the lower the threshold can safely go. A rule scoped to a single login endpoint can sit at a much lower RPS than a rule scoped to the entire site, because the legitimate traffic floor inside that scope is lower and better understood. Tight scope unlocks tight thresholds. Broad scope forces broad thresholds.

This is why on high-volume services, generic site-wide thresholds tend to underperform in both directions – too loose to catch focused attacks, too tight to avoid blocking real users elsewhere.

Multi-Layer Rate Limiting

Single rules force a single tradeoff between aggressiveness and false positives. Layered rules don’t.

The pattern we used recently for a gaming company facing Hit and Run DDoS attacks combined two rules over the same scope:

• A block-mode rule with a high threshold – designed to never fire on legitimate traffic, only on the most extreme bursts
• A JS challenge rule with a much lower threshold – designed to trip on suspicious-but-uncertain bursts, where real browsers solve the challenge and continue uninterrupted

The combination gives you two levels of action. Definite bad traffic gets blocked outright. Ambiguous traffic gets filtered through a challenge that legitimate users pass invisibly. The block rule stays clean. The challenge rule does the discrimination work. Together, they catch a much wider range of attacks than either alone, with fewer false positives than any aggressive single-rule configuration. And the most important thing – these challenge rules allow the enforcement of a much lower threshold – while reducing the Mean Time To Mitigate (MTTM).

The Anti-Pattern: Incrementing on the Destination

This is the misconfiguration we see most often in the field, and it’s worth spelling out because it looks correct right up until it isn’t.

The pattern: a customer sets a rate limit scoped to a specific URL – or the entire website – and configures the incrementor as the destination itself rather than as a per-client attribute. The threshold gets set to some round number above normal traffic. Say, 300 RPS.

During normal operation, the rule sits comfortably above legitimate traffic. Nothing fires. During a real attack of 1 million RPS against that URL, the rule blocks everything past the first 300 RPS – with no way to distinguish legitimate from malicious, because the counter doesn’t separate clients. The probability that any given legitimate request gets through is roughly 300 / 1,000,200 – about 0.03 percent. More than 99.9 percent of real users get blocked.

The rule did exactly what it was configured to do. The Denial of Service was technically executed by the WAF.

We generally do not recommend this pattern during DDoS exposure. Keep the scope tied to the destination if that’s what you want to protect – but make the incrementor a per-client attribute (source IP, JA4 fingerprint, or a combination). A rule scoped to /login and incrementing on source IP lets each legitimate user through unaffected while throttling attacking nodes individually.

For a related failure mode – why even well-configured rules can underperform under distributed attacks across CDN edges – see Why Your Rate Limits Fail Under Distributed DDoS Attacks.

Final Thoughts

Rate limiting is one of the most effective controls in DDoS mitigation, and the easiest one to misconfigure in a way that looks fine on a dashboard and breaks under load.

The right rule, with the right incrementor, at a threshold calibrated against real traffic, will stop most of the attacks we see in the field. The wrong rule will cause an outage with no attacker required.

Red Button helps enterprises validate that their rate-limiting configuration actually works under realistic attack conditions – not just in vendor documentation. If your rate limits have never been tested with traffic that matches what a real attack looks like, you don’t know whether they’re protecting you or waiting to fail you.