You’ve got rate limiting turned on, blocking IPs that send too many requests, and your server still goes down the moment a real attack hits. It’s not that rate limiting doesn’t work — it’s solving a different problem than the one attacking you.
What IP-based rate limiting does well
Counting requests per IP and blocking whoever crosses a threshold works great against a single attacker: someone running a brute-force script against your login, or an aggressive scraper hitting from one machine. In that scenario, cutting off that one IP solves the problem instantly.
Why it fails against a real DDoS
A botnet isn’t one IP, it’s thousands
A distributed denial-of-service attack (DDoS) doesn’t send all its traffic from a single source — it spreads it across hundreds or thousands of different machines, each making relatively few requests. If your rule is “block after 50 requests per minute from the same IP,” a well-distributed botnet never hits that threshold on any single IP, even while the combined total is taking your server down.
Every new IP starts its counter at zero
Even if you block each IP the moment it crosses the line, the attacker just keeps adding new ones. IP-based rate limiting is built to stop a single abuser, not to recognize that the site’s total traffic has spiked because of a coordinated attack.
What a purpose-built mode does differently
Counting global traffic, not by source
Instead of watching each IP separately, this approach measures how many requests the site is receiving in total over a short window. If that total exceeds what’s normal for your site, it triggers a response — without needing to first identify which of the thousands of IPs is “the culprit,” because there isn’t just one.
A lightweight challenge instead of taking the server down
When global volume spikes, instead of letting every single request fully execute WordPress (database query, plugin loading, and all), a small challenge is served — one a normal browser solves instantly, but that stops most automated traffic before it ever consumes real server resources.
What this kind of protection doesn’t replace
It’s worth being honest about the limits: this layer is built to protect the site’s regular pages against a massive traffic spike, not to shield forms, payments, or the API on its own — those routes need their own dedicated protection, precisely because you don’t want to interrupt a real purchase halfway through with a challenge.
Frequently asked questions
Is IP-based rate limiting still useful, then?
Yes, it’s still valuable against brute-force attacks, aggressive scraping, or abuse from a single source — it just isn’t the right tool against an attack distributed across thousands of IPs.
Do I need both running at the same time?
They complement each other: IP-based rate limiting covers individual abuse, and a global traffic layer covers the scenario where no single IP stands out but the site’s total does.
Can a DDoS attack take down any WordPress site without dedicated protection?
Yes — without any layer measuring total volume, WordPress processes every request individually (database included), and a high enough volume exhausts server resources even if each request looks harmless on its own.