Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

At the end of January we noticed a spike in traffic to what JetPack stats says was home/archive page and what Google was classifying as going to /gaming/ which is an archive list in WordPress.

This started off as ~3,000 unique visitors and jumped up to 65,000 unique visitors in one day, again all to the "home" page. This happened over a course of a couple of weeks and we thought we were getting attacked.

The traffic then dropped off for a few days but then came back but came back as only about ~15,000 uniques a day and has been like that every day since. We came to the conclusion that something wasn't tracking right somewhere and this is legitimate traffic and brushed it off.

Now here comes the problem, Google AdSense has just disabled our account for "invalid clicks". We are trying to figure out where this traffic is coming from and stop it if it's not legitimate or figure out a way to track it correctly.

Specs for the site: Dedicated server running CentOS 6 with nginx, php-fpm and MySQL. The site is built in WordPress and we use CloudFlare and W3 Total Cache. Analytics being used are Google Analytics, Quantcast, Alexa and Compete.

Any kind of help would be awesome.

UPDATE: I'm finding more people with the same type of problem and there doesn't seem to be a solution.



After looking at the access logs I noticed they were all CloudFlare IP's. I looked into that and found out CloudFlare acts as a proxy and there was a way to fix the logs in nginx. They are coming from many different ISP's in the US. They are going to /games/ or /gaming/ (/games/ redirects to /gaming/) and all seem to have the same user agent of Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0).

share|improve this question
I suspect you'll get better answers on webmasters.SE. –  Michael Hampton Aug 18 '12 at 20:30
Do you have access logs? The first step to finding where the requests come from is to look at the logs. –  Shane Madden Aug 18 '12 at 20:31
Did you have a look at webserver logs? –  user130370 Aug 18 '12 at 21:19
Ok, after looking at the access logs I noticed they were all CloudFlare IP's. I looked into that and found out CloudFlare acts as a proxy and there was a way to fix the logs in nginx. So I will be monitoring the logs to see what the actual IP address is now. –  kel Aug 18 '12 at 21:20
I'm looking at the logs and they are coming from many different ISP's in the US. They are going to /games/ or /gaming/ (/games/ redirects to /gaming/) and all seem to have the same user agent of Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0). What should I be looking for? –  kel Aug 18 '12 at 21:27

3 Answers 3

up vote 1 down vote accepted

Yup I've had this problem for quite some time with a different user agent.

We just learned to live with the traffic ... if you want to keep the bad page views out of your google analytics or otherwise suspend certain services like adsense for them (we certainly did) you can find out more about doing that here:


There is basically no good server side solution to this -- the solution above is based on click and mouse-move detection in the browser, and so far that's the only good way to tell good traffic of this sort from bad.

Good luck y'all!

share|improve this answer

Sounds like your site may be compromised, esp. if your AdSense has been suspended. Register for Google's Webmaster Tools and see if it reports any malware. Run the site through Sucuri's Sitecheck, too. Install the WordPress Exploit Scanner plugin for a quick check, then consider diffing your site against a clean copy of v3.4.1 and doing the same for your plugins and themes (including the twentyten & twentyeleven directories, which are a common hideout for malware files). I see a lot of sites getting owned via insecure plugins with third-party libraries like timthumb, so it's definitely a vector to be aware of.

Put some sort of protection in place for /wp-login.php, all the WordPress sites I admin get regular automated brute-force attempts against them, so if any of your users' passwords are weak you can be vulnerable there. I tend to protect this location in my nginx configs by limiting IP ranges for logins (if the clients permit), rate-limiting with limit_req_zone and/or installing plugins such as login-lockdown, Duo's Two-factor Auth or Google Authenticator for WordPress. I've seen hacks where the spammer will get an admin login to a blog and then alter the content, rather than trying to own the box, often with the objective of utilising a site's Pagerank to get a linkback boost.

If you've ruled out any sort of hack of your site and you're still getting malicious visitors deliberately trying to subvert the clicks on your ads, something that screens and bans them before they have a chance to will ameliorate matters. The Bad Behaviour plugin will do this and may be suitable (though it's rather agressive, so keep an eye on its ban list and whitelist generously where applicable) or, if you want to do it at a lower level, take a look at naxsi for nginx or fail2ban.

share|improve this answer
Bad Behavior is my code. As far as I know it's very conservative in what it blocks. Though you can make it more aggressive by enabling strict mode. –  Michael Hampton Aug 19 '12 at 3:07
@Stef Pause, no malware reported from GWT, Sucuri shows good. I run WordPress exploit scanner every week. I'm also connected with VaultPress. I've update the post with links of people having the same issue though. –  kel Aug 19 '12 at 4:59
@MichaelHampton, I have Bad Behavior installed but not active. Reason was a while ago there was conflict with Google +1 buttons. It looks like that's been resolved so I just reactivated it. –  kel Aug 19 '12 at 5:01

Very simple. Simply open up index.php in the root directory and add this to the beginning:

$useragent = $_SERVER['HTTP_USER_AGENT'];

if ($useragent == "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)")
    header("Location: http://www.google.com/");

Since all these are coming from different IP addresses, it isn't practical, realistic, or time-efficient to block the IP addresses. But since they all have the same user agent, you can just block that instead. This simply redirects anyone with that user agent to Google. The only possible downside I can think of is that if any legitimate visitor has this same user agent, they will also be redirected to Google. To solve this, instead of redirecting to Google, you can make them enter in a CAPTCHA or something.

Thanks @Oerd for adding the essential exit/die statement.

share|improve this answer
An exit() or die() should go after your header(...) line. You need to make sure that code below won't execute if request has been redirected. You cannot be sure that these "attacking" bots will behave according to HTTP standards. –  Oerd Dec 5 '12 at 22:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.