🛡️ DDoS Resilience Mode

What is this and how is it different from Rate Limiting?

DDoS means "Distributed Denial of Service": many different computers (sometimes thousands, in a "botnet") attack your site at the same time to overload it and take it down.

🐘 Why WordPress is an especially easy target

A static file (an image, a PDF, a plain HTML page) is served directly from disk: the server reads it and sends it, no thinking involved. A WordPress page doesn't work that way. Every visit forces PHP to start from scratch: load the WordPress core, active plugins, the theme, and run several database queries (MySQL) to assemble that specific page with its products, comments, or menu. That turns every request into CPU and database work, not just bandwidth.

That's why a server that could easily handle thousands of requests per second for a static file can start failing with just a few dozen or a few hundred requests per second to uncached WordPress pages: the database hits its connection limit long before the network connection saturates. When that happens, the site stops responding even for real visitors, even though the attack may involve a relatively modest number of requests compared to a classic network-level DDoS.

⚖️ Why isn't Rate Limiting enough?

Rate Limiting counts requests per IP: if one IP goes over the limit, that IP gets blocked. But in a real DDoS, the attack doesn't come from 1 IP — it comes from hundreds or thousands of different IPs at once. Each new IP starts its own counter from zero, so it never exceeds the individual limit, and the attack goes unnoticed.

🧮 How does this solve it?

Instead of counting per IP, it counts the TOTAL traffic to your site (all IPs combined). If that total spikes, "flood mode" activates: every new visitor (regardless of IP) is asked to solve a small math calculation via JavaScript before being allowed to see the page.

✅ For a real visitor: it solves itself automatically, in under a second, without them noticing. For an attack bot (no JavaScript engine): it never answers correctly and is kept out, no matter which IP it comes from.

How it works internally

SeenSecure counts how many requests the whole site receives in short time windows.
If that total exceeds the configured threshold, "flood mode" activates for a minimum time (cooldown), so the challenge doesn't turn on and off constantly if traffic hovers right at the limit.
While flood mode is active, every new visitor receives the verification page instead of the real page, until they solve the calculation (automatically, via JavaScript).
Once verified, the visitor can browse normally for the configured time (pass duration) without being asked again.

💥 Real example: a botnet of around 4,000 different IPs suddenly fires 15,000 requests/minute at the homepage of a WordPress store with no full-page cache. Each of those requests runs PHP and several SQL queries to assemble the cart, menu, and featured products. Within seconds, MySQL hits its simultaneous connection limit and starts returning 500 errors — not just to the bots, but also to real customers who were shopping at that moment. With DDoS Resilience Mode active, SeenSecure detects that the site's total traffic exceeds the configured threshold (say, 15,000 requests/min against a 600-1000 limit) and activates flood mode: new visitors receive the lightweight verification page instead of the real WordPress page, a page that touches neither full PHP nor the database. The attack bots, with no JavaScript engine, get stuck there without generating real load; pressure on MySQL drops within seconds and the store responds normally again for customers who do solve the verification.

🔒 You never get locked out of your own site: administrators who are already logged in, IPs on your Whitelist, and wp-admin/login/cron never see the challenge, no matter what happens with traffic.

Settings in this section

Threshold (requests/min for the whole site)

The TOTAL traffic level from which a possible attack is assumed. Start high (600-1000) and lower it only if your site suffers real attacks; setting it too low can trigger the challenge during normal traffic spikes (e.g. going viral on social media).

Pass duration (minutes)

How long a visitor who already solved the calculation can keep browsing without being asked again.

Cooldown (minutes)

Once activated, how long flood mode stays on after traffic drops, before switching off by itself. Prevents it from turning on and off constantly if traffic hovers right at the limit.

💡 Recommendation: leave it disabled if you have never suffered this kind of attack. Enable it only if your site has gone down from a sudden traffic overload, or as a precaution if you are expecting a spike (launch, campaign, going viral).

What it does NOT do (honest limitations)

It does not protect forms, payments, or API calls (non-"GET" requests) — interrupting them midway would be worse than the attack itself, so they are let through without checking.
It does not replace a CDN (like Cloudflare) against network/connection-level attacks — this protects at the application level (web pages), not raw network traffic.

⚠️ No challenge is 100% foolproof: this mechanism filters out the vast majority of generic flood bots (those that don't execute JavaScript), but a very dedicated attacker who specifically studies your site could, in theory, reproduce the calculation without executing JS. For the real case of a small-to-medium WordPress site, this is a solid, honest improvement, not a promise of total invulnerability.

❓ FAQ — Frequently Asked Questions

🔹 Should I always have this enabled?

Not necessary for most sites. Enable it if your site has already gone down from sudden traffic overload, or preventively before an event you expect to generate heavy traffic (launch, ad campaign, going viral).

🔹 Could it block my real customers during a sales spike?

It doesn't block them — it asks them for a second of automatic verification (invisible to them) before showing the page, only while flood mode is active. A real customer with a normal browser passes without noticing. It's more likely to trigger flood mode during a legitimate traffic spike if the threshold is set too low — that's why starting high (600-1000 requests/minute) is recommended.

🔹 Where do I enable this in the dashboard?

Under Firewall → Rate Limiting, in the "🛡️ DDoS Resilience Mode" card (right below the "🚀 Front Line" card). Available on the FREE plan, no PRO required. Don't confuse the two cards: "Front Line" runs BEFORE WordPress even loads and keeps working even if the database is overloaded, while "DDoS Resilience Mode" runs INSIDE WordPress with a configurable per-minute threshold. They're independent of each other, and it's recommended to keep both enabled.

💡 Tip: if you're launching a campaign you expect to be very popular, temporarily raise the threshold (or disable the mode) during the event, and re-enable it afterwards.