为什么 gzip 压缩在 IIS 8.5 上不起作用？

Question

我无法在 Server 2012 R2 机器上的 IIS 8.5 上使用 gzip 压缩。 我做了一些研究，并按照这些帖子中的说明进行了操作：

1. 如何在 IIS 7.5 中启用 GZIP 压缩
2. IIS 8.5 中的压缩不成功，说明 ALREADY_CONTENT_ENCODING
3. IIS 7.5 上的 GZip 压缩不起作用
4. gzip 压缩不适用于 IIS 8.5

这是我的配置的相关部分：

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" staticCompressionIgnoreHitFrequency="true">
    <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
    <!-- I have read that dynamic compression increases server CPU load.
    <dynamicTypes>
        <add mimeType="text/*" enabled="true"/>
        <add mimeType="message/*" enabled="true"/>
        <add mimeType="application/javascript" enabled="true"/>
        <add mimeType="*/*" enabled="false"/>
    </dynamicTypes>
    -->
    <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </staticTypes>
</httpCompression>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />

此外，在 IIS 中，我将压缩设置为适用于大于 256 字节的任何内容。 我已经执行了iisreset。

尽管如此，我在 Chrome 或 IE 的开发控制台中没有看到提到的压缩，PageSpeed 仍然告诉我压缩内容。 我错过了什么简单的步骤？

Answer 1

很难理解发生了什么。假设您已正确完成所有 IIS 设置。

• 为了检查压缩是否正常工作，您如何访问该网站。 例如，如果您使用 FQDN www.example.com，请尝试使用 localhost url。 这将确保您的 IIS 设置正确。
• 如果 localhost 工作正常而您的完全限定域名不起作用，那么问题可能出在网络上。为了压缩工作，浏览器需要发送请求头accept-encoding:gzip, deflate 。 很多时候，您的代理或负载平衡器可以修剪此标头，而此标头可能无法到达 IIS 服务器。因此，即使所有设置都正确，IIS 也永远不会压缩。

要验证请求发生了什么以及 IIS 未压缩请求的原因，您可以执行以下操作。

• 确保您已安装失败请求跟踪。
• 配置您的失败请求定义
  • 转到失败请求跟踪模块
  • 点击侧边栏的添加
  • 启用所有内容和状态为200-999
  • 并完成配置。
  • 现在重现该问题，您将获得在目录 C:\\inetpub\\logs\\FailedReqLogFiles\\W3SVC 中捕获的跟踪。
  • 打开跟踪文件（对于每个请求都会生成一个文件。在 IE 中打开跟踪文件（确保请求详细信息与您要验证的请求匹配）并转到紧凑视图
  • 搜索压缩并检查原因

Answer 2

正如对 OP 链接到的问题之一的回答中所述，请务必检查服务器上运行的任何防病毒软件。 就我而言，它是 ESET。 在禁用相关 ESET 设置之前，所有 IIS 压缩设置均无效。

我省略了设置的详细信息 - 我做了一些看起来很全面的禁用，然后让 IT 找出哪种确切设置最适合在保持安全性的同时压缩仍然有效。

Answer 3

我有一个类似的问题，是由 ESET 引起的，有一些奇怪的行为。 它适用于某些机器，但不适用于带有 eset 的机器，我花了一些时间才意识到。

发生的事情是 ESET 导致 chrome 将 http2 请求降级到 http 1.1 而没有压缩它们。 如果您打开网络并启用“协议”列，则可以看到它。 删除 eset 后，即使我强制 chrome 使用带有“--disable-http2”标志的 http1.1，它也能工作

无论如何，如果它仍然不起作用，我会尝试（除了其他答案）：

• 检查不同客户端的行为是否相同（在我的情况下，只有开发机器有问题）
• 部署一个简单的静态站点（事件默认站点）并进行测试
• 重新安装 iis
• 检查 iss 服务器管理器上的设置，配置编辑器/system.webServer/httpCompression 集合，更改压缩级别