Error Pages and Query Strings DDOS


I know this isn’t really directly related to Wordpress and/or Nginx but I have noticed even with FastCGI_Cache or W3TC running a server on a cheap host can be taken down with nothing more than random page requests that return a 404 or worse simply adding a random query string to the end of the URL. Is there any fix or recommendations on how to deal with this?


Navigate to which is a valid page for most wordpress sites, with a caching plugin/module in place it would be cashed and even a million requests after would not tax the system at all.

  1. Navigate to and you will get a 404, which will be caused after the first request but only for that page. Additional requests to other pages that don’t exist will force the php service to trigger and the caching module to have to work again. Running a script that makes requests to random pages will cause the system to eventually lock-up either the Swap Daemon or the PHP Daemon.

  2. Navigating to won’t navigate to a 404 error page but it will bypass the caching module and force the system to give you a fresh version of the page. Like above on a small server, like that which you might use on Digital Ocean, this would be disastrous at it doesn’t even require a script but instead to simple refresh a browser or send many CURL requests to the site with anything in the query string. Again causing either the Swap or PHP Daemon to lockup or even crash entirely.

I am sure more than a few of you have come across this in your testing and I am guessing someone has a fix but I wanted to be as informative as I could be in my description of the problem.


The only solutions I know:

  1. Use CloudFlare as an extra layer of proxy-cache’ing (and a CDN, for all purposes) in front of your server. Basic service is free and it will certainly filter out many attempts such as those — and because CloudFlare acts as a cache for so many millions of websites, they can quickly (and automatically) figure out potential sources of DDoS attacks and block the IPs before they hit your server. Last but not least, CloudFlare has an ‘attack mode’. When you activate it, every new access (yes, this will happen with legitimate users as well) will pause for a few extra seconds and requires active JavaScript to figure out if the person behind that request is a human using a browser or not. (It will not prevent someone from physically sitting in front of a computer and do a ‘manual’ DDoS attack, possibly with several friends doing the same thing…)

  2. Use the WordFence Security plugin. WordFence will act not only as a way to scan your website (if it was infected) but also acts as an application firewall, and, yes, it is also good at detecting harmful attacks, especially those that are targeted at brute-force attempts to guess passwords. Because it also works on millions of websites, they collect a black list which is served to everybody very quickly. And also because it sits at the application level, it has some knowledge on how people use typical attacks to WordPress servers and block them before they’re harmful. It also includes their own caching engine (you can turn it off), so it’s a multipurpose plugin. The disadvantage, of course, is that it runs on WordPress — that is, potential threats/attacks are already threatening your server, so even if you block them, you might preserve the integrity of WordPress, but you will still be wasting CPU and bandwidth in order to deal with all those attacks.

For that reason, I use both for practically all my websites. They’re not perfect nor foolproof, but both give some interesting statistics about how many attacks they have defeated, and these numbers are actually scary… even on very low-traffic websites, which I had (wrongly) guessed that hackers would have little interest.