Windows11下Express的compression()中间件失效问题排查

你的猜测完全正确——ESET互联网安全软件的Web防护模块会在本地拦截并修改HTTP响应，这就是Chrome网络面板看不到压缩差异的核心原因，底层运行机制如下：

1. ESET的本地代理拦截逻辑 #

• ESET会在Windows系统中部署本地HTTP/HTTPS代理服务，强制接管浏览器的所有网络请求，相当于在浏览器和服务器之间插入一个“中间人”节点。
• 当服务器返回gzip/deflate格式的压缩响应时，ESET代理会先自动解压响应内容，执行病毒扫描、漏洞检测（比如检查脚本恶意代码、XSS注入风险等）。
• 扫描完成后，代理会将解压后的明文内容转发给Chrome浏览器，同时修改响应头（比如移除Content-Encoding字段，或替换为非压缩标识）。
• 这种情况下，Chrome网络面板显示的是代理转发的明文大小，而Wireshark抓包的是服务器到ESET代理的原始流量，所以能看到真实的压缩数据。

2. Linux Mint下正常的原因 #

• 要么你在Linux上未启用ESET的Web防护/HTTP扫描功能，要么Linux版ESET的代理拦截规则默认不处理本地开发环境的请求；也有可能Linux下浏览器未被强制走ESET代理，直接与服务器建立连接，因此能显示真实的压缩大小。

3. 快速验证方法 #

• 临时关闭ESET的「Web保护」或「HTTP/HTTPS扫描」功能，重启Chrome后刷新页面，查看网络面板的资源大小，此时应该能看到压缩后的数值。
• 检查Chrome代理设置：打开chrome://settings/system，点击「打开您计算机的代理设置」，若显示使用127.0.0.1某个端口的代理（ESET默认代理端口通常为8080或其他自定义端口），则坐实流量被拦截的判断。

内容的提问来源于stack exchange，提问作者AxelBlaze