修復 Nextcloud 2GB 上傳限制：如何允許上傳大文件

Nextcloud 上傳檔案大小限制在 2GB 通常是因為請求路徑中的某個環節限制了檔案大小，而不是 Nextcloud 的某個通用設定。要接受更大的文件，需要在處理上傳的每個環節（包括 PHP、Web 伺服器以及任何反向代理或主機控制面板）都設定高於文件大小的目標值。然後確認儲存空間、臨時空間和請求超時時間足以支援此傳輸。

本指南以 5 GB 的目標大小為例，適用於最約 4 GB 的檔案。請根據您的實際使用場景選擇合適的限制，並在必要時預留請求開銷空間，並確保整個技術堆疊的設定一致。這些範例適用於使用 PHP 的自架 Nextcloud 伺服器；託管主機、容器和專用裝置可能會提供不同的設定路徑。

為什麼 2GB 的上傳會失敗

Nextcloud 目前的管理手冊解釋說，大檔案上傳會受到 PHP 和 Web 伺服器配置的限制。分塊上傳時，瀏覽器或用戶端會傳送多個檔案片段，Nextcloud 會將它們組裝起來；某些 PHP 檔案大小指令可能不受這些要求的限制，但 Web 伺服器或 PHP 的逾時機制仍然有效。代理程式、防火牆、儲存後端、使用者配額或臨時磁碟已滿等因素也會造成限制。請參閱Nextcloud 大檔案上傳管理指南和Nextcloud 大檔案上傳使用者指南。

「2 GB」也可能指 2,000,000,000 位元組或 2 GiB（2,147,483,648 位元組）。顯示的限制和實際的位元組閾值可能並不完全匹配。請記錄錯誤訊息、檔案大小（以位元組為單位）以及故障是立即發生還是在開始運行後發生。這些細節有助於確定要檢查的層。

1. 找出第一個拒絕上傳的層

在更改設定前，請記下文件上傳方式：Nextcloud 網頁介面、桌面或行動同步用戶端，或是 WebDAV 應用程式。測試文件時，請上傳一個略大於舊閾值的文件，但不要在故障排除期間重複上傳數 GB 的文件。故障發生時，請檢查 Nextcloud 的管理概覽和日誌、Web 伺服器錯誤日誌、PHP-FPM 或 Apache 日誌，以及任何代理程式或主機控制面板。

• 立即收到的 HTTP 413 回應通常表示 Web 伺服器或代理程式的請求體長度有限制。
• PHP 警告提示檔案大小超過允許限制，該警告指向常規 multipart 請求的 PHP 上傳設定。
• 傳輸開始後停滯或逾時，表示請求逾時、連線中斷或資源不足。
• 明確的配額訊息意味著用戶可用的 Nextcloud 儲存空間不足，而不是伺服器上傳上限成為限制因素。

這些只是線索，並非最終診斷：代理伺服器可能會掩蓋應用程式錯誤，而且不同部署環境的日誌也會有所不同。在編輯配置之前，請先比較各層日誌的時間戳記。

2. 設定瀏覽器表單上傳的 PHP 限制

找到面向 Web 的 Nextcloud 進程所使用的 PHP 配置。在 Debian 或 Ubuntu 系統中，典型的 PHP-FPM 檔案位於 `/etc/php.conf` 目錄下/etc/php/<version>/fpm/php.ini；而使用 mod_php 的 Apache 通常使用單獨的apache2/php.ini`/etc/php.conf` 檔案。 PHP 命令列配置可能有所不同，因此php --ini僅編輯 `/etc/php.conf` 報告的檔案可能不會變更網站。 Nextcloud 的PHP 設定指南描述了伺服器端的設定上下文。

如果記憶體上限為 5 GB，請檢查目前 Web PHP 配置中的以下設定：

upload_max_filesize = 5G
post_max_size = 5G
max_input_time = 3600
max_execution_time = 3600

post_max_size至少應upload_max_filesize與目標大小相同；將兩者都設定為相同的目標大小是單一檔案分段上傳的實用起點。以上時間值僅供參考，並不保證傳輸一定能夠完成：請根據您的可用頻寬和操作策略選擇合適的持續時間。不要memory_limit因為檔案大小為 5 GB 就將 PHP 的上傳限制也增加到 5 GB。 PHP 文件中提到，上傳限制max_input_time包含接收上傳輸入所花費的時間，且上傳行為取決於相關指令；請參閱PHP 上傳陷阱文件。

3. 提高 Web 伺服器請求限制

使用 PHP-FPM 的 Nginx

在 Nextcloud 的活動 Nginx 伺服器區塊中，設定一個請求體上限，使其高於您打算接受的最大檔案大小。例如，對於 5 GB 的檔案：

client_max_body_size 5G;

將其放置在合適的 `<head>` http、server`<head>` 或 ` location<head>` 上下文中，避免在更具體的程式碼區塊中使用衝突的較小值。 Nginx 在其核心模組參考文件中對此指令進行了說明。 Nextcloud 的Nginx 安裝範例也包含了上傳大小和逾時設定。在重新載入 Nginx 之前，請使用 `<command>` 指令驗證設定sudo nginx -t。

阿帕契

檢查活動虛擬主機、目錄配置或包含的配置是否已設定LimitRequestBody。對於預設或明確限制低於目標值的 Apache 版本，請將其提高到所需的位元組數，或0僅在部署允許的情況下才使用無 Apache 等級限制。確認該指令位於 Apache 版本和設定允許的上下文中。 Apache 在LimitRequestBody 文件apachectl configtest中描述了其行為。在重新載入服務之前執行此命令。

4. 檢查反向代理、容器和存儲

如果流量經過另一個 Nginx 執行個體、負載平衡器、主機控制面板或安全代理，則其請求體大小和逾時限制也必須允許上傳。請求可能在到達 Nextcloud 之前被拒絕。僅更新擁有該設定的層，然後檢查其日誌和回應代碼。對於 Docker 或其他容器部署，請變更掛載到執行容器中的配置或該映像支援的環境設定；容器可能根本不會使用主機上的 PHP 檔案。

上傳大檔案也會消耗資源。請確認 Nextcloud 資料卷有足夠的可用空間，並且 PHP 或 Web 伺服器的臨時目錄能夠容納上傳的工作負載。分塊上傳時，可能需要臨時空間來組裝各個資料塊；物件儲存部署可能需要額外的臨時磁碟空間。請規劃同時上傳多個文件的情況，而不僅僅是單一文件的最大大小限制。在繁忙的部署環境中提高上傳限制之前，請務必查看 Nextcloud 關於臨時空間和大文件上傳的章節。

5. 應用變更並通過受控測試進行驗證

配置檢查通過後，重新載入或重新啟動相關的 PHP-FPM 和 Web 伺服器服務，以便它們讀取更新後的設定。具體的服務名稱會因發行版和 PHP 版本而異。避免重啟無關的生產服務。然後，使用先前上傳失敗的用戶端和路由，上傳一個略大於先前 2 GB 限制的檔案——例如一個大約 2.1 GB 的已知測試檔案。確保測試檔案的大小不超過新的限制，並監控可用磁碟空間、日誌和傳輸進度。

成功的測試應該不會出現 HTTP 大小錯誤或逾時，檔案會出現在預期的 Nextcloud 資料夾中，並且在客戶端檢查時檔案大小也應合理。對於重要文件，如果您的工作流程支持，請比較來源文件和目標文件的校驗和。進度條達到 100% 並不能證明儲存的文件已完成。

當這種修復方法還不夠時

• 網頁上傳正常，但桌面用戶端上傳失敗：請檢查用戶端、代理程式和伺服器的逾時行為。 Nextcloud 用戶端使用分塊上傳，因此upload_max_filesize僅修改 PHP 程式碼可能無法解決分塊請求或最終組裝逾時的問題。
• 錯誤提示使用者空間不足：請調整該使用者的 Nextcloud 配額或可用儲存空間；增加請求限制並不會增加容量。
• 每個用戶端在相同的位元組數處發生故障：尋找共享代理、WAF、託管提供者或 Web 伺服器限制，並將其日誌與請求關聯起來。
• 上傳完成但佔用過多臨時磁碟空間：減少並發上傳，確保足夠的臨時儲存空間，或查看後端文件中記錄的分塊和儲存行為。

提高上傳限制會增加使用者可以發送到伺服器的檔案數量，因此應該配合配額、監控、充足的儲存空間和合理的存取控制。沒有一個通用的安全上限：實際上限取決於請求路徑中最慢的環節以及伺服器和儲存系統的容量。

參考

• Nextcloud 伺服器管理手冊：上傳大文件
• Nextcloud 伺服器管理手冊：PHP 配置
• NGINX 文件：client_max_body_size
• Apache HTTP 伺服器文件：LimitRequestBody
• PHP手冊：常見上傳陷阱