Retina “@2x” 404’s Killing Your Site? Here’s a Quick Fix!
I woke up the other day to find one of my sites had made it onto Reddit (yay) and a pretty decent stream of traffic by my standards. I think that site ended up with over 50,000 page views for the day, when it usually gets around 10-20k.
When I went into WordPress to try to add some new content, I noticed things were moving very sluggishly, which I attributed to the spike in traffic. I popped over to cPanel and WHM to see what the server load was, and it was sitting menacingly in the high 40’s, which – even with that kind of traffic – should not have been anywhere near that number. Thus began my quest to fix the problem.
DDOS Attack?
My first thought was that the link on Reddit must have prompted someone to launch a DDOS attack, because I was getting tons of 404 errors. Even my host’s tech support suspected an attack. So they adjusted some firewall settings, and I went to see what I could do to minimize the damage.
First I went over to CloudFlare and set it to “Under Attack” mode, which has worked brilliantly for me in the past. This time, however, the 404’s continued to pile up. How was this bogus traffic still getting through?
I then loaded up my WordFence Security plug in – which has also proven invaluable in the past – and changed the settings to be as aggressive as possible. The 404’s were coming in so quickly that WordFence couldn’t block IP’s fast enough. And why were they even getting through when I had CloudFlare set to Under Attack mode anyway?
Note to self: Turn off or limit WordFence’s email notifications the next time this happens. Getting a few thousand emails for every blocked user didn’t help matters!
I tinkered with settings until I pretty much gave up… when I noticed on WordFence’s “Live Traffic” screen that virtually all of my 404 errors were looking for images with “@2x” inserted just before the extension (so while filename.jpg did exist, I was getting 404s for [email protected], which didn’t exist).
@2x 404 Errors
Not being much of a techie, this “@2x” file type wasn’t familiar to me, so my first assumption was that this may have been some method employed by DDOS attackers. Of course now I realize that was a wrong assumption, and that the @2x files are merely related to retina displays. It slowly began to dawn on me that I wasn’t under attack at all, but I was being flooded with 404’s related to non-existent retina files. That’s why CloudFlare and WordFence weren’t stopping the attack – because there was no attack.
So now that I figured out the problem, how would I fix it?
My first thought was to grab an app to batch rename files and just upload “@2x” versions of all of my files. On this particular site, it wasn’t too hard, since there are only about 300 graphics total. That seemed to slow down the 404s considerably, but I noticed a few new ones kept getting through.
Then I checked my oldest and largest website, and saw a small number of “@2x” 404’s occurring there as well. That’s when I knew that uploading new versions of all graphics would be completely unrealistic, as that site had thousands of images dating back 8 years.
I tried installing a plugin called WP Retina 2x, which seemed like it might be the quick fix I wanted. After tinkering with it, however, I found that most of my graphics were “too small” and could not generate retina-friendly versions. That plugin may work in some instances – and actually probably be useful for me moving forward – but it didn’t help in the case of my larger site, as it showed over 3200 graphics that it couldn’t fix automatically.
.htaccess Code
Finally, thanks to some unnamed saint over at Quadra Hosting, I found a much simpler solution: Code in the .htaccess file which simply redirects those pesky @2x requests.
That code, to be placed before any WordPress rules is:
#QH MOD BEGIN
#This block of code needs to go above your WordPress rules
<IfModule rewrite_module>
#This is to short circuit non existent Retina image requests generated by retina.js
# without this, the whole wordpress 404 stack will be executed which is very expensive
# We simply redirect the request to the non @2x version of the file, if one exists, otherwise, send a 404 status
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} @2x\.[a-z]+$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)@2x(.*)$ $1$2 [E=QHNORETINA:1]
RewriteCond %{ENV:QHNORETINA} 1
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* – [L,R=404]
</IfModule>
#QH MOD END
Be sure to back up your htaccess file before messing with it, but I found the code worked flawlessly on both sites. The stream of 404’s vanished, and my server load currently sits below 1.0.
I realize that some people may tell me to simply disable retina support in my theme, but there was no way to do this automatically for my theme, and I don’t feel comfortable messing around with the theme’s code unless it’s absolutely necessary. I considered contacting the theme developer, but found the above code before I reached out to them. That could still be a viable solution in some cases.
Obviously the ideal solution would be to have properly-formatted Retina-friendly graphics on your site, which I have started to keep in mind as I move forward. For older sites with thousands of graphics, or small graphics with no need for retina support, the htaccess code above could save you a major headache down the road.
Have you had this problem? What was your solution?
I’m having the exact same issue. I too tried going with WP Retina first. Didn’t work. I didn’t try your htaccess method yet since I don’t have access to FTP at the moment. Any idea what could have caused this? It didn’t happen before, why all of a sudden?
Dude You Rock!!!!! That worked perfectly!