| 开发者 | wbdv |
|---|---|
| 更新时间 | 2026年8月14日 17:44 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPL-2.0+ |
| 版权网址: | 版权信息 |
/purge
location that Nginx handles, and the caching policy itself lives entirely in
your Nginx configuration. A Settings page exists for the optional extras - a
background cache warmer, a purge-endpoint override for sites behind a proxy, and
a cache self-test - but you can ignore all of it.
What it purges
http context (the top of your site's file in conf.d/ is fine):
fastcgi_cache_path /var/cache/nginx/wpcache levels=1:2 keys_zone=wpcache:100m
inactive=12h max_size=512m;
In server { }:
location ~ ^/purge(/.*) {
allow 127.0.0.1;
allow ::1;
allow 203.0.113.10; # this server's own public IP
deny all;
cache_purge_response_type json;
fastcgi_cache_purge wpcache "$scheme$host$1";
}
In the PHP location:
open_file_cache off;
fastcgi_cache wpcache;
fastcgi_cache_key "$scheme$host$request_uri";
fastcgi_cache_methods GET;
fastcgi_cache_valid 200 301 302 12h;
fastcgi_ignore_headers Cache-Control Expires;
Three things that catch people out:
$request_uri, not $uri, in the cache key. WordPress routes everything
through try_files ... /index.php, so $uri becomes /index.php and the
whole site collapses onto one cache entry.$request_method out of the key, and set fastcgi_cache_methods GET.
Otherwise GET and HEAD are stored separately and the HEAD copies can never be
purged.open_file_cache, turn it off in the cached location.
Nginx caches the descriptors of cache files too, so purges appear to do
nothing for up to open_file_cache_valid seconds.fastcgi_cache_key exactly,
with $1 in place of the path. If they differ, every purge returns 412.
Then:
nginx -t && systemctl reload nginx
2. The plugin
reqad-cache-purger folder to wp-content/plugins/, or install
the zip through Plugins > Add New > Upload Plugin.add_header X-FastCGI-Cache $upstream_cache_status always; while testing.No. Nginx does the caching; this plugin only tells it what to throw away.
That module purges one exact key per request and has no wildcard support, so the "purge everything" button cannot work. It has also been unmaintained since 2015 and no longer builds against current Nginx. Use https://github.com/nginx-modules/ngx_cache_purge instead.
The request is not reaching Nginx from an address in your allow list. The
plugin calls the site's own public hostname, so the source address is normally
the server's public IP - not 127.0.0.1. Behind a proxy that sets
real_ip_header, $remote_addr becomes the visitor's address instead; in that
case point the plugin at your origin with the ngxcp_purge_endpoint filter.
412 means "this key was not in the cache". For a page nobody has requested yet
that is normal and the plugin treats it as success. If it happens for pages that
are definitely cached, your purge-location key expression does not match
fastcgi_cache_key.
Enable WP_DEBUG and WP_DEBUG_LOG. Every purge attempt is logged to
wp-content/debug.log with an NGXCP: prefix, including the URL and HTTP status.
Yes, with the ngxcp_purge_endpoint filter. ngxcp_purge_sslverify controls
certificate verification, and ngxcp_paths_for_post controls which paths are
purged when a post changes. See README.md.
Yes. Product and product-category purging switch on automatically. Make sure your Nginx bypass rules exclude cart, checkout, my-account and the WooCommerce session cookies - the configuration in README.md does.
Not for page caching, no. Those plugins store rendered HTML themselves, and Nginx then caches their output - two caches with two lifetimes and two purge mechanisms that know nothing about each other, so pages go stale in ways no single purge fixes. Turn page caching off in the other plugin (its minification, database and CDN features are fine to keep), or drop the fastcgi_cache directives from your vhost and let that plugin do the caching. The Settings page warns you when it detects one. Object caches such as Redis Object Cache work fine - they are a different layer.
Core's test looks for a fixed list of caching headers and does not know
x-fastcgi-cache. The plugin registers the header with core, so the test should
pass once this plugin is active. If it still does not, either the cache status
header is missing from your vhost, or the home page is being bypassed - run the
cache self-test on the Settings page to see which. You can also emit the name
core already knows: add_header X-Cache-Status $upstream_cache_status always;.
ngxcp_purge_sslverify filter for setups that need it off.publish did, so content pulled offline stayed cached.delete_term fires after the term is already gone.product_cat.ngxcp_purge_endpoint, ngxcp_purge_sslverify and ngxcp_paths_for_post
filters.