MSCache Varnish Purge, il Plugin Avanzato di Purge Cache Varnish per WordPress

Cos’è MSCache Varnish Purge

MSCache Varnish Purge è un plugin WordPress professionale che consente di invalidare (purgare) la cache di Varnish in modo asincrono tramite socket TCP raw, senza impatto sulle performance del sito. Progettato e ottimizzato per lo stack hosting di Managed Server S.r.l., è compatibile con qualsiasi installazione Varnish Cache correttamente configurata.

A differenza di molti plugin presenti sul mercato, che effettuano richieste HTTP sincrone verso Varnish (o addirittura verso endpoint intermedi), MSCache Varnish Purge evita completamente di bloccare il processo di esecuzione di WordPress. I plugin tradizionali attendono la risposta del server Varnish prima di proseguire, introducendo latenza aggiuntiva ad ogni salvataggio, pubblicazione o aggiornamento di contenuti. Questo comportamento, soprattutto su siti ad alto traffico o con molte operazioni concorrenti, può tradursi in rallentamenti percepibili lato backend e in un degrado complessivo delle performance.

Il plugin invia invece richieste HTTP PURGE direttamente a Varnish tramite fsockopen, chiudendo immediatamente la connessione senza attendere la risposta del server — un approccio “fire and forget” che elimina completamente i tempi di attesa. In questo modo si garantisce zero latenza aggiuntiva su ogni operazione di WordPress, mantenendo al contempo un meccanismo di invalidazione rapido, efficiente e scalabile.

Questo approccio asincrono rende MSCache Varnish Purge particolarmente efficace anche in scenari complessi, dove i purge sono frequenti e devono essere eseguiti senza compromettere la reattività dell’interfaccia di amministrazione o delle operazioni applicative.

Perché serve un plugin di purge per Varnish?

Varnish Cache è un acceleratore HTTP che si posiziona davanti al backend e memorizza copie delle pagine web già generate, servendole direttamente ai visitatori senza dover coinvolgere ogni volta WordPress, PHP e MySQL. In questo modo si riducono in maniera sensibile i tempi di risposta, si alleggerisce il carico sul server applicativo e si migliora la capacità del sito di gestire un numero elevato di richieste contemporanee.

Il problema sorge quando il contenuto cambia: un articolo viene aggiornato, un commento viene approvato, un prodotto WooCommerce esaurisce le scorte. Senza un meccanismo di invalidazione, Varnish continua a servire la versione vecchia (stale) della pagina fino alla scadenza naturale del TTL, con il rischio di mostrare ai visitatori contenuti non più aggiornati.

MSCache Varnish Purge risolve questo problema notificando automaticamente Varnish ogni volta che un contenuto WordPress cambia, purgando chirurgicamente solo le URL coinvolte — l’articolo modificato, la home page, le pagine archivio delle categorie e dei tag, e qualsiasi altra URL associata. Questo consente di mantenere i benefici della cache senza rinunciare alla coerenza e all’aggiornamento immediato dei contenuti pubblicati.

Funzionalità principali

Purge automatico su modifiche contenuti

Il plugin monitora tutti gli eventi rilevanti di WordPress e invia automaticamente le richieste di purge a Varnish:

Articoli e Pagine — purge al salvataggio, aggiornamento, pubblicazione, cestinamento e cancellazione
Home page — purgata automaticamente ad ogni modifica di contenuto (configurabile)
Archivi categorie e tag — le pagine archivio vengono purgate quando un articolo appartenente a quella categoria/tag viene modificato
Archivi autore — la pagina autore viene aggiornata quando l’autore pubblica o modifica un articolo
Archivi data — gli archivi anno, mese e giorno vengono purgati quando un articolo con quella data viene modificato
Custom Post Type — supporto completo per qualsiasi tipo di contenuto personalizzato
Feed RSS — il feed viene purgato per garantire che i lettori RSS ricevano i nuovi contenuti immediatamente
Commenti — quando un commento viene approvato, modificato o cancellato, la pagina del post viene purgata per riflettere il conteggio aggiornato
Termini tassonomici — quando una categoria o un tag viene rinominato o cancellato, l’archivio corrispondente viene purgato
Menu di navigazione — modifiche ai menu triggerano un purge della home page o dell’intera cache
Widget e Customizer — modifiche a widget e impostazioni del personalizzatore WordPress
Post programmati — i post schedulati per la pubblicazione futura vengono purgati automaticamente quando il cron di WordPress li pubblica
Immagine in evidenza — il cambio della featured image di un post trigga il purge anche senza salvare il post
Aggiornamenti core, plugin e temi — un purge completo viene eseguito automaticamente dopo ogni aggiornamento
Cambio tema — il cambio del tema attivo trigga un purge completo
Cambio permalink — la modifica della struttura permalink trigga un purge completo
Modifiche opzioni frontend — cambi a titolo sito, descrizione, pagina home, pagina blog triggerano un purge completo
Editor Gutenberg — supporto completo tramite hook REST API come fallback per i salvataggi via editor a blocchi

Purge manuale

Oltre al purge automatico, il plugin offre diversi modi per eseguire purge manuali:

Admin bar — menu “MSCache” nella barra di amministrazione con:
- Purge intera cache (con popup di conferma e avviso performance)
- Purge home page
- Purge pagina corrente (disponibile sul frontend)
- Purge pagina + archivi (purge completo come il salvataggio automatico)
Tab Azioni — pulsanti dedicati nella pagina di configurazione del plugin
Metabox nell’editor — pulsante “Purge This Page” nella sidebar dell’editor per purgare la pagina che stai modificando
Row action — link “Purge Cache” nella lista post/pagine per purgare singoli contenuti
Bulk action — azione di massa per purgare la cache di più post selezionati contemporaneamente

Purge completo configurabile

Il purge dell’intera cache supporta tre metodi, configurabili in base alla VCL Varnish in uso:

PURGE wildcard (PURGE /.*) — invia una richiesta con path regex che matcha tutte le URL del dominio
PURGE percorso personalizzato — invia un PURGE a un URL specifico che la VCL mappa a un ban completo
BAN con header personalizzato — invia un metodo HTTP BAN con un header custom (es. X-Purge-Regex: .*)

Esclusioni dalla cache

Il plugin consente di definire pattern per le URL che non devono mai essere cachate. Quando una richiesta frontend corrisponde a un pattern di esclusione, il plugin aggiunge l’header HTTP ms-cache: excluded alla risposta.

Questo header viene letto dalla VCL di Varnish (o dalla configurazione proxy_no_cache di Nginx) per impedire il caching di quella risposta.

Modalità di matching

Glob (predefinita) — usa wildcard semplici: * corrisponde a qualsiasi sequenza di caratteri, ? a un singolo carattere. Esempi: /wp-admin/*, /cart*, /checkout*, *.xml
Regex (avanzata) — espressioni regolari PCRE complete con protezione ReDoS integrata (limite di backtracking ridotto a 10.000)

Pattern tester

Un tool integrato nel tab Esclusioni consente di testare se un URL matcha un pattern configurato, senza dover fare richieste reali.

Auto-esclusione WooCommerce

Le pagine Carrello, Checkout e Il mio account vengono escluse automaticamente dalla cache quando l’opzione è attiva, senza bisogno di configurare pattern manualmente.

Integrazione WooCommerce

MSCache Varnish Purge include un tab dedicato per WooCommerce con integrazione granulare su ogni aspetto dell’e-commerce:

Cambio giacenze — quando la quantità in stock di un prodotto cambia (acquisto, riassortimento, modifica manuale), la pagina prodotto, la pagina negozio e le pagine categoria vengono purgate
Saldi programmati — il cron di WooCommerce che attiva e disattiva i saldi trigga automaticamente il purge dei prodotti in saldo e della pagina negozio
Recensioni prodotto — quando una recensione viene pubblicata, approvata o cancellata, la pagina prodotto viene purgata per riflettere la valutazione aggiornata
Coupon — la creazione o modifica di coupon trigga il purge della pagina negozio e home page
Attributi prodotto — modifiche ad attributi (Colore, Taglia, Materiale) triggerano il purge della pagina negozio
Cambio stato ordine — quando un ordine cambia stato (in lavorazione, completato, annullato, rimborsato), il plugin purga la pagina prodotto, la pagina negozio e le categorie di ogni prodotto contenuto nell’ordine
Auto-esclusione — Cart, Checkout e My Account vengono automaticamente escluse dalla cache tramite l’header ms-cache: excluded

Integrazione CloudFlare CDN

Per i siti che usano Cloudflare come CDN, il plugin offre sincronizzazione automatica della cache: ogni volta che Varnish viene purgato, anche la cache Cloudflare edge viene invalidata.

Configurazione

API Token — con permesso “Zone.Cache Purge” (non Global API Key)
Zone ID — identificativo della zona del dominio su Cloudflare
Test connessione — pulsante per verificare che le credenziali siano valide

Modalità di purge

Per-URL — ogni URL purgata da Varnish viene purgata singolarmente anche su Cloudflare (preciso, più chiamate API)
Purge Everything — qualsiasi purge Varnish trigga un “purge everything” su Cloudflare (semplice, svuota tutta la CDN)
Per-URL + fallback (raccomandato) — purge per-URL per le singole pagine, “purge everything” solo quando si esegue un purge completo di Varnish

Integrazioni con plugin di performance

Il plugin si integra in modo bidirezionale con i principali plugin di performance WordPress, mantenendo tutti i livelli di cache sincronizzati.

WP Rocket

WP Rocket è uno dei plugin di caching più diffusi e performanti per WordPress, progettato per migliorare la velocità di caricamento delle pagine e l’esperienza utente senza richiedere configurazioni complesse. Attraverso funzionalità come page cache, ottimizzazione dei file CSS e JavaScript, lazy loading e precaricamento della cache, consente di ridurre drasticamente i tempi di risposta lato frontend.

MSCache → WP Rocket — quando Varnish viene purgato, la page cache locale di WP Rocket viene pulita tramite rocket_clean_post() e rocket_clean_domain()
WP Rocket → MSCache — quando l’utente clicca “Pulisci Cache” in WP Rocket, anche Varnish viene purgato
Auto-detect dell’add-on Varnish di WP Rocket con warning per evitare purge doppi

FlyingPress

FlyingPress è un plugin di ottimizzazione delle performance per WordPress focalizzato sulla velocità reale percepita dall’utente, con un approccio moderno e altamente efficiente. Include funzionalità come page cache, ottimizzazione e ritardo dell’esecuzione dei JavaScript, lazy loading avanzato, critical CSS e preload intelligente delle risorse, contribuendo a migliorare significativamente metriche come Core Web Vitals e tempi di caricamento complessivi.

Sincronizzazione bidirezionale tramite FlyingPress\Purge::purge_url() e action hook flying_press_purge_everything
Auto-detect del plugin con indicatore di stato

W3 Total Cache

W3 Total Cache è uno dei plugin storici per l’ottimizzazione delle performance su WordPress, pensato per offrire un controllo avanzato su tutti i livelli di caching. Supporta page cache, object cache, database cache e integrazione con CDN, oltre a strumenti per la minificazione di CSS e JavaScript. Grazie alla sua flessibilità è adatto a configurazioni complesse, anche se richiede una corretta impostazione per ottenere i migliori risultati.

Sincronizzazione unidirezionale (MSCache → W3TC) tramite w3tc_flush_post() e w3tc_flush_all()
Auto-detect del modulo Varnish nativo di W3TC con warning conflitto

Autoptimize

Autoptimize è un plugin leggero per WordPress dedicato all’ottimizzazione degli asset frontend, con l’obiettivo di ridurre il peso e il numero delle richieste HTTP. Si occupa principalmente di aggregare, minificare e comprimere file CSS e JavaScript, oltre a ottimizzare il caricamento delle risorse e, opzionalmente, delle immagini. È spesso utilizzato in combinazione con sistemi di caching per migliorare ulteriormente le performance complessive del sito.

Pulizia della cache CSS/JS ottimizzata solo su purge completo di Varnish, tramite autoptimizeCache::clearall()
Non si attiva su purge singole pagine per evitare rigenerazioni eccessive degli asset

Object Cache (Redis / Memcached)

Redis Object Cache è un plugin che consente di utilizzare Redis come sistema di object caching per WordPress, memorizzando in memoria dati frequentemente richiesti come query al database e oggetti PHP. Questo riduce il numero di accessi a MySQL e migliora significativamente le performance del backend, soprattutto su siti ad alto traffico o con operazioni complesse. È particolarmente efficace quando integrato in uno stack ottimizzato lato server.

Flush opzionale dell’object cache WordPress (wp_cache_flush()) su purge completo di Varnish
Auto-detect del backend (Redis, Memcached, APCu)

Ogni integrazione ha un guard anti-loop che previene cicli infiniti di purge reciproci.

Pagine AMP

Il plugin supporta il purge automatico delle versioni AMP delle pagine, in entrambi i formati:

Endpoint — /post-slug/amp/ (usato dal plugin AMP ufficiale e AMP for WP)
Query parameter — /post-slug/?amp e /post-slug/?amp=1

Quando abilitato, per ogni URL purgata vengono generate e purgate anche le varianti AMP corrispondenti. Il plugin rileva automaticamente il formato AMP in uso.

WordPress Multisite

MSCache Varnish Purge supporta pienamente WordPress Multisite con una configurazione a due livelli:

Impostazioni di rete — IP Varnish, porta, timeout, Cloudflare e integrazioni terze parti sono condivise tra tutti i siti e gestite dal Network Admin
Impostazioni per-sito — opzioni di purge automatico, esclusioni, WooCommerce e permessi sono configurabili indipendentemente su ogni sito
Host header dinamico — il plugin usa automaticamente il dominio corretto per ogni sito del network, supportando anche il domain mapping
Dashboard di rete — mostra tutti i siti con il loro host header e lo stato del plugin
WP-CLI — comando wp mscache purge-network per purgare tutti i siti in un’unica operazione

Permessi basati sui ruoli

L’accesso alle funzioni di purge è configurabile per ruolo WordPress:

Amministratore — sempre abilitato, accesso completo alle impostazioni
Editor, Autore, altri ruoli — configurabili singolarmente. I ruoli abilitati vedono i pulsanti di purge nella admin bar e nelle liste post, ma non hanno accesso alla pagina di configurazione del plugin

WP-CLI

Il plugin offre comandi WP-CLI completi per l’automazione e gli script di deploy:

# Purge dell'intera cache
wp mscache purge --all

# Purge di una URL specifica
wp mscache purge --url=/shop/

# Purge della home page
wp mscache purge --home

# Purge delle URL aggiuntive configurate
wp mscache purge --additional

# Stato configurazione
wp mscache status

# Test connessione a Varnish
wp mscache test

# Purge di tutti i siti nel network (Multisite)
wp mscache purge-network

REST API

Endpoint autenticati per trigger di purge da sistemi esterni, pipeline CI/CD o integrazioni custom:

# Purge di una URL specifica
curl -X POST https://example.com/wp-json/mscache/v1/purge \
  -H "Authorization: Basic ..." \
  -d '{"url": "/shop/"}'

# Purge completo
curl -X POST https://example.com/wp-json/mscache/v1/purge \
  -d '{"all": true}'

# Stato del plugin
curl https://example.com/wp-json/mscache/v1/status

L’autenticazione usa il sistema standard di WordPress (Application Passwords, cookie auth, o qualsiasi plugin di autenticazione).

Dashboard e monitoraggio

Dashboard del plugin

Il tab Dashboard nella pagina di configurazione mostra:

Stato — plugin abilitato/disabilitato, connessione Varnish OK/FAIL, target IP:porta, host header, stato Multisite
Statistiche purge — conteggio successi/fallimenti per giorno negli ultimi 7 giorni
Ultimo fallimento — timestamp e path dell’ultima purge fallita
Attività recente — ultime 500 operazioni di purge con timestamp, path, risultato, trigger e nome utente. Paginazione a 50 record per pagina con ricerca per URL

Widget WP Dashboard

Un widget compatto nella dashboard principale di WordPress che mostra a colpo d’occhio:

Stato connessione (pallino verde/rosso/grigio)
Target Varnish
Contatore purge del giorno
Ultimo purge con timestamp e path
Pulsante rapido “Purge Entire Cache”

Log di debug

Quando la modalità debug è attiva, il plugin registra ogni operazione di purge in file di log giornalieri:

Path dell’URL purgata
Risposta di Varnish (codice HTTP)
Errori di connessione socket
Pattern di esclusione matchati
Timestamp in formato UTC

I log sono protetti con .htaccess, nomi file offuscati con token random, e un index.php guard. Un log viewer integrato nella pagina settings mostra le ultime 50 righe del log del giorno corrente.

Sicurezza

CRLF injection — tutti i valori iniettati nelle richieste HTTP raw vengono sanitizzati contro \r\n\0
SSRF — blocco degli IP link-local e cloud metadata (169.254.x.x) nella configurazione dell’IP Varnish
ReDoS — limite di backtracking ridotto a 10.000 per i pattern regex, troncamento path a 2.048 caratteri
Log injection — sanitizzazione newline nei messaggi di log
Log file exposure — token random nei nomi file, protezione .htaccess e index.php
CSRF — nonce verification su tutte le azioni admin
Capability check — manage_options per le impostazioni, current_user_can_purge() per le azioni di purge
Input sanitization — sanitize_text_field(), sanitize_textarea_field(), intval(), FILTER_VALIDATE_IP, whitelist per campi select
Output escaping — esc_html(), esc_attr(), esc_url(), wp_kses() su tutti gli output admin
Hostname validation — regex /^[a-zA-Z0-9._-]+$/ per l’header host personalizzato
Zone ID validation — regex hex 32 caratteri per il Zone ID Cloudflare

Configurazione VCL Varnish

Il plugin è testato e collaudato sullo stack Varnish di Managed Server S.r.l. Di seguito la configurazione VCL di riferimento per Varnish 3.x o successive.

vcl_recv — Gestione PURGE

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 (req.request == "PURGE") {
        if ((req.http.X-Forwarded-For == "123.123.123.123, 127.0.0.1")
            || (req.http.X-Forwarded-For == "127.0.0.1")) {
            ban("req.url ~ ^" + req.url + "$"
                + " && req.http.host == " + req.http.host);
            error 200 "Purged.";
        } else {
            error 405 "Not allowed.";
        }
    }

    if ((req.request == "PURGE")
        && ((req.http.X-Forwarded-For == "123.123.123.123")
            || (req.http.X-Forwarded-For == "127.0.0.1"))
        && (req.http.X-Purge-Domain)) {
        ban("req.http.host == " + req.http.X-Purge-Domain);
        error 200 req.http.X-Purge-Domain + " purged.";
    }

    # ... altre regole vcl_recv ...
}

vcl_fetch — Esclusioni ms-cache

sub vcl_fetch {

    if (beresp.http.ms-cache == "excluded") {
        set beresp.ttl = 0s;
        set beresp.http.X-Cache = "EXCLUDED";
        return (hit_for_pass);
    }

    # ... altre regole vcl_fetch ...
}

Sostituire 123.123.123.123 con l’IP pubblico del server e 127.0.0.2 con l’indirizzo del backend.

Compatibilità

Componente	Versioni supportate
WordPress	5.0+
PHP	7.0 — 8.x
Varnish Cache	3.x, 4.x, 5.x, 6.x, 7.x
WooCommerce	3.x — 9.x
Multisite	Sì

Lingue disponibili

Inglese (default)
Italiano
Francese
Tedesco
Spagnolo

In futuro probabilmente verranno integrate altre lingue (Cinese, Giapponese, Rumeno, Russo, Greco, Finlandese)

Installazione

Caricare la directory mscache-4-wp in /wp-content/plugins/
Attivare il plugin dal pannello Plugin di WordPress
Andare su MSCache nel menu laterale
Configurare l’IP e la porta di Varnish (default: 127.0.0.1:80)
Abilitare il plugin dal tab Generale
Usare il pulsante Test Connection nel tab Azioni per verificare la connettività

Requisiti

PHP 7.0 o superiore con funzione fsockopen abilitata
Varnish Cache installato e raggiungibile via TCP dall’IP configurato
VCL configurata per accettare richieste PURGE (vedi sezione Configurazione VCL)

Disclaimer

Questo plugin è distribuito sotto licenza GPLv2 o successiva. È progettato e ottimizzato per l’infrastruttura hosting di Managed Server S.r.l. Può funzionare correttamente su qualsiasi ambiente hosting con Varnish Cache configurato correttamente. MANAGED SERVER S.R.L. non si assume alcuna responsabilità per malfunzionamenti, perdita di dati, inconsistenze della cache o interruzioni di servizio derivanti dall’uso del plugin su ambienti non gestiti dalla società. Si raccomanda di testare accuratamente in ambiente di staging prima del deploy in produzione.

BLOG