Dan Collis-Puro

Need for Speed?
This plugin handles the wordpress/php side of a statically cached nginx-fronted wordpress (or wordpress mu) site. It makes WordPress emit an “X-Accel-Expires: 0” header when a user is logged in or has taken actions that should cause them to get a customized page on your frontend. This – along with the nginx configuration below – will ensure logged-in users aren’t impacted by your static nginx cache.
Why would you want to statically cache wordpress with <a href="http://www.nginx.org" rel="nofollow ugc">nginx?</a>
<ul>
<li>INSANE performance. Hardware that could generate 6 pages / second can now generate many thousands.</li>
<li>Low resource usage. Even on very busy servers, nginx uses only a handful of RAM.</li>
<li>Unobtrusiveness. You plop nginx in front of wordpress and that’s pretty much it. This plugin (and nginx) is all you need to make your site digg- and slashdot- proof.</li>
<li>Stability. Nginx is rock solid.</li>
<li>Faster is better. All the web gurus agree – visitors like faster sites, even when the differences are slight.</li>
<li>Do more with less. Using a frontend proxy lets you keep your heavy wordpress apaches lightly loaded, letting you handle more concurrent connections and use less RAM.</li>
</ul>
We’ve been using a caching nginx proxy at the fairly busy <a href="http://blogs.law.harvard.edu" rel="nofollow ugc">blogs.law.harvard.edu</a> since September, 2009. The results have been dramatic: we’ve halved the amount of RAM we need, doubled our outgoing network throughput (nginx is fast!) and have had essentially no significant load spikes.
Drawbacks
There are a few.
<ul>
<li>Plugins that rely on php code running on each page view won’t work properly. This is similar to wp-supercache or any of the other static caching plugins. Stats, image rotation, etc. You should implement these features via javascript or third-party services, depending. </li>
<li>You need to install and configure an nginx frontend proxy – but see the “installation” tab. It’s really not that hard.</li>
</ul>
Notes
<ul>
<li>It is completely harmless to install and activate this plugin before you’ve got the nginx side set up.</li>
<li>YOU MUST keep this plugin activated as long as you’ve got an nginx frontend proxy active – otherwise, you’ll end up caching too much of your site, and authenticated users won’t see customized pages.</li>
<li>This plugin helps speed up access for authenticated users mainly because it makes all other traffic a negligible resource drain. I suggest installing <a href="http://php.net/manual/en/book.apc.php" rel="nofollow ugc">apc</a> (or another opcode cache) and – alternatively – a wordpress object cache. Definitely install an opcode cache – leave the object cache for later. You may find you don’t need it!</li>
</ul>
<h3>The Future</h3>
This plugin could be set up to allow you to manage caching policies entirely from a wordpress control panel. We’d do this by manipulating the timeout in the “X-Accel-Expires” header based on the type of resource that’s been requested.
It’d be nice to de-cache when pages change via some call from the backend to the nginx frontend.

WordPress Nginx proxy cache integrator

Enables your blog to work properly with an nginx frontend static proxy cache. ASTRONOMICAL performance is yours!

Vladimir Kolesnikov

The plugin solves two problems:
<ol>
<li>When WordPress detects that FastCGI PHP SAPI is in use, it 
<a href="http://blog.sjinks.pro/wordpress/510-wordpress-fastcgi-and-301-redirect/" rel="nofollow ugc">disregards the redirect status code</a> 
passed to <code>wp_redirect</code>. Thus, all 301 redrects become 302 redirects 
which may not be good for SEO. The plugin overrides <code>wp_redirect</code> when it detects 
that nginx is used.</li>
<li>When WordPress detects that <code>mod_rewrite</code> is not loaded (which is the case for nginx as 
it does not load any Apache modules) it falls back to <a href="https://codex.wordpress.org/Using_Permalinks#PATHINFO:_.22Almost_Pretty.22" rel="nofollow ugc">PATHINFO permalinks</a> 
in Permalink Settings page. nginx itself has built-in support for URL rewriting and does not need 
PATHINFO permalinks. Thus, when the plugin detects that nginx is used, it makes WordPress think 
that <code>mod_rewrite</code> is loaded and it is OK to use pretty permalinks.</li>
</ol>
The plugin does not require any configuration. It just does its work. 
You won’t notice it — install and forget.
WARNING: nginx must be configured properly to support permalinks.
<h3>nginx Configuration</h3>
nginx 0.7.32 and higher:
<pre><code>server {
 server_name mysite.com;

 root /path/to/blog;

 index index.php;

 error_page 404 = @wordpress;
 log_not_found off;

 location ^~ /files/ {
 rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
 }

 location @wordpress {
 fastcgi_pass ...;
 fastcgi_param SCRIPT_FILENAME $document_root/index.php;
 include /etc/nginx/fastcgi_params;
 fastcgi_param SCRIPT_NAME /index.php;
 }

 location ~ \.php$ {
 try_files $uri @wordpress;
 fastcgi_index index.php;
 fastcgi_pass ...;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include /etc/nginx/fastcgi_params;
 }

 location ^~ /blogs.dir/ {
 internal;
 root /path/to/blog/wp-content;
 }
}
</code></pre>
Older versions:
<pre><code>server {
 server_name mysite.com;

 root /path/to/blog;

 index index.php;

 log_not_found off;
 error_page 404 = @wordpress;

 location ^~ /files/ {
 rewrite /files/(.+) /wp-includes/ms-files.php?file=$1 last;
 }

 location @wordpress {
 fastcgi_pass ...;
 fastcgi_param SCRIPT_FILENAME $document_root/index.php;
 include /etc/nginx/fastcgi_params;
 fastcgi_param SCRIPT_NAME /index.php;
 }

 location ~ \.php$ {
 if (!-e $request_filename) {
 rewrite ^(.+)$ /index.php break;
 break;
 }

 fastcgi_index index.php;
 fastcgi_pass ...;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 include /etc/nginx/fastcgi_params;
 }

 location ^~ /blogs.dir/ {
 internal;
 root /path/to/blog/wp-content;
 }
}
</code></pre>
Of course, do not forget to replace <code>...</code> in <code>fastcgi_pass</code> with the address/socket 
php-cgi is listening on and replace /path/to/blog with the actual path.
Also please note that the path in <code>SCRIPT_NAME</code> should be relative to the <code>DOCUMENT_ROOT</code> (<code>root</code> directive). 
Thus, if your WordPress blog resides in <code>http://example.com/blog/</code>, <code>root</code> is set to <code>/path.to/example.com</code>, 
 SCRIPT_NAME in <code>location @wordpress</code> will be <code>/blog/index.php</code>.
<a href="http://blog.sjinks.pro/wordpress/874-wpms-nginx-accel-redirect/" rel="nofollow ugc">Multi-Site Configuration</a>: the above configs work perfectly with WordPress MultiSite. To make downloads faster, consider adding this line to <code>wp-config.php</code>:
<pre><code>define('WPMU_ACCEL_REDIRECT', true);
</code></pre>
Need help with configuring nginx? Contact me: vkolesnikov at odesk dot com, I will try to help you.

nginx Compatibility

The plugin makes WordPress more friendly to nginx.

WordPress Nginx proxy cache integrator vs nginx Compatibility