Nota operativa — Risoluzione dei conflitti tra Varnish Cache e Wordfence Firewall
Ambiente: CloudPanel · NGINX · PHP-FPM · Varnish · WordPress · Wordfence
Stato: Risolto il problema di rilevamento del controller Varnish.
1. Il problema
Su alcuni siti WordPress gestiti con CloudPanel ho riscontrato problemi con Varnish dopo aver attivato la protezione avanzata di Wordfence (Extended Protection).
Il problema nasce dal fatto che CloudPanel e Wordfence utilizzano entrambi la direttiva PHP auto_prepend_file per caricare i rispettivi componenti prima dell’esecuzione di WordPress.
CloudPanel utilizza un controller PHP situato normalmente in:
/home/SITE_USER/.varnish-cache/controller.phpWordfence, invece, utilizza:
/home/SITE_USER/htdocs/example.com/wordfence-waf.phpPoiché auto_prepend_file può indicare un solo file, è necessario che uno dei due componenti richiami anche l’altro.
Wordfence gestisce questa situazione durante la procedura Optimize Firewall, permettendo di mantenere il caricamento del controller Varnish attraverso un’istruzione di inclusione.
Se questo passaggio non viene gestito correttamente, alcune funzionalità della cache Varnish possono smettere di funzionare.
2. Il passaggio fondamentale: Optimize Firewall
Quando configuro Wordfence su un sito che utilizza Varnish, accedo a:
Wordfence → Firewall → Optimize the Wordfence Firewall
Durante la procedura, Wordfence dovrebbe riconoscere il controller Varnish già configurato da CloudPanel e mostrare un percorso simile a:
/home/SITE_USER/.varnish-cache/controller.phpDevo verificare che Wordfence proponga di mantenere il caricamento del file attraverso l’opzione INCLUDE.
Se il percorso viene riconosciuto, posso procedere con l’ottimizzazione.
Se invece Wordfence non mostra il controller Varnish, interrompo la procedura, perché potrei compromettere il corretto funzionamento dell’integrazione con la cache.
3. Come ho risolto il problema
In un caso recente, Wordfence non riconosceva il controller Varnish durante Optimize Firewall.
Ho verificato che il file esistesse e che la direttiva auto_prepend_file fosse correttamente presente nella configurazione NGINX.
Nonostante questo, Wordfence continuava a non rilevarlo.
Ho risolto senza modificare manualmente alcun file, seguendo questa procedura:
- Ho aperto CloudPanel → Sites → Varnish Cache.
- Ho disattivato Varnish per il sito interessato.
- Ho riattivato Varnish.
- Sono tornato in WordPress e ho ripetuto Wordfence → Optimize Firewall.
- Wordfence ha finalmente riconosciuto il controller Varnish, proponendone l’inclusione.
Non ho verificato quale configurazione interna sia stata aggiornata da CloudPanel, ma la procedura ha risolto il problema di rilevamento.
Questa è quindi la prima soluzione da provare quando Wordfence non riconosce Varnish.
4. Controlli da terminale
Se la riattivazione di Varnish non risolve il problema, posso verificare direttamente la configurazione.
Verificare la presenza del controller
sudo test -f /home/SITE_USER/.varnish-cache/controller.php \
&& echo "Controller presente" \
|| echo "Controller assente"Verificare la direttiva auto_prepend_file
sudo nginx -T 2>/dev/null | grep -n -C 5 'auto_prepend_file'Nel Vhost del sito dovrei trovare una configurazione simile:
fastcgi_param PHP_VALUE "
auto_prepend_file=/home/SITE_USER/.varnish-cache/controller.php;
";La presenza della direttiva conferma che NGINX è configurato per trasmetterla a PHP-FPM, ma non garantisce che Wordfence riesca a rilevarla.
Prima di intervenire manualmente è opportuno verificare anche eventuali configurazioni concorrenti in .user.ini o PHP-FPM.
5. Verificare il funzionamento dopo l’ottimizzazione
Una volta completata la procedura, devo controllare entrambi i sistemi.
Wordfence: verifico che il firewall risulti in modalità Extended Protection.
Varnish: controllo che le pagine pubbliche vengano effettivamente memorizzate nella cache.
Per una prima verifica posso utilizzare:
sudo varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_missEseguo alcune richieste a una pagina pubblica cacheabile e verifico se aumentano le cache hit.
Se il server ospita più siti, questi contatori rappresentano l’attività complessiva di Varnish, quindi non permettono da soli di attribuire le hit al sito che sto verificando.
È inoltre importante controllare che le pagine riservate, il carrello e il checkout di WooCommerce non vengano memorizzati nella cache condivisa.
Attenzione: il controller PHP di CloudPanel gestisce l’integrazione con Varnish, ma Varnish può continuare a funzionare come reverse proxy anche senza di esso. Una cache hit non dimostra quindi, da sola, che tutte le funzionalità del controller siano operative.
6. Promemoria operativo
Quando devo attivare Wordfence Extended Protection su un sito con Varnish:
- Verifico che Varnish sia attivo in CloudPanel.
- Avvio Wordfence → Optimize Firewall.
- Controllo che venga riconosciuto il controller Varnish e proposta l’opzione INCLUDE.
- Se il controller non viene riconosciuto, disattivo e riattivo Varnish da CloudPanel e riprovo.
- Se il problema persiste, verifico il controller e la direttiva
auto_prepend_fileda terminale. - Completo l’ottimizzazione soltanto quando l’inclusione del controller è correttamente prevista.
- Verifico il funzionamento di Wordfence e della cache Varnish.
Nota conclusiva — 08/10/2026
Il problema di rilevamento del controller Varnish durante Optimize Firewall è stato risolto disattivando e riattivando Varnish da CloudPanel, senza modificare manualmente NGINX o PHP.
La causa precisa del mancato rilevamento non è stata identificata.
Il ripristino del riconoscimento del controller è stato confermato; resta da documentare la verifica finale delle cache hit e delle invalidazioni dopo l’attivazione di Extended Protection.
Da ricordare: quando Wordfence non mostra il percorso del controller Varnish durante Optimize Firewall, prima di intervenire sui file di configurazione conviene provare a disattivare e riattivare Varnish da CloudPanel.
Documentazione tecnica di riferimento: CloudPanel — PHP Controller · CloudPanel — Vhost · Wordfence — Firewall Optimization.
