{"id":3295,"date":"2026-09-30T11:24:33","date_gmt":"2026-09-30T11:24:33","guid":{"rendered":"https:\/\/siteharbour.com\/blog\/?p=3295"},"modified":"2026-09-30T11:24:34","modified_gmt":"2026-09-30T11:24:34","slug":"nginx-fastcgi-cache-wordpress","status":"publish","type":"post","link":"https:\/\/siteharbour.com\/blog\/nginx-fastcgi-cache-wordpress\/","title":{"rendered":"How to Set Up an Nginx FastCGI Cache for WordPress on a Small Server"},"content":{"rendered":"

To cache a WordPress site in Nginx, define a fastcgi_cache_path<\/code> zone, switch the cache on inside the location that passes PHP to PHP-FPM, and bypass it for logged-in users, admin pages, POST requests and query strings. Add an X-Cache<\/code> header so you can see every HIT, MISS and BYPASS, test the configuration with nginx -t<\/code> before each reload, and clear the cache after you publish. That gives anonymous readers a page straight from disk instead of a PHP and MySQL round trip. This guide builds it step by step and shows real measurements from a 1 GB server.<\/p>\n

The commands assume Ubuntu 24.04 with Nginx 1.24 and PHP-FPM, and a WordPress blog served from a sub-path such as \/blog<\/code>. If your WordPress lives at the site root, the same rules apply to your main PHP location. It pairs well with the guides on PHP-FPM workers for limited RAM<\/a> and optimizing WordPress on a 1 GB server<\/a>.<\/p>\n

What a page cache does and does not do<\/h2>\n

Without a cache, every visit to a post runs PHP, loads WordPress and queries MySQL to build the same HTML the previous visitor received. A FastCGI cache lets Nginx store that HTML the first time and answer the following requests itself, without waking PHP-FPM at all.<\/p>\n

It is only safe for pages that look the same for everyone. A logged-in editor, a commenter with a saved name, a search results page and the admin area must never come from a shared cache, so most of the work in this guide is deciding what to skip. It also does not make a slow page fast on the first request. The first visitor after a purge still pays the full PHP cost.<\/p>\n

Step 1: Check your current setup<\/h2>\n

Find the version and the location block that hands PHP to PHP-FPM. That block is where the cache switches on:<\/p>\n

nginx -v\nsudo nginx -T 2>\/dev\/null | grep -n \"fastcgi_cache|fastcgi_pass\"\nsudo nginx -T 2>\/dev\/null | grep -n \"configuration file\"<\/code><\/pre>\n
If the second command already shows fastcgi_cache<\/code> lines, you have a cache and should adjust it instead of adding a second one. Note which file holds the PHP location. On Ubuntu that is usually a file in \/etc\/nginx\/sites-available\/<\/code>, linked from sites-enabled<\/code>, and you edit the real file.<\/p>\n
Step 2: Create the cache zone and the skip rules<\/h2>\n
Create the cache directory, owned by the user your Nginx workers run as (www-data<\/code> on Ubuntu):<\/p>\n
sudo mkdir -p \/var\/cache\/nginx\/blog\nsudo chown www-data:www-data \/var\/cache\/nginx\/blog<\/code><\/pre>\n
Then put the zone and the rules in their own file under \/etc\/nginx\/conf.d\/<\/code>. Nginx includes that folder at the http<\/code> level, which is where these directives must live. Ubuntu’s default nginx.conf<\/code> already includes it:<\/p>\n
fastcgi_cache_path \/var\/cache\/nginx\/blog levels=1:2 keys_zone=SHBLOG:10m max_size=100m inactive=60m use_temp_path=off;\n\nmap $request_method $sh_skip_method { default 1; GET 0; HEAD 0; }\nmap $request_uri $sh_skip_uri {\n    default 0;\n    ~*\/wp-admin 1;\n    ~*wp-login.php 1;\n    ~*\/wp-json 1;\n    ~*\/wp-cron 1;\n    ~*\/feed 1;\n    ~*sitemap 1;\n    ~*preview= 1;\n}\nmap $http_cookie $sh_skip_cookie {\n    default 0;\n    ~*wordpress_logged_in 1;\n    ~*wordpress_sec 1;\n    ~*comment_author 1;\n    ~*wp-postpass 1;\n}\nmap $query_string $sh_skip_qs { default 1; \"\" 0; }\nmap \"$sh_skip_method$sh_skip_uri$sh_skip_cookie$sh_skip_qs\" $sh_skip { \"0000\" 0; default 1; }<\/code><\/pre>\n
Here is what each part does:<\/p>\n