Optimizing Apache Configuration for WordPress Under Attack

How We Tuned Apache to Survive Bot Storms on a WordPress Server

When your logs show scanner traffic all day and Apache starts throwing AH00161: server reached MaxRequestWorkers, you’re not just fighting performance. You’re fighting availability.

We recently tuned Apache on a production WordPress host running mpm_prefork + PHP, and the goal was simple: keep the site responsive under bursty, low-value traffic.

The Problem We Saw

• Continuous automated probes against WordPress and common vulnerability paths.
• Periodic worker exhaustion.
• Too many connections sitting around too long during bot waves.

The Tuning We Applied

In Apache config:

# /etc/apache2/apache2.conf
Timeout 60
KeepAliveTimeout 2

# /etc/apache2/mods-enabled/mpm_prefork.conf
MaxRequestWorkers 180
MaxConnectionsPerChild 2000

Previous values were:

• Timeout 300
• KeepAliveTimeout 5
• MaxRequestWorkers 150
• MaxConnectionsPerChild 0

Why These Changes Matter

1) Lower Timeout reduces worker hostage time

A 300-second timeout is very forgiving for slow or abusive clients. In hostile traffic, that means workers get pinned too long. Dropping to 60 seconds reclaims workers faster.

2) Lower KeepAliveTimeout frees idle sockets quickly

Keep-Alive is useful, but idle keep-alive connections during bot spikes can starve real requests. Moving from 5s to 2s helps concurrency.

3) Higher MaxRequestWorkers raises burst capacity

If traffic is legitimate or unavoidable, you need more headroom before hitting worker ceiling alarms.

4) Non-zero MaxConnectionsPerChild controls memory creep

In prefork, long-lived processes can grow over time. Recycling workers after a fixed number of requests helps keep memory behavior predictable.

What This Does Not Replace

Apache tuning is not a security control by itself. You still need:

• Edge filtering and rate limiting (Cloudflare WAF/rules).
• Fail2Ban and IP reputation controls.
• Firewall policy hygiene.
• WordPress hardening for wp-login.php, xmlrpc.php, and probe paths.

How to Roll This Out Safely

1. Back up current config files.
2. Apply one change set at a time.
3. Run apache2ctl configtest.
4. Reload Apache (prefer graceful reload).
5. Monitor AH00161, 5xx rate, memory usage, and response time.

Final Takeaway

Under persistent scanner traffic, tuning connection lifetimes and worker limits gives Apache breathing room. It won’t stop attacks, but it helps keep your WordPress service stable while your security layers do their job.

Further reading: WordPress XML-RPC Docs

Related posts:

• 5 ways to use Cloudflare service to protect your website
• One of the most useful WordPress plugins I've come across is…

Related: learn more about our WordPress operations approach, layered security for repeated attacks, or contact us for support.