Nginx 反向代理導致大檔案下載失敗的原因分析與解決方案

問題現象

在採用 Nginx 反向代理架構（上游同為 Nginx）的環境中，用戶端下載大檔案時，進度條推進至約 1GB 便提示「下載失敗」。若在 Firefox 中選擇續傳，會再下載 1GB 後再次中斷。錯誤日誌顯示：

• 反向代理伺服器：upstream prematurely closed connection while reading upstream
• 被代理伺服器：upstream timed out (60: Operation timed out) while reading response header from upstream

根因分析

1. 連接超時的鏈式反應
   代理端報告上游過早關閉連接，上游則抱怨讀取回應標頭超時。推測：代理伺服器長時間未向上游請求數據，導致上游判定連接閒置而主動斷開；代理端再嘗試讀取時連接已不可用。
2. 正常流程應為持續流式傳輸
   客戶端 → 代理 → 上游 的數據流本應持續不斷，不應出現閒置超時。
3. 核心原因：代理端開啟緩衝導致「假性閒置」
   內網帶寬極高，代理從上游拉取 1GB 數據僅需數十秒，但向客戶端傳輸卻需數十分鐘。此期間代理與上游之間無數據交互，超過 proxy_read_timeout（預設 60s），上游主動切斷連接。

解決方案

方案一：關閉代理緩衝（推薦）

在代理伺服器的 location 或 server 區塊加入：

proxy_pass https://192.168.0.1;
proxy_redirect default;
proxy_buffering off;   # 關鍵：禁用緩衝，實現真正的流式轉發

此設定使代理邊讀邊傳，上游持續有數據流出，不會觸發超時。

方案二：大幅延長上游超時時間

在被代理伺服器的 http、server 或 location 區塊調整：

client_body_timeout 3600;
client_header_timeout 1800;
keepalive_timeout 15;
send_timeout 3600;

注意：四個指令作用不同，若不確定具體影響，建議全部設定，但方案一更符合反向代理的流式轉發本質。

總結

大檔案下載失敗的本質是「高速內網拉取」與「低速外網推送」的速度失衡，導致上游連接閒置超時。關閉 proxy_buffering 實現零拷貝流式轉發 是最乾淨、效能最好的解法；若業務需保留緩衝，則必須配合調大上游各項超時參數。