為什么 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 集合，更改壓縮級別