IIS 啟用 GZIP 失效排查：通配符應用程式映射才是隱形殺手

GZIP 壓縮配置無誤、權限正確、ISAPI 篩選器逐個排查後仍不生效？真兇可能藏在「主目錄 → 配置 → 通配符應用程式映射」裡。本文記錄一次耗時一週的排查實戰，揭示非標準映射如何攔截壓縮模組。

排查路徑回顧

1. 確認基礎配置：metabase.xml 中 HcDoDynamicCompression/HcDoStaticCompression 為 TRUE，壓縮目錄權限給 IIS_WPG/NETWORK SERVICE。
2. 排查 ISAPI 篩選器：保留 URL Rewrite、ASP.NET、PHP 核心篩選器，刪除其餘第三方篩選器 → 重啟 IIS → GZIP 仍無輸出。
3. 鎖定通配符映射：檢查「網站屬性 → 主目錄 → 配置 → 通配符應用程式映射」，發現某業務系統註冊了 * 映射到自定義 DLL。刪除該映射 → 重啟 IIS → HTTP 響應頭即出現 Content-Encoding: gzip，線上檢測工具確認生效。

根因分析

通配符映射 (*) 會攔截 所有 請求（含靜態文件、動態腳本），導致請求在進入 IIS 靜態/動態壓縮模組前，先被自定義 DLL 處理。若該 DLL 未正確傳遞壓縮相關的 Server Variables (如 HTTP_ACCEPT_ENCODING) 或未調用後續通知，壓縮模組永不觸發。

最佳實踐建議

• 避免使用通配符映射：改用具體副檔名映射 (如 .aspx, .php) 或原生模組 (Managed Modules)。
• 若業務強制需通配符，開發方必須在 DLL 中正確實現 SF_NOTIFY_SEND_RAW_DATA 等通知，透傳壓縮協商頭。
• GZIP 故障排查清單：配置 → ISAPI 篩選器 → 通配符映射 → 模組順序 → 權限 → 磁盤空間，逐項排除。

後續跟進

已將問題反饋給該通配符映射開發商，要求修復兼容性。臨時方案：在該網站下建立獨立應用程式池，隔離風險。