Scaricare i siti web che utilizzano Varnish

Informazioni su Varnish

Una cache è progettata per passare inosservata. Tutto ciò che un reverse proxy fa bene lo rende più difficile da vedere dall’esterno, perché una cache efficace risponde al posto della macchina che le sta dietro e non lascia al visitatore alcun motivo di chiedersi cosa sia successo. È una proprietà scomoda per un dataset di rilevamento, ed è la prima cosa da dire su questa tecnologia, non l’ultima.

Il proxy Varnish si colloca davanti a un server di origine e serve dalla memoria copie archiviate delle risposte. Rilasciato nel 2006 con licenza BSD, con supporto commerciale di Varnish Software, il software si configura in un proprio linguaggio di regole anziché tramite una pagina di impostazioni, ed è questo il dettaglio che conta di più per l’interpretazione. Nessuno si ritrova con questo software per caso. Qualcuno lo ha scelto, ha scritto le regole e le ha testate, il che significa che un rilevamento implica una decisione ingegneristica, un’origine che vale la pena proteggere e abbastanza traffico da giustificare il lavoro.

È questa inferenza a distinguerlo dalle altre voci della categoria Caching. Una rete di distribuzione dei contenuti in hosting può essere attivata con la modifica di un record del name server da qualcuno che non ha mai visto un’intestazione di cache. Un acceleratore autogestito presuppone invece un team che gestisce la propria infrastruttura e tratta le prestazioni come qualcosa da progettare, non da comprare. Per un fornitore che vende osservabilità, filtraggio di sicurezza, distribuzione gestita o hosting di origine, quella popolazione è molto più adatta di una lista generica di siti web molto trafficati.

A ottobre 2026 rileviamo il software su 2.832.857 siti, di cui 1.542.091 localizzati negli Stati Uniti, con .com come estensione più comune. Individuiamo 22 stringhe di versione distinte, e 7.0 è la lettura che registriamo più spesso. Le letture di versione esistono solo perché il proxy si annuncia nella risposta, a meno che non sia configurato per non farlo, ed è proprio questo l’annuncio che le guide di hardening raccomandano agli operatori di rimuovere.

La sottostima, quindi, non è un errore casuale di misurazione ma un effetto di selezione, e va in senso contrario all’inferenza fatta sopra. Le installazioni che riusciamo a vedere sono in misura sproporzionata quelle lasciate nella configurazione predefinita, cioè piattaforme di hosting che forniscono la cache come dotazione standard e team più piccoli che non sono mai arrivati alla checklist di hardening. Le installazioni più sofisticate, gestite proprio dai team che la tecnologia lascia supporre, sono quelle che con maggiore probabilità restano silenziose. Il conteggio va trattato come un sottoinsieme visibile e non come un totale, e la distribuzione delle versioni come la descrizione di quel solo sottoinsieme.

Anche come sottoinsieme, la popolazione risponde a domande che nessuna singola ricerca può affrontare. Quanti siti in un determinato mercato usano una cache autogestita anziché una rete di distribuzione dei contenuti in hosting? Quali sistemi di gestione dei contenuti e piattaforme di e-commerce compaiono dietro di essa, e quel mix cambia in base al paese o all’estensione? Quali letture di versione persistono nella coda, e cos’altro gira su quegli stessi host? Ciascuna di queste domande è un filtro applicato a un’intera popolazione, ed è il tipo di domanda che precede una decisione di ingresso in un mercato, un articolo di ricerca o una campagna outbound.

Una verifica sul singolo dominio indica se un sito si trova oggi dietro questa cache, il che è utile quando si sta per fare una telefonata e inutile quando si deve decidere se farne qualcuna. La lista scaricabile riporta il dominio, il paese risultante dalla risoluzione, l’estensione, la versione quando siamo riusciti a leggerla e il resto dello stack rilevato per lo stesso sito, ed è questo il formato che serve alla seconda domanda.