Why do per-source rate limits fail against DDoS?

Because the first D in DDoS is distributed. A limit that stops one address from making a thousand requests a second does nothing about ten thousand addresses making one each. Worse, carrier-grade NAT and large corporate egress mean a single address can legitimately represent thousands of users, so tightening the per-source limit blocks real customers before it inconveniences an attacker.

What should we limit instead?

The expensive operation. Search, report generation, login attempts, cache-missing queries and anything that reaches a database are where an application-layer attack extracts its leverage, and a limit expressed per endpoint costs an attacker far more than it costs a normal user who rarely touches those paths.

How do we choose a threshold?

From measurement, not from a default. Take your normal peak for that dimension across a period that includes a genuine business peak, and set the limit above it with headroom you can justify. Then test at the real peak rather than a quiet window — a threshold that is comfortable on a Tuesday morning is a different threshold in the busiest hour of the quarter.

Should rate limiting drop, delay or challenge?

Dropping is cheapest and least forgiving. Delaying preserves the request and pushes back on the attacker's throughput, which suits expensive endpoints. Challenging distinguishes a browser from a script but costs the user an interruption and does nothing against a client that can answer. Most designs use all three at different tiers, and the important thing is knowing which one fired when you read the logs afterwards.

Does rate limiting help against volumetric attacks?

Only upstream of the bottleneck. A rate limit applied on your own server still requires the packets to arrive, so it protects the application and not the circuit. Rate limiting as a volumetric answer only works when it is applied by the network delivering the traffic, which is the FlowSpec rate-limit action rather than anything on your side.

Mitigation technique

Rate Limiting for DDoS Defence

Last updated: August 2026 · The control most likely to bite you · Reading time ~13 min

Many hands competing for a few benches, standing for a bounded resource shared out under a limit that has to be set somewhere.

Rate limiting bounds how much of something a client, a prefix or a service may consume per unit time. It is the most widely available DDoS control and the one most likely to cause the outage it was meant to prevent, because the threshold that stops an attack at 3am is a different threshold from the one that must not stop customers at the busiest hour of the quarter.

Rate limiting is available everywhere. Every load balancer, web server, application server, CDN and firewall offers some form of it, which is why it is usually the first control reached for and the one most often mis-set.

The mechanism is trivial: count something per unit time, act when the count exceeds a threshold. Everything difficult about it is in the two choices the mechanism does not make for you — what to count, and where to put the threshold.

What to bound

Appliance	What it bounds	Works against	Fails against
Per source address	One client's share	Single-source abuse, scrapers	Distributed attacks; NAT hides many users behind one address
Per prefix	One network's share	Botnets concentrated in a few networks	Truly distributed sources; large shared providers
Per destination or service	Total load on one thing	Protecting a fragile backend	Nothing — it drops real users along with the attack
Per request type	Load on the expensive endpoints	Application-layer floods aimed at cost	Attacks that stay within the cheap endpoints

The last row is the one worth building first and the one most often built last: limiting the expensive operation rather than the client is usually both fairer and more effective.

The instinct is to limit per source address, and it is the weakest choice available. A distributed attack defeats it by construction, and carrier-grade NAT means one address can legitimately carry thousands of real users — so tightening the limit reaches your customers before it reaches the attacker.

Limiting the expensive operation inverts the economics. An attacker aiming at cost has to touch the endpoints that cost something, and a normal user touches them rarely. A limit expressed as “this many report generations per minute across the whole service” is both fairer and harder to evade than any per-client rule.

Where to apply it

Upstream, as a FlowSpec rate-limit action, is the only placement that helps with saturation, because it acts before your circuit. Everything below acts after the traffic has already arrived.

At the edge device, where connection and packet rates can be bounded without application context.

At the reverse proxy or CDN, where requests are visible and cheap to reject before they reach an origin.

In the application, where the true cost of an operation is known — the only place that can distinguish an expensive request from a cheap one with certainty.

A design that limits in only one of these places has a gap. A design that limits in all four without knowing which one fired has a debugging problem.

What it works against

Application-layer floods aimed at cost. Credential-stuffing and login floods. Scraping that degrades service as a side effect. Any abuse whose leverage comes from doing an expensive thing many times.

It also works as a containment measure while something better is arranged: a limit that keeps a backend alive at degraded service is preferable to a backend that falls over, and buys the minutes needed to divert or to escalate.

What it does not work against

Saturation, unless applied upstream. This is the recurring boundary in every technique on this site and it does not move RFC 4732.

Attacks below the threshold. An attacker who measures your limit and stays just under it extracts the maximum damage your own configuration permits. Thresholds are public information to anyone willing to probe.

Genuinely distributed low-rate attacks. Ten thousand clients making one expensive request each are indistinguishable from ten thousand customers by rate alone. That is a baselining and classification problem, not a rate problem.

Operational risk

The threshold is a business decision wearing a technical costume. Setting it is choosing what fraction of a peak you are willing to reject. That choice belongs to someone who understands what rejecting it costs.

Thresholds age. Traffic grows, campaigns launch, a new mobile app changes request patterns. A limit set once and never revisited becomes an outage waiting for a marketing email.

Shared-address blast radius. One limit applied per source address in front of a large mobile carrier’s NAT can take out a whole region’s users at once.

Silent tightening under pressure. Loosening a threshold during an incident is easy to do and easy to forget to reverse. Every change needs a timestamp and a review point.

Response-rate limiting on DNS interacts with fallback to TCP, which modern operational guidance requires support for RFC 9210 — a limiter that suppresses answers without accounting for the TCP retry can produce worse behaviour than it prevents.

False-positive risk

The highest of any technique on this site, and the one that produces outages nobody attributes to the defence. A rate limit does not distinguish between an attacker and an enthusiastic customer; it distinguishes between a rate and a number you chose.

The mitigation for that is measurement rather than caution. Record the rejection rate as a first-class metric alongside the attack-blocked metric, review it at business peaks, and treat a rise in rejections during normal traffic as an incident in its own right.

How to verify

Measure normal peak for the dimension you intend to limit, across a period including a real business peak.
Set the threshold with stated headroom and write down the reasoning.
Replay legitimate traffic at that peak with the limit engaged and measure what fraction is rejected.
Probe from a single source to confirm the limit fires where you think it does.
Confirm the logs tell you which tier rejected a request — edge, proxy or application.
Set a calendar review, because the threshold will be wrong within two quarters.

Sources

Frequently asked questions

Why do per-source rate limits fail against DDoS?: Because the first D in DDoS is distributed. A limit that stops one address from making a thousand requests a second does nothing about ten thousand addresses making one each. Worse, carrier-grade NAT and large corporate egress mean a single address can legitimately represent thousands of users, so tightening the per-source limit blocks real customers before it inconveniences an attacker.
What should we limit instead?: The expensive operation. Search, report generation, login attempts, cache-missing queries and anything that reaches a database are where an application-layer attack extracts its leverage, and a limit expressed per endpoint costs an attacker far more than it costs a normal user who rarely touches those paths.
How do we choose a threshold?: From measurement, not from a default. Take your normal peak for that dimension across a period that includes a genuine business peak, and set the limit above it with headroom you can justify. Then test at the real peak rather than a quiet window — a threshold that is comfortable on a Tuesday morning is a different threshold in the busiest hour of the quarter.
Should rate limiting drop, delay or challenge?: Dropping is cheapest and least forgiving. Delaying preserves the request and pushes back on the attacker's throughput, which suits expensive endpoints. Challenging distinguishes a browser from a script but costs the user an interruption and does nothing against a client that can answer. Most designs use all three at different tiers, and the important thing is knowing which one fired when you read the logs afterwards.
Does rate limiting help against volumetric attacks?: Only upstream of the bottleneck. A rate limit applied on your own server still requires the packets to arrive, so it protects the application and not the circuit. Rate limiting as a volumetric answer only works when it is applied by the network delivering the traffic, which is the FlowSpec rate-limit action rather than anything on your side.

Sources

RFC 4732 — Internet Denial-of-Service Considerations
IETF · 2006-11 · standard · accessed 2026-08-15
RFC 9210 — DNS Transport over TCP: Operational Requirements
IETF · 2022-03 · standard · accessed 2026-08-15
Relevant to response-rate limiting on DNS, where the countermeasure and the fallback transport interact.

Published: August 2026 · Last reviewed: August 2026

Reviewed means the sources above were re-read on that date; the text is only reissued when something material changed.

This guide is updated as vendors release new models and pricing. How we compare vendors