Set Up Nginx FastCGI Cache to Reduce WordPress Server Response Time

This tutorial will be showing you how to set up Nginx FastCGI cache to reduce server response time for your WordPress site.

What is Nginx FastCGI Cache?

If you followed my previous tutorials about installing LEMP stack on various Linux distributions, then Nginx is configured to pass PHP request to PHP-FPM because Nginx itself is unable to process PHP code. Let me explain how a LEMP stack website works.

  1. Web browsers send HTTP requests  to Nginx, which tries to fetch the page from file system.
  2. If Nginx found PHP codes in the page, it passes the request to PHP-FPM to process the PHP codes.
  3. If necessary, PHP-FPM will query MySQL/MariaDB database to get what it needs.
  4. PHP-FPM generates a static HTML page, which is then given back to Nginx.
  5. Finally, Nginx sends the static HTML page to web browser.

Nginx is super fast when it comes to serving static HTML pages. However, PHP is known to be slow, although the latest version PHP7 is much faster than previous versions. And MySQL/MariaDB database is another performance bottleneck of LEMP stack websites.

Instead of passing the dynamic page request to PHP-FPM and let it generate HTML page every time, Nginx can cache the generated HTML page so next time it can send cached pages to web browsers, eliminating PHP and database requests.

  • This can greatly improve server response time and reduce load on PHP-FPM and database server.
  • It also allows Nginx to serve web pages when the upstream PHP-FPM or database server is down (MySQL/MariaDB is usually the first process to be killed when your Linux server runs out of memory).

FastCGI is the protocol between Nginx and PHP-FPM so the cache is called FastCGI cache.

How to Configure Nginx FastCGI Cache

Step 1: Edit the Nginx Main Configuration File

Edit Nginx main configuration file.

sudo nano /etc/nginx/nginx.conf

In the http context, add the following 2 lines:

fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=phpcache:100m max_size=10g inactive=60m use_temp_path=off;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

The first directive fastcgi_cache_path creates a FastCGI cache. This directive is only available under the http context of an Nginx configuration file.

  • The first argument specifies the cache location in the file system (/etc/nginx/cache/).
  • The levels parameter sets up a two-level directory hierarchy under /etc/nginx/cache/. Having a large number of files in a single directory can slow down file access, so I recommend a two-level directory for most deployments. If the levels parameter is not included, Nginx puts all files in the same directory. The first directory uses one character in its name. The sub-directory uses two characters in its name.
  • The 3rd argument specifies the name of the shared memory zone name (phpcache) and its size (100M). This memory zone is for storing cache keys and metadata such as usage times. Having a copy of the keys in memory enables Nginx to quickly determine if a request is a HIT or MISS without having to go to disk, greatly speed up the check. A 1MB zone can store data for about 8,000 keys, so the 100MB zone can store data for about 800,000 keys.
  • max_size sets the upper limit of the size of the cache (10GB in this example). If not specified, the cache can use all remaining disk space. Once cache reaches its maximum size, Nginx cache manager will remove the least recently used files from the cache.
  • Data which has not been accessed during the inactive time period (60 minutes) will be purged from the cache by the cache manager, regardless of whether or not it has expired. The default value is 10 minutes. You can also use values like 12h (12 hours) and 7d (7 days).
  • Nginx first writes files that are destined for the cache to a temporary storage area (/var/lib/nginx/fastcgi/). use_temp_path=off tells Nginx to write them directly to the final cache directory to avoid unnecessary copying of data between file systems.

The 2nd directive fastcgi_cache_key defines the key for cache lookup. Nginx will apply a MD5sum hash function on the cache key and uses the hash result as the name of cache files. After entering the two directives in the http context, save and close the file.

Step 2: Edit Nginx Server Block

Then open your server block configuration file.

sudo nano /etc/nginx/conf.d/your-domain.conf

Scroll down to the location ~ \.php$ section. Add the following lines in this section.

fastcgi_cache phpcache;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
fastcgi_cache_min_uses 1;
fastcgi_cache_lock on;
add_header X-FastCGI-Cache $upstream_cache_status;
  • The fastcgi_cache directive enables caching, using the memory zone previously created by fastcgi_cache_path directive.
  • The fastcgi_cache_valid sets the cache time depending on the HTTP status code. In the example above, responses with status code 200, 301, 302 will be cached for 60 minutes. You can also use time period like 12h (12 hours) and 7d (7 days).
  • Nginx can deliver stale content from its cache when it can’t get updated content from the upstream PHP-FPM server. For example, when MySQL/MariaDB database server is down. Rather than relay the error to clients, Nginx can deliver the stale version of the file from its cache. To enable this functionality, we added the fastcgi_cache_use_stale directory.
  • fastcgi_cache_min_uses sets the number of times an item must be requested by clients before Nginx caches it. Default value is 1.
  • With fastcgi_cache_lock enabled, if multiple clients request a file that is not current in the cache, only the first of those requests is allowed through to the upstream PHP-FPM server. The remaining requests wait for that request to be satisified and then pull the file form the cache. Without fastcgi_cache_lock enabled, all requests go straight to the upstream PHP-FPM server.
  • The 3rd line adds the X-FastCGI-Cache header in HTTP response. It can be used to validate whether the request has been served from the FastCGI cache or not.

Now save and close the server block configuration file. Then test your Nginx configuration.

sudo nginx -t

If the test is successful, reload Nginx.

sudo service nginx reload


sudo systemctl reload nginx

The cache manager now starts and the cache directory (/etc/nginx/cache) will be created automatically.

Testing Nginx FastCGI Cache

Reload your site’s home page for a few times. Then use curl to fetch the http response header.

curl -I

Like this:

nginx fastcgi cache test

Take a look at the X-FastCGI-Cache header. HIT indicates the response was served from cache.

Stuff that Should not be Cached

Login session, user cookie, POST request, query string, WordPress back-end, site map, feeds and comment author should not be cached. To disable caching for the above items, edit your server block configuration file. Paste the following code into the server context, above the location ~ \.php$ line.

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/*|/tag/.*/feed/*|index.php|/.*sitemap.*\.(xml|xsl)") {
    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;

Sometimes I want to test the upstream (PHP-FPM and MariaDB) response time, so I also add the following lines to tell Nginx to bypass the FastCGI cache for my IP addresses.

if ($remote_addr ~* "|") {
     set $skip_cache 1;

The tilde symbol (~) tells Nginx that what follows is a regular expression (regex). The star symbol * makes the regex case-insensitve. The vertical bar | is for alternation of several values. If the value of $remote_addr variable matches any IP address in the regex, then set the value of $skip_cache to 1.

Note that if you are using the Google XML sitemap plugin in your WordPress site, then you can probably see the following rewrite rules in your Nginx configuration.

rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;

These rewrite rules should be put below the skip cache rules. If the rewrite rules are above the skip cache rules, then your sitemap will always be cached.  Similarly, if you use the Yoast SEO plugin to generate sitemap, then you also need to move the Yoast rewrite rules below the skip cache rules.

Now in the location ~ \.php$ section, paste the following directives.

fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

The first directive tells Nginx to send request to upstream PHP-FPM server, instead of trying to find files in the cache. The second directive tells Nginx not to cache the response. Save the file and reload Nginx.

sudo systemctl reload nginx


sudo service nginx reload

How to Automatically Purge Cache with WordPress

First, you need to install and activate the Nginx Helper plugin on your WordPress site. Then to to WordPress Settings -> Nginx helper and tick on the Enable Purge box. The default purging conditions are fine all most WordPress blogs. You can also enable logging to check if purging is working correctly.

nginx fastcgi cache purge wordpress

Click the Save all changes button.

Then you need to install the http-cache-purge module on your Linux server. Run the following command to install it on Ubuntu 18.04 and above. During the installation process, a configuration file will be put under /etc/nginx/modules-enabled/ directory to enable this module.

sudo apt install libnginx-mod-http-cache-purge

You can also install the nginx-extras package to enable this module, but this package also enables many other modules. To keep my Nginx as lightweight as possible, I don’t install the nginx-extras package.

Next, open your Nginx server block configuration file. Add the following lines in the server {...} context.

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

Save and close the file. Then test Nginx configurations.

sudo nginx -t

If the test is successful, reload Nginx.

sudo systemctl reload nginx

Now you can modify one of your posts in WordPress to see if the cache will be automatically purged.

Next Step

I hope this article helped you set up Nginx FastCGI Cache with WordPress. You may also want to use Nginx Amplify to monitor LEMP stack performance. As always, if you found this post useful, then subscribe to our free newsletter to get more tips and tricks. Take care 🙂

Rate this tutorial
[Total: 12 Average: 4.3]

6 Responses to “Set Up Nginx FastCGI Cache to Reduce WordPress Server Response Time

  • Mysterion
    1 year ago

    Got it working. Thanks!

  • Mauricio Lazo
    6 months ago

    Thank you so much! I’ve been looking a simple and clear way of understanding and then enable this and your way is perfect.

  • Vladislav
    4 months ago

    IT WORKS!!!! SPEND FEW HOURS before, thank you :*

  • Yeach man! You saved my time! All the best to you!!
    Only one thing was needed to be added to settings to me:

    fastcgi_ignore_headers "Set-Cookie";
    fastcgi_hide_header "Set-Cookie";

    Because without it requests always was missed.

  • I followed the instructions exactly, but when I do the curl test, it says:
    X-FastCGI-Cache: MISS

    I also tried adding the “Set-Cookie” settings suggested by Pavel.

    How can I troubleshoot this? I use Cloudflare, but put it in Development Mode and flushed the home page cache for this test.

    Please help! Thanks!

  • Okay, turns out I had put the ignore headers (“Set-Cookie”) lines in the wrong place. They need to be outside (above) the “location ~ \.php$” block. I actually found this and am using it instead:

    fastcgi_ignore_headers Cache-Control Expires Set-Cookie;

    … WordPress installations may need it, apparently.


Leave a Comment

  • Comments with links are moderated by admin before published.
  • Your email address will not be published.
  • Use <pre> ... </pre> HTML tag to quote the output from your terminal/console.
  • Please use the community ( for questions unrelated to this article.
  • If my answer helped you, please consider supporting this site. Thanks :)