調整 IIS 設定優化大檔案上傳：解決 48KB 限制與逾時問題

問題背景

瀏覽器上傳大檔案時，IIS 預設僅緩衝前 48KB (49152 bytes) 便傳遞給應用程式 (如 ASP/ASP.NET)，超過部分需應用程式主動請求 (如 Request.BinaryRead(Request.TotalBytes)) 才會繼續傳輸。若應用程式未及時請求，連線將掛起，最終導致 HTTP 413 Request Entity Too Large 或瀏覽器陷入重試死循環。

核心解決方案：調整 UploadReadAheadSize

此 Metabase 屬性控制 IIS 預讀緩衝大小，預設 49152 位元組，最大可設 4GB。

設定方法

• 單一網站： 在 IIS 管理員中，右鍵網站 →「內容」→ 依版本找到 Metabase 編輯器修改
• 全域 IIS： 修改全域 Metabase 設定
• 建議值：根據實際上傳需求設定 (如 10MB = 10485760)，勿盲目設過大

相關屬性協同調整

兩者預設值通常較大，但需確認未被誤設過小。

特殊情境：設為 0 繞過 IIS 緩衝

若上傳由第三方 ISAPI 擴展處理且未遵循標準請求模式，可嘗試將 UploadReadAheadSize = 0，強制 IIS 直接將資料流導向 ISAPI。注意： 這會關閉 IIS 應用程式預讀緩衝，可能影響其他應用效能，需謹慎測試。

安全性警示

過大的 UploadReadAheadSize 會擴大攻擊面：惡意用戶可利用大檔上傳耗盡頻寬/記憶體發動 DoS 攻擊。防護建議：

• 設定恰好滿足業務需求的值 (如業務最大 20MB，設 25MB 即可)
• 強制啟用身份驗證，僅允許受信任用戶上傳
• 結合應用層檔案大小、類型驗證
• 考慮使用上傳元件 (如 ASP.NET FileUpload、第三方元件) 而非裸露 ISAPI

總結檢查清單

1. 確認應用程式正確呼叫 Request.BinaryRead(Request.TotalBytes) 或對應讀取方法
2. 按需調整 UploadReadAheadSize (預設 48KB → 業務需求值)
3. 檢查 maxRequestLength / maxAllowedContentLength 未限制過小
4. 第三方 ISAPI 狀況下嘗試設為 0
5. 落實身份驗證與應用層驗證