Table of contents of the article:
In recent months, during our activities of web performance optimization on customer projects Managed Server SRL, we came across some strange behavior that initially left us perplexed. We use HTTP/3 with QUIC protocol and the compression ZSTD (Zstandard) for over two years, with excellent results in terms of speed, efficiency, and connection stability. Throughout this time, the implementations have always worked flawlessly: browsers negotiated HTTP/3 correctly, ZSTD compression was enabled for HTML, CSS, and JavaScript, and site performance was in line with expectations.
However, suddenly, something changed. During some routine tests, we began to notice that connections that until recently had been handled correctly via HTTP / 3 now they almost always fell back on HTTP / 2, while the text resources we had configured to be compressed in ZSTD were suddenly served with Brotli or even gzipIt was as if, from one day to the next, our optimizations no longer existed.
This situation was both unusual and frustrating. Considering that our stack had been configured in a stable and functional manner for years, it didn't make sense for it to suddenly behave differently. This led to a rather in-depth technical investigation to understand what was happening.
The Initial Investigation: Suspicions About NGINX
The first step was the most natural one for those who deal with infrastructure and web performance: verify the behavior of our NGINX Web ServerLogic told us that a recent update or some change to the compilation flag It could have changed the way the server handled QUIC and ZSTD. We analyzed the configurations in detail, verified the loaded modules, and even double-checked the compatibility of the versions in use.
To eliminate any doubt, we also created a completely clean test environment, installing NGINX from scratch with our minimal necessary settings, without any customization. The idea was simple: eliminate any possible external interference and observe the protocol and compression behavior in an isolated context.
The result, however, was surprising. Even on a clean and minimal installation, HTTP/3 was not negotiated e ZSTD continued to go unusedAt that point it was clear that the problem was not related to NGINX, nor to our server configurations.
The Red Herring: Network and MTU Issues
Having ruled out the possibility that our web server was the cause, we began to look elsewhere. Since HTTP / 3 It is based on the protocol HERE C, which he uses UDP rather than TCP, we hypothesized that the issue could be related to some network parameter. In particular, we suspected that theMTU (Maximum Transmission Unit) could influence the negotiation of the protocol.
We tested several configurations: first the default value of 1500 bytes, then more conservative settings, such as 1400 and even 1300 bytes, to see if smaller packets would facilitate the transition to QUIC. Even in this case, however, the results remained unchanged: the connection continued to fall back to HTTP/2, and compression remained stuck on Brotli or gzip.
It was clear that the problem was neither with our stack nor with the network. But the strangest thing was that, comparing historical logs, we discovered that negotiations had been working perfectly until a few weeks earlier. From that point, we began to suspect that something external to our infrastructure was influencing the connection behavior.
The discovery: even the big ones have the same problem
To understand whether the phenomenon was limited to our servers or had a wider scope, we decided to run some tests on websites of large international corporationsWe have analyzed the behavior of giants such as Amazon, Google, Microsoft and even some major newspapers. The discovery was surprising: even on those platforms, connections were almost never negotiated in HTTP/3 e ZSTD was not used.
This allowed us to definitively rule out the server-side problem. If large companies with multi-million dollar infrastructure, dedicated engineering teams, and advanced optimization processes were unable to properly negotiate HTTP/3 and ZSTD, it was clear that the cause had to be found elsewhere. on the client side.
The decisive insight: the suspicion about the antivirus
When you exclude everything under your control, you start looking at the components you usually take for granted. In this case, the focus shifted to locally installed software. We knew that on the test systems, ESET Antivirus NOD32.
Modern antiviruses, to analyze HTTPS traffic, adopt a strategy that many users are not aware of: they establish a local proxy This intercepts all browser connections, analyzes their contents, and only then forwards them to the remote server. In other words, the browser never communicates directly with the site, but with an intermediary that can modify, filter, or reinterpret the connection.
If this proxy does not support the latest versions of compression protocols or algorithms, the browser is forced to a automatic fallback on older, more compatible technologies. That's why connections suddenly dropped on HTTP / 2 and the compressions went back to use Brotli or gzip: It was not the server's fault, but rather client-side interference.
Confirmation: Uninstall your antivirus
To confirm the hypothesis, we decided to do a drastic experiment. We removed ESET Antivirus NOD32 from the test systems, rebooted the machine, and repeated the checks. The result was immediate: the browsers began negotiating again. HTTP/3 / QUIC correctly and compression ZSTD it went back to working exactly as before.
After weeks of testing, exclusions, and verification, we finally found the cause. The antivirus, with its local proxy, was interfering with connection negotiation and preventing the optimizations we had implemented long ago.
Why it happens and why it's not just about ESET
What we found wasn't an isolated bug, but a direct consequence of how modern Windows antivirus programs work. Many of them, not just ESET, use the same interception strategy via a local HTTPS proxy. This means that software like Avast, Kaspersky, Bitdefender, McAfee and many others could cause the exact same behavior.
Whenever an antivirus program places itself between the browser and the network, it takes control of the connection and partially manages its features. If the proxy isn't updated to support modern protocols like HTTP / 3 or more efficient compressions such as ZSTD, the browser is forced to negotiate legacy protocols. This results in poorer performance, slower loading times, and, in our case, the failure of optimizations designed for our customers.
Conclusions
This experience taught us an important lesson. When we were faced with connections HTTP/3 missing and compressions ZSTD not active, the first reaction was to think the problem was ours: an incorrect configuration, an untested update, an incorrect parameter. The reality, however, was completely different.
Our stack was configured correctly and had been working for years. The real cause was external software, which was acting silently, altering the browser's behavior without it being immediately apparent. In our specific case, the culprit was ESET NOD32, but the same dynamic can occur with many other antivirus programs.
Next time you find yourself debugging features like HTTP / 3, HERE C o ZSTDBefore questioning servers, CDNs, proxies, and configurations, ask yourself whether an antivirus program is interfering with protocol negotiation. Sometimes, the solution is much simpler than it seems: simply identifying the real culprit can save you hours of wasted analysis.
mbri: just identify the real culprit to save hours of useless analysis.
