WordPress Application-Layer DDoS Protection: Progressive Rate Control for Expensive PHP Traffic
Aegisify WAF 1.20.13 tracks request pressure by source and WordPress traffic group, then escalates from browser challenge to HTTP 429 rate limiting and temporary blocking as configured thresholds are crossed. It is designed for application-layer floods that reach WordPress/PHP—not as a replacement for edge or network-level volumetric mitigation.
A login flood, XML-RPC burst, REST surge, search storm, and ordinary page traffic consume different resources. Aegisify applies separate thresholds so expensive surfaces can be defended more aggressively.
How the DDoS Engine Responds to Repeated Requests
The current engine uses one-minute source counters and endpoint-group thresholds. It escalates only when traffic crosses the configured levels for that group.
Click a stage to expand
01GroupIdentify the surface
02CountSource + group
03ChallengeFirst escalation
04Rate LimitHTTP 429
05Temporary BlockHTTP 403 + cooldown
06InvestigateVisuals + Attack Story
Different WordPress Surfaces Receive Different 60-Second Thresholds
The defaults show the intended risk model. Administrators should tune them against real application traffic before making them more aggressive.
300 / 420 / 600
Ordinary traffic uses challenge, rate-limit, and block defaults of 300, 420, and 600 requests per minute per source. This is the broadest request group.
20 / 35 / 60
wp-login.php uses materially lower thresholds because repeated authentication requests are expensive and frequently abused.
5 / 8 / 12
XML-RPC has the tightest default profile. Sites that intentionally depend on XML-RPC should validate expected clients before enabling aggressive enforcement.
80/120/180 and 120/180/260
wp-admin defaults to 80/120/180, while admin-ajax.php defaults to 120/180/260. Authenticated users can be excluded from DDoS checks with the default ignore-logged-in setting.
160/220/320 and 25/40/70
REST allows more traffic by default, while wp-cron.php uses lower thresholds. Integrations and background jobs should be tested because legitimate automation may generate bursts.
35/55/90 and 40/60/90
Search and cache-bypass query patterns receive lower thresholds because they can force dynamic PHP/database work that bypasses ordinary page caching.
Rate Enforcement Depends on Shared Counters
A request-rate control must see consistent state across PHP requests.
Aegisify uses a supported shared counter backend for DDoS state. The current implementation recognizes a compatible persistent WordPress object cache or APCu, with an integration filter available for another supported implementation. If no shared backend is available, the DDoS engine does not pretend that per-minute counters are working.
This matters on multi-process PHP environments because process-local memory is not enough to provide reliable cross-request counting. Administrators should confirm the counter backend shown by the WAF before relying on application-layer rate enforcement.
Tighten Thresholds During an Active Application-Layer Flood
Emergency Mode reduces configured thresholds without requiring every group to be edited individually.
Reduce Thresholds as a Group
The default emergency multiplier is 0.50, which halves the configured challenge, rate-limit, and block thresholds. The implementation bounds the multiplier between 0.10 and 1.00.
Avoid Collapsing to Zero
Emergency thresholds retain minimum floors. The default minimums are 3 requests for challenge, 5 for rate limiting, and 8 for blocking, preserving a progressive order even when normal thresholds are sharply reduced.
Use Emergency Mode Temporarily
Emergency Mode is an incident control, not a permanent tuning shortcut. After the event, review DDoS evidence, restore normal thresholds, and determine whether a narrow group requires a durable change.
Protect Known Operations Without Hiding Attack Traffic
Exceptions should be narrow because broad allowlists can defeat rate controls.
Ignore Logged-In Users Where Appropriate
The default configuration excludes authenticated users from DDoS checks. This can reduce administrative friction, but it should not be treated as a substitute for authentication security.
Use IP or CIDR Allowlists Carefully
Trusted infrastructure can be excluded by specific IP or CIDR. Keep entries narrow and review them periodically because allowlisted sources bypass this DDoS decision layer.
Review Temporary Blocks Centrally
DDoS blocks are registered with Aegisify WAF’s temporary block system so administrators can review active sources, release an incorrect block, or promote a source into a separately managed permanent block when warranted.
Use the Dashboard to Tune Thresholds Against Real Traffic
The current DDoS page includes four visual perspectives on enforcement pressure.
Use Progressive Rate Control Where PHP and Database Work Is Most Expensive
Validate the shared counter backend, review expected traffic, and tune login, REST, search, AJAX, cron, and other thresholds deliberately.
Common Questions About Application-Layer DDoS Protection
Does Aegisify stop volumetric network DDoS attacks?
No. Aegisify WAF handles request pressure that reaches WordPress/PHP. Keep edge, CDN, reverse-proxy, hosting, and network mitigation for bandwidth saturation and attacks that should be stopped before PHP.
What happens if no shared counter backend is available?
The DDoS engine cannot make reliable per-minute decisions from its built-in shared counter path. Confirm a supported persistent object cache, APCu, or supported integration before relying on this layer.
Why are XML-RPC and login thresholds lower?
They are high-value, frequently abused WordPress surfaces where repeated requests can consume authentication or application resources. If the site legitimately depends on those interfaces, tune against real traffic before enforcement.
Should Emergency Mode stay enabled?
Normally no. It is designed to tighten thresholds during active pressure. After the event, return to normal policy and make any long-term threshold change based on evidence.
How can Aegisify AI help?
Ask about Aegisify or WordPress: errors, plugins, security, SEO, compatibility, troubleshooting, comparisons, or launch a free website scan.