Indice dei contenuti dell'articolo:
Negli ultimi mesi, durante le nostre attività di ottimizzazione delle performance web sui progetti dei clienti di Managed Server SRL, ci siamo imbattuti in un comportamento anomalo che inizialmente ci ha lasciati perplessi. Utilizziamo HTTP/3 con protocollo QUIC e la compressione ZSTD (Zstandard) da oltre due anni, con risultati eccellenti in termini di velocità, efficienza e stabilità delle connessioni. In tutto questo tempo, le implementazioni hanno sempre funzionato senza alcun problema: i browser negoziavano correttamente HTTP/3, la compressione ZSTD era attiva per HTML, CSS e JavaScript, e le performance dei siti erano allineate alle aspettative.
Tuttavia, improvvisamente, qualcosa è cambiato. Durante alcuni test di routine, abbiamo iniziato a notare che le connessioni che fino a poco tempo prima venivano gestite correttamente tramite HTTP/3 ora ricadevano quasi sempre su HTTP/2, mentre le risorse testuali che avevamo configurato per essere compresse in ZSTD risultavano improvvisamente servite con Brotli o addirittura gzip. Era come se, da un giorno all’altro, le nostre ottimizzazioni non esistessero più.
Questa situazione era tanto insolita quanto frustrante. Considerando che da anni il nostro stack era configurato in modo stabile e funzionante, non aveva senso che improvvisamente si comportasse diversamente. Da qui è iniziata un’indagine tecnica piuttosto approfondita per capire che cosa stesse accadendo.
L’indagine iniziale: sospetti su NGINX
Il primo passo è stato quello più naturale per chi si occupa di infrastrutture e web performance: verificare il comportamento del nostro Web Server NGINX. La logica ci suggeriva che un recente aggiornamento o qualche modifica ai flag di compilazione potesse aver cambiato il modo in cui il server gestiva QUIC e ZSTD. Abbiamo analizzato in dettaglio le configurazioni, verificato i moduli caricati e persino ricontrollato la compatibilità delle versioni in uso.
Per fugare ogni dubbio, abbiamo anche creato un ambiente di test completamente pulito, installando NGINX da zero con le nostre impostazioni minime necessarie, senza alcuna personalizzazione. L’idea era semplice: eliminare ogni possibile interferenza esterna e osservare il comportamento del protocollo e delle compressioni in un contesto isolato.
Il risultato, però, è stato sorprendente. Anche su un’installazione pulita e minimale, HTTP/3 non veniva negoziato e ZSTD continuava a non essere utilizzato. A quel punto era evidente che il problema non era legato a NGINX, né tantomeno alle configurazioni dei nostri server.
Il falso indizio: problemi di rete e MTU
Esclusa la possibilità che la causa fosse il nostro web server, abbiamo iniziato a guardare altrove. Poiché HTTP/3 si basa sul protocollo QUIC, che utilizza UDP anziché TCP, abbiamo ipotizzato che la questione potesse essere legata a qualche parametro di rete. In particolare, abbiamo sospettato che l’MTU (Maximum Transmission Unit) potesse influenzare la negoziazione del protocollo.
Abbiamo testato diverse configurazioni: prima il valore standard di 1500 byte, poi impostazioni più conservative, come 1400 e perfino 1300 byte, con l’idea di capire se pacchetti più piccoli avrebbero facilitato il passaggio a QUIC. Anche in questo caso, però, i risultati non sono cambiati: la connessione continuava a ricadere su HTTP/2 e la compressione rimaneva bloccata su Brotli o gzip.
Era chiaro che il problema non riguardava né il nostro stack né la rete. Ma la cosa più strana è che, confrontando i log storici, abbiamo scoperto che le negoziazioni funzionavano perfettamente fino a poche settimane prima. Da quel momento, abbiamo iniziato a sospettare che qualcosa di esterno alla nostra infrastruttura stesse influenzando il comportamento delle connessioni.
La scoperta: anche i big hanno lo stesso problema
Per capire se il fenomeno fosse limitato ai nostri server o avesse una portata più ampia, abbiamo deciso di fare dei test su siti di grandi corporate internazionali. Abbiamo analizzato il comportamento di colossi come Amazon, Google, Microsoft e persino alcune testate giornalistiche di primo piano. La scoperta è stata sorprendente: anche su quelle piattaforme, le connessioni non venivano quasi mai negoziate in HTTP/3 e ZSTD non veniva utilizzato.
Questo ci ha permesso di escludere definitivamente che il problema fosse lato server. Se grandi aziende con infrastrutture multimilionarie, team di ingegneri dedicati e processi di ottimizzazione avanzati non riuscivano a negoziare correttamente HTTP/3 e ZSTD, era evidente che la causa doveva trovarsi sul lato client.
L’intuizione decisiva: il sospetto sull’antivirus
Quando escludi tutto ciò che è sotto il tuo controllo, inizi a guardare ai componenti che di solito dai per scontati. In questo caso, l’attenzione si è spostata sui software installati localmente. Sapevamo che sui sistemi di test era presente ESET NOD32 Antivirus.
Gli antivirus moderni, per analizzare il traffico HTTPS, adottano una strategia che molti utenti non conoscono: instaurano un proxy locale che intercetta tutte le connessioni del browser, ne analizza i contenuti, e solo dopo le inoltra verso il server remoto. In altre parole, il browser non parla mai direttamente con il sito, ma con un intermediario che può modificare, filtrare o reinterpretare la connessione.
Se questo proxy non supporta le versioni più recenti dei protocolli o degli algoritmi di compressione, il browser è costretto a un fallback automatico su tecnologie più vecchie e compatibili. Ecco perché improvvisamente le connessioni cadevano su HTTP/2 e le compressioni tornavano a usare Brotli o gzip: non era colpa del server, ma di un’interferenza lato client.
La conferma: disinstallare l’antivirus
Per confermare l’ipotesi abbiamo deciso di fare un esperimento drastico. Abbiamo rimosso ESET NOD32 Antivirus dai sistemi di test, riavviato la macchina e ripetuto le verifiche. Il risultato è stato immediato: i browser hanno ricominciato a negoziare HTTP/3 / QUIC correttamente e la compressione ZSTD è tornata a funzionare esattamente come prima.
Dopo settimane di test, esclusioni e verifiche, avevamo finalmente trovato la causa. L’antivirus, con il suo proxy locale, interferiva con la negoziazione delle connessioni e impediva l’uso delle ottimizzazioni che avevamo implementato da tempo.
Perché succede e perché non riguarda solo ESET
Quello che abbiamo riscontrato non è un bug isolato, ma una conseguenza diretta del funzionamento dei moderni antivirus per Windows. Molti di essi, non solo ESET, adottano la stessa strategia di intercettazione tramite proxy HTTPS locale. Questo significa che software come Avast, Kaspersky, Bitdefender, McAfee e molti altri potrebbero provocare lo stesso identico comportamento.
Ogni volta che un antivirus si pone tra browser e rete, prende il controllo della connessione e ne gestisce in parte le caratteristiche. Se il proxy non è aggiornato per supportare protocolli moderni come HTTP/3 o compressioni più efficienti come ZSTD, il browser è costretto a negoziare protocolli legacy. Questo si traduce in performance peggiori, caricamenti più lenti e, nel nostro caso, nel fallimento delle ottimizzazioni pensate per i nostri clienti.
Conclusioni
Questa esperienza ci ha insegnato una lezione importante. Quando ci siamo trovati di fronte a connessioni HTTP/3 mancanti e compressioni ZSTD non attive, la prima reazione è stata pensare che il problema fosse nostro: una configurazione errata, un aggiornamento non testato, un parametro sbagliato. La realtà, invece, era completamente diversa.
Il nostro stack era configurato correttamente e funzionava da anni. La vera causa era un software esterno, che agiva in silenzio, alterando il comportamento del browser senza che fosse immediatamente evidente. Nel nostro caso specifico, il colpevole era ESET NOD32, ma la stessa dinamica può verificarsi con molti altri antivirus.
La prossima volta che vi trovate a fare debug di funzionalità come HTTP/3, QUIC o ZSTD, prima di mettere in discussione server, CDN, proxy e configurazioni, chiedetevi se un antivirus stia interferendo con la negoziazione dei protocolli. A volte, la soluzione è molto più semplice di quanto sembri: basta individuare il vero colpevole per risparmiare ore di analisi inutili.
mbri: basta individuare il vero colpevole per risparmiare ore di analisi inutili.
