MSCache Varnish Purge

This plugin has been designed, developed, tested, and validated on the hosting infrastructure of Managed Server S.r.l. — Performance Managed Hosting (managedserver.it). The reference stack consists of Nginx (SSL termination and micro-caching) + Varnish Cache 3.x/4.x (HTTP reverse proxy) + Apache/Nginx (backend) + PHP-FPM, running on Linux. The plugin communicates with Varnish via raw TCP socket on a configurable IP address and port. Whether it works on other hosting environments depends entirely on: The Varnish version installed and its VCL configuration The IP address and port on which…

Your VCL must handle PURGE requests from the WordPress server and optionally support the ms-cache: excluded header for cache exclusions. Below is the reference VCL configuration tested and validated on the Managed Server infrastructure, for Varnish 3.x. Replace 123.123.123.123 with your server’s public IP address and 127.0.0.2 with your actual backend address and port. vcl_recv — PURGE handling (single URL + full domain): ` backend website { .host = “127.0.0.2”; .port = “80”; } sub vcl_recv {

if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For + “, ” + client.ip; } else { set req.http.X-Forwarded-For = client.ip; }

if (beresp.http.ms-cache == “excluded”) { set beresp.ttl = 0s; set beresp.http.X-Cache = “EXCLUDED”;

} **vcl_fetch — Respect the ms-cache: excluded header from the plugin:** sub vcl_fetch {

return (hit_for_pass); }

} `

The plugin sends an HTTP PURGE request to Varnish via a raw TCP socket connection (fsockopen). The request includes the URL path to invalidate and the correct Host header for the domain. Single URL purge — When a post is saved, the plugin sends: PURGE /2026/04/03/my-post-title/ HTTP/1.0 Host: www.example.com Connection: Close The VCL uses ban() with a regex anchored match (^/path/$) to invalidate the URL. This approach is used instead of return(purge) because most production Varnish configurations include additional keys in vcl_hash (e.g., x-ua-device for mobile/desktop variants). A ban()…

PURGE (return(purge) in VCL) removes a single cached object matching an exact URL and hash. It is fast and frees memory immediately, but only works for the exact hash — if your vcl_hash includes device type, language, or other keys, you would need a separate PURGE for each variant. BAN (ban() in VCL) adds a rule to the ban list that retroactively invalidates all cached objects matching a condition. Objects are checked against the ban list when they are next requested. BAN is more flexible because it can match patterns (regex) and invalidates all variants of a URL regardless of the hash. This…

When a frontend request path matches one of the exclusion patterns configured in the plugin settings (e.g., /cart/*, /checkout/*, /my-account/*), the plugin adds the HTTP response header ms-cache: excluded. This header does nothing by itself — it is a signal for your caching layer to skip caching for that response. In Varnish: The vcl_fetch block shown above checks for this header and sets beresp.ttl = 0s + return(hit_for_pass), ensuring the response is never stored in cache. In Nginx proxy cache: You can use this header with proxy_no_cache to achieve the same effect. See the Nginx…

Yes. The plugin fully supports WordPress Multisite with a dual-layer configuration: Network-level settings — Varnish IP, port, socket timeout, Cloudflare CDN integration, and third-party plugin integrations are configured once in Network Admin → Settings → MSCache Network and shared across all sites in the network. Per-site settings — Each site in the network has its own independent configuration for auto-purge options, exclusion patterns, WooCommerce integration, permissions, and debug mode. Dynamic host header — The plugin automatically detects and uses the correct domain name for each site…

Yes. The plugin only opens outbound TCP connections to the configured Varnish IP (default: 127.0.0.1, localhost). It does not require any special PHP extensions beyond the standard fsockopen function available in all PHP installations. It is compatible with PHP 7.0 through PHP 8.x without deprecation warnings.

The WordPress HTTP API (wp_remote_request) sends the request and waits for the full HTTP response cycle before returning control to WordPress. This adds latency to every post save. Raw sockets with fsockopen allow the plugin to: Open a TCP connection to Varnish Write the PURGE request Close the connection immediately — without reading the response This “fire and forget” approach avoids waiting for the full HTTP response cycle on each purge, so the purge request does not block the WordPress admin request regardless of how long Varnish takes to process it. In debug mode, the plugin optionally…

The plugin integrates with: Cloudflare CDN — Synchronized cache purge via Cloudflare API v4 (per-URL or purge-everything) WP Rocket — Bidirectional sync (MSCache → WP Rocket and WP Rocket → MSCache) FlyingPress — Bidirectional sync W3 Total Cache — Sync purge (MSCache → W3TC) Autoptimize — CSS/JS cache clear on full Varnish purge Redis / Memcached Object Cache — Optional flush on full purge WooCommerce — Dedicated integration with stock, sales, reviews, coupons, attributes, orders, and auto-exclusion of dynamic pages Each integration is detailed below.

Many websites use Cloudflare as a CDN and security layer in front of their origin server. When Varnish is purged, the content at the origin is fresh — but Cloudflare edge nodes around the world may still serve stale cached copies to visitors for hours or days. The plugin solves this by optionally sending purge requests to the Cloudflare API v4 every time Varnish is purged. Configuration requires a Cloudflare API Token (with “Zone.Cache Purge” permission) and the Zone ID of your domain, both available from the Cloudflare dashboard. Three purge modes are available: Per-URL — Each individual URL…

WP Rocket is one of the most popular WordPress performance plugins, providing page caching, file optimization, and lazy loading. When both MSCache and WP Rocket are active, two separate caching layers exist: Varnish (server-level) and WP Rocket (application-level). If only one is purged, visitors may see inconsistent content. The integration provides bidirectional synchronization: MSCache → WP Rocket — When MSCache purges a URL from Varnish, it also calls rocket_clean_post() to clear that page from WP Rocket’s local page cache. On a full Varnish purge, rocket_clean_domain() clears the entire…

FlyingPress is a lightweight WordPress performance plugin focused on page caching and CDN. The integration works similarly to WP Rocket: MSCache → FlyingPress — Calls FlyingPress\Purge::purge_url() for single pages and FlyingPress\Purge::purge_everything() for full cache purge. FlyingPress → MSCache — Listens to the flying_press_purge_everything action. When FlyingPress clears its cache, MSCache also sends a full PURGE to Varnish. The plugin auto-detects FlyingPress via FLYING_PRESS_VERSION constant or class existence and shows the detection status in the Integrations tab.

W3 Total Cache (W3TC) is a comprehensive performance plugin with page cache, database cache, object cache, and CDN support. The integration is one-directional (MSCache → W3TC): When MSCache purges a single URL, it calls w3tc_flush_post() to clear that page from all W3TC cache layers. When MSCache performs a full purge, it calls w3tc_flush_all() to clear the entire W3TC cache. Important: W3TC has its own Varnish module. If both the W3TC Varnish module and MSCache are active, you will get duplicate PURGE requests. The plugin auto-detects this conflict and warns you. Disable W3TC’s Varnish…

Autoptimize aggregates and minifies CSS and JavaScript files to reduce HTTP requests and file sizes. After a theme or plugin update, the optimized asset bundles may reference outdated code. The integration is one-directional and limited to full purge only: When MSCache performs a full Varnish purge (e.g., after a plugin/theme update), it also calls autoptimizeCache::clearall() to regenerate all optimized CSS/JS bundles. Single page purges do not trigger Autoptimize clear, because regenerating all optimized assets for a single page change would be disproportionately expensive. This ensures…

WordPress object cache (Redis, Memcached, APCu) stores transients, database query results, and rendered fragments in memory. When Varnish is fully purged (e.g., after a major site update), the object cache may still contain stale data that causes WordPress to render pages with outdated content — even though Varnish fetches fresh HTML from the backend. The integration is one-directional and limited to full purge only: When MSCache performs a full Varnish purge, it optionally calls wp_cache_flush() to clear the entire object cache. Single page purges do not trigger an object cache flush…