2026.11.10

Nginx 上傳回傳 413？找出請求大小限制並只調整目標路徑

檔案上傳在瀏覽器收到 HTTP 413，代表某一層認為請求內容過大。流量可能先經 CDN、負載平衡器，再到 Nginx 和應用程式；不能只因畫面顯示 413 就假定限制一定在 PHP 或 Nginx。先使用沒有個資的測試檔，記下檔案大小、網址、時間與錯誤回應。

先辨認是哪一層拒絕

開啟瀏覽器開發者工具 Network，重送一次測試並選取上傳請求，查看狀態、Response Headers 和回應內容。再請管理者比對同一時間的 CDN、代理及 Nginx access／error log。標頭可能被代理改寫，單靠 Server 標頭不足以確定來源。用小檔與接近門檻的測試檔比對；multipart 表單還有額外欄位與編碼開銷，請求大小不會等於單一檔案大小。既有 WordPress 媒體上傳其他錯誤可參考上傳錯誤排查。

檢查 Nginx 的有效設定

擁有伺服器管理權且確認是 Nginx 拒絕後，先備份受管的設定檔，查看目前載入的組態與對應站台。以下命令可能列出敏感路徑、上游與設定，請避免公開完整輸出：

sudo nginx -T

找到請求實際命中的 server 與 location，檢查該處及上層的 client_max_body_size；更具體的設定可能覆蓋上層。預設為 1m，但系統套件、控制台或其他 include 可能已調整；以實際載入組態為準。Nginx 文件說明此指令可設於 http、server 或 location。nginx -T 會測試並列出設定，不能只搜尋到某一行就斷言它適用於目標請求。

只在必要範圍調整並測試

確認產品需求、磁碟與上游限制後，於實際負責上傳的既有 location 設定合理上限，例如 client_max_body_size 32m;。不要複製建立另一個相同 location，也不要設為 0 無限制。若設定由控制台或自動部署產生，應透過其受管方式變更，避免之後被覆蓋；CDN 或應用程式的限制仍需分別核對。

sudo nginx -t
sudo systemctl reload nginx

第二行只在第一行測試成功、服務由 systemd 管理且已確認維護影響時執行。重新載入後，使用授權測試帳號上傳符合需求的無敏感資料檔案，確認應用程式實際保存成功；再用超出政策上限的測試檔確認限制仍生效，並查看日誌。若原本 413 消失卻變成應用程式錯誤，繼續查上游與應用程式限制，不要反覆提高 Nginx 上限。