“WP Fastest Cache” Configuration for Nginx

Wordpress Nginx WP Fastest Cache Configuration


This article only covers the configuration part of Nginx. If WP Fastest Cache isn’t already installed, and if you are completely new to either Nginx or WP Fastest Cache, then DO NOT read beyond at this point, as it’s not worth the time. This article is for those who have a working Nginx web server, a working wordpress site where WP Fastest Cache is installed, but not configured to work with Nginx.


I have been using many cache plugins for wordpress ever since I started using wordpress platform for writing blog articles, but I didn’t like anything so far except WP Fastest Cache. Unlike the other cache plugins, WP Fastest Cache has been working fine from the beginning smoothly without any problems and without bloating its source codes. Even though it has less features compared to W3 Total Cache, WP Total Cache, it is sufficient for me, and is extremely lightweight for the server. This whole things made me to stick with WP Fastest Cache from the beginning, and didn’t make my mind to leave it and look for another even when I changed the web server to Nginx.

The plugin stated in its FAQ section, it supports to Nginx, but it turned out it only supports when Nginx is setup as a proxy server for Apache, where Nginx works in the front-end, meanwhile the apache does all the heavy dynamic content processing while sitting in the back-end. I contacted author and asked from him how to make this plugin works with Nginx, as you might have guessed, he stated the same thing what I also found through another reply as stated earlier. This almost made me to give up on WP Fastest Cache, and look elsewhere, but I couldn’t leave it due to its uniqueness and performance. Even though while I had been searching, I could find a working code, it wasn’t enough for me as it  doesn’t cover certain conditions. so I decided to write my own code, and test it in my own server to see how it turns out. With a load of trials and errors, finally I could produce something working, optimized, and almost equal to its apache counterpart.

Code Snippet

Copy and paste the following code snippet in the server { } block of “default” file (or whatever the file is being used) located in /etc/nginx/sites-enabled/. Make sure to remove the existing location / { } block before using the one in the following code snippet.

server {
  listen 80;
  root /var/www/html;
  index index.php index.html index.htm;
    set $condition '';
    if ($request_method = POST)
      set $condition "null";
    if ($query_string)
      set $condition "null";
    if ($http_cookie ~* (comment_author|comment_author_|wordpress_logged_in|wp_woocommerce_session))
      set $condition "null";
    set $fullurl '/wp-content/cache/all${condition}';
  location / {
    set $serve_URL $fullurl${uri}index.html;
    add_header Nucuta-Cache-Location $serve_URL;
    try_files $serve_URL $uri $uri/ /index.php$is_args$args;

  location ~* \.(css|gif|ico|jpeg|jpg|js|png|woff|woff2|ttf|ttc|otf|eot)$ {
    expires max;
    log_not_found off;


Explanation of Code Snippet

  • It creates a variable and assigns nothing to its container.
  • It checks for the the request_method, and if it’s POST, it sets the aforesaid variable – condition to null, which is just a string NOT a boolean.
  • In the next block it checks for query string, such as anything that comes after ? in a link (in youtube ?v=_lx9pZbhAhc). It checks for the presence of any query string, meaning when there is a query string in the URL, it sets the condition to null.
  • In the next block, it checks for the cookies, which is useful to ignore logged in users/admins/people who made comments/if it’s an e-commerce website, then customers. Basically if request header contains one of these cookie names, it sets the condition variable to null, implying the users who sent such requests are ignored from serving cache files. ~* operating means, it doesn’t strictly checks cases, meaning it works in case-insensitive ways (no uppercase and lowercase difference when checking). Logged off state is also taken into consideration, meaning if an user logged out , and starts using the same browser for exploring the site, they are served the cached contents just as to a guest visitor.
  • In the last block before the “CACHE” comment, It creates another variable and names it $fullurl, and assigns itself the path where the cached files are stored (generated HTML files), in my server since the cache files are stored in “/var/www/html/wp-content/cache/all/” , that path is used. Here cached contents means generated HTML files from PHP pages, and thus no database call, PHP engine is used.
    The $condition variable in the same line is for triggering an artificial 404 state if the given conditions are met. As an example, if an logged in user visited the site, the $fullurl’s path returns as /var/www/html/wp-content/cache/allnull, since it doesn’t exist, a fresh content is served to that particular user (PHP is called)
  • Make sure to enable gzip in /etc/nginx/nginx.conf in your server as well to compress static files on the fly to reduce the download time. text/html also known as HTML files are compressed by default without even mentioning the gzip_types directive. Please refer this article for more information.
    Again another variable is created $serve_URL and is assigned with $fullurl${uri}index.html. This is quite useful when debugging the code. In the production environment, it’s advised to comment it out.

Mechanism and try_files

The basic logic here is, if none of the above conditions are met, $condition variable is nothing, and thus the $fullurl  is simply “/var/www/html/wp-content/cache/all” as it is supposed to be, but if at least one condition is met, it turns out to be /var/www/html/wp-content/cache/allnull. Finally in the location block, try_files directive is used to serve contents depending on their availability. First it tries to serve $firsturl which is declared in the server block, as explained early, If at least one condition is met, it comes out as /var/www/html/wp-content/cache/allnull/index.html , leading to throw 404 error, but since try_files directive is used, it passes to the next order which is /index.php$is_args$args, meaning let the wordpress to take care of the request, meaning serve a fresh content. Basically, if cached files are not available fresh contents are served, otherwise cached files are served. Fresh contents require access to database, and utilize PHP; hence it costs CPU, and RAM, but cached contents virtually cost nothing, since the webserver is Nginx, contents are just HTML files, serving rate is extremely high. This tremendously decreases the page loading time, and improves the conversion, and retention rate.

In $fullurl${uri}index.html, when an user requests a content of the root folder, $uri returns as “/”, if it to either a post or a page, then it would be “/<post or page name>/” (as an example /how-to-change-your-wifi-password/ in (ignore the double quotations).

Relative to root path /var/www/htmlIf none of the conditions are metIf at least one of the condition is met
Request to root/wp-content/cache/all / index.html/wp-content/cache/allnull / index.html
Request to a page/wp-content/cache/all /<page name>/ index.html/wp-content/cache/allnull /<page name>/ index.html
Request to a post/wp-content/cache/all /<post name>/ index.html/wp-content/cache/allnull /<post name>/ index.html

In try_files directory, after $serve_URL, use $uri if you intend to serve any file format other than html/php, use $uri/ if you intend to serve directories, be aware that if directory listing is enabled, any request to such directory will lead the browser to show all the contents in that particular folder as in windows explorer. It’s strongly recommended to use $uri, because otherwise static contents like images, text files etc.. are not served.

You may remove “add_header” header, as they are used to debug the codes. If you want to see the result yourself, then let it to be in the code, and examine the header through F12 -> Network in Chrome to make sure the codes are working as they are supposed to be.

Don’t forget to use the respective…

listen 80;
root /var/www/html;
index index.php index.html index.htm;

pertain to your server, but the root folder should always be somewhere up in the same line as the cache folder. As an example, if the root folder is /var/www/html, the cache folder should be under the html folder, the position is not relevant, the cache folder can be in /var/www/html/cache  or /var/www/html/1/2/3/cache. Make sure to use the index.php before index.html, in index directive.

Wp Fastest Cache Settings

The following changes had been made in “WP Fastest Cache” plugin. Cache System option has to be enabled to make the plugin active, Preload makes sure the plugin regularly takes and stores caches without the intervention of the users. Additionally, it provides more options to store caches of specific sections of the website in a given time frame, currently as sections it supports Home Page, Posts, Categories, Pages, Tags, Attachments and the Interval to take caches. As the Interval 8 to 12 pages per minutes is recommended depending on the hardware configuration of the server. For shared hosts keep it minimal as possible, for VPS it’s best to keep it around 8 to 10, for dedicated server anything above is fine as long as it’s not overdone. If preload is disabled, a visit to pages has to be made to store their caches. Logged in Users option restricts the cache for non-logged users, and thereby only visitors see the cache pages. This is quite useful to test any changes made in the website before deploying to public. New Post option clears the entire cache files whenever a new post is published, the new version of wp fastest cache now has additional options to clear out the cache files of all the sections or caches of home page, categories and tag, and this is same for Update Post option as well except it clears caches whenever an existing post is updated.

wp fastest cache settings



  1. Liyanage

    php block was removed to make the code compatible with other php versions as well.

  2. Liyanage

    gzip_static directory was removed as it’s not useful unless there are pre-compressed files of files in the same directory. Now the code is optimized to compress files on the fly. So make sure to add gzip directory as explained in the tutorial.

  3. Could you update the post with a screenshot also of your WP Fastest Cache settings? It would be interesting for readers to know what settings you made in wp fastest cache in combination with nginx. I assume Gzip and Browser caching are disabled as long as they are part of nginx configuration. Thank you!

    1. Liyanage

      Thanks for your feedback. I updated the post, please check at end of the post. 🙂

  4. Hello,

    I am total newbie to all this.
    I have a new server that I manage with Webuzo. I’m using Nginx and WordPress. Basic settings (configs) are made by Webuzo, my blog it’s live and works fine.
    I did however added the code needed for pretty permalinks.
    For example I have created permalinks.conf file with content:
    try_files $uri $uri/ /index.php?q=$uri&$args;
    So if I need new settings I just create new .conf files and Webuzo will load them from a specific folder. For me, this is fine.

    So, in this case I would need to create WPFastestCache.conf and add your code. Must I add it in full, with server {} and all that?

    Thank you kindly.

    1. Liyanage

      Use Nginx in Configuration, and then add my codes within the existing codes.

  5. […] to cover all the methods in one article. So, this tutorial teaches how to prevent web scraping with Nginx with the help of geo module which is technically known as ngx_http_geo_module in nginx […]

  6. Liyanage

    set $serve_URL $fullurl${uri}index.html;
    add_header Nucuta-Cache-Location $serve_URL;
    try_files $serve_URL $uri $uri/ /index.php$is_args$args;

    Were added. now it’s much more neat, also in the header (with this name -> Nucuta-Cache-Location) the real cache location from where the files are served display too.

  7. Liyanage

    Article was again edited. if ($query_string !~ “”) was replaced with if ($query_string).

  8. You should change “request_uri” to “uri” in “try_files” in order to fix UTF-8 requests for cached files.
    Since you use request_uri, this rule will not work for any requests which contain UTF-8 symbols.

    1. Liyanage

      Thanks for the feedback.

Leave a Reply

Your email address will not be published. Required fields are marked *

nucuta header blue