Nginx can proxy requests using http, FastCGI, uwsgi, SCGI, or memcached. In this guide, we will discuss FastCGI proxying, which is one of the most common proxying protocols.

Nginx has become one of the most flexible and powerful web server solutions available. However, in terms of design, it is first and foremost a proxy server. This focus means that Nginx is very performant when working to handle requests with other servers.

Nginx has built-in support for fastcgi_cache but it doesn’t have a mechanism to purge cached content built-in. So we need to rely on a third-party nginx module.  Without this 3rd party module, the cache won’t be updated if you create or edit any post or page in WordPress.

I have discovered recently that the fastcgi_cache_purge function is now included in the nginx-extras package available for Ubuntu 14.04+ This eliminates the need to install the custom nginx version from the rtcamp non-standard repo, but the original instructions are still available below for those who don’t have access to the nginx-extras package.

Why Use FastCGI Proxying?

FastCGI proxying within Nginx is generally used to translate client requests for an application server that does not or should not handle client requests directly. FastCGI is a protocol based on the earlier CGI, or common gateway interface, protocol meant to improve performance by not running each request as a separate process. It is used to efficiently interface with a server that processes requests for dynamic content.

One of the main use-cases of FastCGI proxying within Nginx is for PHP processing. Unlike Apache, which can handle PHP processing directly with the use of the mod_php module, Nginx must rely on a separate PHP processor to handle PHP requests. Most often, this processing is handled with php-fpm, a PHP processor that has been extensively tested to work with Nginx.

Nginx with FastCGI can be used with applications using other languages so long as there is an accessible component configured to respond to FastCGI requests.



Check if your nginx has fastcgi_cache_purge module

If you have installed Nginx by following this guide, then support for fastcgi_cache_purge should be already there. You can test it by running following command:

nginx -V 2>&1 | grep nginx-cache-purge -o

If you see nginx-cache-purge in output then you already have it.

Otherwise, if you are on Ubuntu with default Nginx installation, you can run following commands to install nginx with fastcgi_cache_purge module.

Reinstall nginx with fastcgi_cache purge module support

sudo add-apt-repository -y ppa:rtcamp/nginx
sudo apt-get update
sudo apt-get remove nginx*
sudo apt-get install nginx-custom

If you’re running Ubuntu 16.04 LTS you can use this or download the script:

sudo sh -c "echo 'deb /' >> /etc/apt/sources.list.d/nginx.list"
sudo apt-get update
sudo apt-get install --allow-unauthenticated -y nginx-custom

Install Nginx Helper Plugin

Above step ensures that Nginx can purge a page from its fastcgi_cache selectively. But Nginx cannot automatically find out which page to purge and when to purge?

So install Nginx helper plugin from WordPress plugin repository and activate it. Apart from other features, it provides cache purging options. Just activate it, go to its settings and turn on “Enable Cache Purge” option.

Nginx WordPress Helper Purge Options

If you want more control over your cache purging rules, you can play with different purging options it provides.

Using ramdisk (tmpfs) for cached content

This step is optional. You need give Nginx a folder store fastcgi_cache content. I will recommend using/var/run on Ubuntu as its mounted as tmpfs (in RAM). If you do not have ample RAM you can pick any other location.

If you are going with RAM, make sure you check size of /var/run folder. Its generally 20% of your total RAM size.

To verify it, run command df -h /var/run. You will see output like below:

Filesystem Size Used Avail Use% Mounted on tmpfs 6.3G 364K 6.3G 1% /run

It looks like we have more than 6GB at our disposal! Our server has 32GB RAM by the way, so 6.3GB is close to 20%

Nginx Config

No matter how you are using WordPress, i.e. single or Multisite (with subdirectory/subdomain/domain-mapping) fastcgi_cache related configuration will remain similar.

Now make changes to /etc/nginx/sites-available/example.comfile so it looks like one below:
Move the first 4 lines to /etc/nginx/nginx.conf if you want to use fastcgi_cache across all sites

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
server {

	access_log   /var/log/nginx/;
	error_log    /var/log/nginx/;

	root /var/www/;
	index index.php;

	set $skip_cache 0;

	# POST requests and urls with a query string should always go to PHP
	if ($request_method = POST) {
		set $skip_cache 1;
	if ($query_string != "") {
		set $skip_cache 1;

	# Don't cache uris containing the following segments
	if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
		set $skip_cache 1;

	# Don't use the cache for logged in users or recent commenters
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1;

	location / {
		try_files $uri $uri/ /index.php?$args;

	location ~ .php$ {
		try_files $uri =404;
		include fastcgi_params;

		fastcgi_cache_bypass $skip_cache;
	        fastcgi_no_cache $skip_cache;

		fastcgi_cache WORDPRESS;
		fastcgi_cache_valid  60m;

	location ~ /purge(/.*) {
	    fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";

	location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
		access_log off;	log_not_found off; expires max;

	location = /robots.txt { access_log off; log_not_found off; }
	location ~ /. { deny  all; access_log off; log_not_found off; }

The line fastcgi_cache_use_stale is what makes caching on Nginx-side unique. This line tells Nginx to use old (stale) cached version of page if PHP crashes. This is something not possible with WordPress caching plugins.

Don’t Forget

Always sanity check your Nginx configuration files prior to reloading them. You do not need to restart the service nor kill active TCP connections to your webserver to reload the config. Issue the commands below to tell Nginx to check the syntax of all of its configuration files (nginx.conf + all related config files), followed by telling the Master process to reload the configif the syntax is ok.

$:/etc/nginx# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$:/etc/nginx# nginx -s reload


Page generated in 0.8068 seconds.
Advertisment ad adsense adlogger