提高 WordPress 上傳檔案大小上限

有三個設定控制著 WordPress 的上傳上限，而且它們必須彼此一致。實際生效的上限是 upload_max_filesize、post_max_size 以及網站伺服器請求上限三者中最小的那一個。你只調高其中一個、卻讓另外兩個維持在很低的數值，結果什麼都不會改變——這正是為什麼多數人會認定自己的修正「沒有效」。請先用 WordPress 上傳檔案大小上限工具檢查你目前的數值；它讀取的是與 WordPress 回報相同的值，並會告訴你是哪一個在拖後腿。

這個上限為什麼存在，又存在於哪裡

WordPress 並不會設定上傳上限，它只是回報而已。當你看到「上傳的檔案超過了 php.ini 中 upload_max_filesize 參數的設定值。」這則訊息時，它是直接來自 PHP 的。

有三個各自獨立的值在把關一次上傳，真正的天花板就是其中最低的那一個：

• upload_max_filesize（PHP）——PHP 願意接受的單一檔案最大值。
• post_max_size（PHP）——整個 POST 主體的最大值。你的檔案是連同其他表單欄位一起夾在 POST 請求裡的，所以這個值必須大於 upload_max_filesize。
• 網站伺服器的主體大小上限——在 Nginx 上是 client_max_body_size，在 Apache 上則是 LimitRequestBody。這個值完全存在於 PHP 之外，這也是為什麼在 Nginx 背後，只改 PHP 的修正會悄悄失效。

第四個值 max_execution_time 並不限制大小，但在連線品質不佳時，它會在傳輸途中中止一個緩慢的大型上傳。這是另一種獨立的症狀，並不屬於大小天花板的一部分。

陷阱在於：你把 upload_max_filesize 設成 256M、重新載入，卻還是無法上傳一個 100 MB 的檔案——因為 post_max_size 仍然是 8M。PHP 早在檢查那個檔案之前，就先因為整個主體過大而拒絕了請求。並不是那個上限沒理你，而是另一個上限先把它攔了下來。

該如何依序修正

從最有可能一勞永逸的做法，一路做到最後手段。

1. 編輯 php.ini（正確的地方）。 找到你的網站實際載入的那個檔案——用 <?php phpinfo(); 執行一個頁面，然後看「Loaded Configuration File」，或者直接問你的主機商。把兩個 PHP 值都設好，並讓 post_max_size 保持大於 upload_max_filesize：

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

重新啟動 PHP-FPM（sudo systemctl restart php8.2-fpm）或 Apache。在 PHP 程序重新啟動之前，任何變更都不會生效。

2. 沒有 php.ini 的存取權限？改用 .htaccess（僅限 Apache + mod_php）。 在你 WordPress 根目錄的 .htaccess 中加入：

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

這只有在 PHP 以 Apache 模組的形式執行時才有效。在 PHP-FPM、CGI 或 FastCGI 之下，php_value 會拋出 500 錯誤——這個失敗代表你走錯方向了，而不是數值設錯了。改用 .user.ini：

upload_max_filesize = 256M
post_max_size = 260M

3. 調高網站伺服器的上限——大家都會忘記的一步。 在 Nginx 上，PHP 根本連過大的請求都看不到；Nginx 會先回傳 413 Request Entity Too Large。在你的 server block 中加入：

client_max_body_size 256M;

用 sudo nginx -t && sudo systemctl reload nginx 重新載入。如果你用的是 Nginx，而你改的 PHP 設定「毫無作用」，幾乎都是因為這個原因。

任何變更之後，請重新檢查回報出來的數值。上傳檔案大小上限工具會告訴你新的實際上限，並針對你的環境產生確切的程式碼片段，這樣你就不用猜三者中到底還有哪一個是低的。

不該做的事

別以為編輯 wp-config.php 就能提高上限。 那行被到處複製的程式碼，並不會做到那些部落格文章聲稱的事：

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize 屬於 PHP_INI_PERDIR。它無法在執行期用 ini_set() 從 PHP 內改變。它只接受來自 php.ini、.htaccess 或 .user.ini 的新值——絕不接受來自應用程式碼的值。那行程式碼執行時不會報錯，卻什麼也沒做，這使它成為 WordPress 圈裡最被信心滿滿地重複轉述的錯誤建議之一。

也別貼上 @ini_set('post_max_size', ...)——同樣的限制、同樣悄無聲息地毫無作用。

別把 WP_MEMORY_LIMIT 設一設就以為那是上傳上限。 那控制的是 PHP 執行程式碼時的記憶體上限，跟伺服器能接受多大的檔案毫無關係。

別只改一個檔案就停手。 最常見的失敗，就是只改了 upload_max_filesize 一項，然後就斷定這修正沒用。三個都要改，並讓 post_max_size 保持在 upload_max_filesize 之上。

別「為了保險起見」把上限設得高得離譜。 一個 2 GB 的上限會招來資源耗盡的問題，而且也幫不上忙——如果你真的需要處理數 GB 的檔案，就繞開瀏覽器來上傳（用 SFTP，或是分塊上傳的外掛），而不是硬把它們塞進單一個 PHP POST。

還是卡住嗎？

如果三個值都已調高，你卻仍然撞牆，那麼這個請求是在你伺服器上游的某處被設了上限：可能是 CDN 或代理伺服器（Cloudflare 的控制台會自行限制上傳主體大小）、代管主機平台自身、無視你 php.ini 的限制，或者是還沒重新整理的 .user.ini——它遵循 PHP 的 user_ini.cache_ttl，所以在你儲存之後，它可能會延遲幾分鐘才更新。請確認伺服器實際回報的內容，而不是你在檔案裡寫了什麼，然後去修正那個仍然偏低的層級。當回報出來的數字終於與你的目標一致時，上傳就會成功。