網站又掛了？502 Bad Gateway / 504 Gateway Timeout 排雷指南：從 Nginx 到 PHP-FPM 的除錯實戰

WordPress 網站跳出 502 Bad Gateway 或 504 Gateway Timeout，客戶電話快把手機打爆了嗎？先深呼吸，別急著無腦重啟伺服器。這兩個錯誤碼其實是 Nginx 在告訴你「後端出事了」，照著正確的除錯路徑從 Nginx 一路查到 PHP-FPM，會比亂槍打鳥快得多。

先別急著重啟伺服器（雖然我知道你很想），重啟通常只是把問題往後延一小時發生而已。身為工程師，我們解決問題不能靠運氣，要靠邏輯。

這這兩錯誤代碼是 WordPress 架構中最經典的「通訊不良」問題，通常發生在 Nginx（網頁伺服器） 與 PHP-FPM（後端處理器） 之間的溝通破裂。今天這篇，我不講虛的，直接帶你看 Config 檔，從根源解決這些讓人生無可戀的 HTTP 錯誤代碼。

為什麼會發生 502 與 504 錯誤？工程師視角的解讀

在我們動手改 Code 之前，你得先搞懂它們到底在抱怨什麼。現在的 WordPress 高效能架構（例如我們常提到的 Cloudways 或自架 VPS），通常是使用 Nginx 作為反向代理，配合 PHP-FPM 來執行 PHP 程式碼。

• Nginx 是外場服務生：負責接收訪客的點單（HTTP Request）。
• PHP-FPM 是內場廚師：負責實際炒菜（執行 WordPress 核心、外掛、佈景主題）。

502 Bad Gateway (錯誤的閘道)

這代表服務生（Nginx）把單子送進廚房，但廚房傳回來的不是菜，而是一個無效的回應，甚至是廚師直接昏倒了（PHP Worker Crash）。這通常意味著 PHP-FPM 進程已死，或者 Nginx 的 Buffer 設定太小，裝不下廚師做好的大拼盤。

504 Gateway Timeout (閘道逾時)

這代表服務生（Nginx）在出菜口等了太久，廚師（PHP-FPM）還沒把菜做好。這通常發生在執行耗時的任務（如匯入大量商品、備份網站、或被爛外掛卡死）時，超過了 Nginx 預設的等待時間。

第一步：別瞎猜，看 Log 才是真理

很多人問我：「Eric，我該調大哪個參數？」我都會回：「你看了 Error Log 沒？」不看 Log 就調參數，跟蒙眼開車沒兩樣。

請進入你的伺服器（SSH），查看 Nginx 的錯誤日誌。通常位於：

/var/log/nginx/error.log

如果你看到類似以下的訊息，那就是我們今天的目標：

• upstream timed out (110: Connection timed out) while reading response header from upstream → 這是 504，PHP 跑太慢了。
• recv() failed (104: Connection reset by peer) while reading response header from upstream → 這是 502，PHP-FPM 可能崩潰或重啟了。
• upstream sent too big header while reading response header from upstream → 這是 502，Nginx 的 Buffer 太小。

實戰一：解決 504 Gateway Timeout (延長等待時間)

如果你的網站是因為匯入資料或執行長任務而掛掉，我們需要告訴 Nginx 和 PHP：「多點耐心，別急著掛電話。」

1. 修改 PHP 設定 (php.ini)

首先，確保 PHP 本身允許跑這麼久。

max_execution_time = 300
max_input_time = 300

2. 修改 PHP-FPM Pool 設定 (www.conf)

如果你用的是 PHP-FPM，還要檢查 request_terminate_timeout。如果這裡設定 30秒，就算你 PHP 設定 300秒，FPM 也會強制殺掉進程，導致 502。

request_terminate_timeout = 300s

3. 修改 Nginx 設定 (nginx.conf 或 server block)

這步最關鍵。你需要告訴 Nginx 願意等 PHP 多久。在你的 location ~ \.php$區塊中加入：

fastcgi_read_timeout 300;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;

Eric 的囉嗦：時間設太長（例如 3600秒）不是好事，這會讓你的 PHP Worker 被佔用無法釋放，如果是被 DDoS 攻擊，你的伺服器很快就會資源耗盡（OOM）。300秒通常是極限了。

實戰二：解決 502 Bad Gateway (Buffer 與 Worker 調校)

如果 Log 顯示 header too big，或是你發現只要頁面稍微複雜一點就掛掉，這通常是 Nginx 的緩衝區（Buffer）不夠大。

1. 加大 Nginx FastCGI Buffer

預設的 Buffer 很小，當 WordPress 吐出巨大的 HTML 或 Header 時（有些 Page Builder 或複雜的主題會這樣），Nginx 會因為裝不下而報錯。請在 Nginx 設定檔加入：

fastcgi_buffer_size 32k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_size 64k;

2. 調整 PHP-FPM 的 pm.max_children

如果你的網站流量暴增，現有的 PHP Worker 全部都在忙（Busy），新的請求進來沒人接單，也會導致 502 甚至 504。這時候你需要根據你的記憶體（RAM）來算數。

假設你有 4GB RAM，扣除系統保留，每個 PHP Process 大概吃 60MB-100MB（看外掛多寡）。

pm = dynamic
pm.max_children = 50  ; 不要盲目設大，設太大會記憶體溢出(OOM)導致 MySQL 被殺掉
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

最新技術趨勢：PHP 8.2+ 與 JIT 的影響

根據 2024-2025 的最新技術趨勢，升級到 PHP 8.2 或 8.3 對於減少 504 錯誤有顯著幫助。PHP 8.x 的運算效率比 7.4 高出許多，這意味著同樣的程式碼，廚師炒菜的速度變快了，自然就不容易超時。

此外，如果你的伺服器負載很高，可以考慮開啟 Opcache JIT (Just-In-Time) 編譯，這對於 CPU 密集型的 WordPress 任務（如圖片處理、複雜計算）能有效降低 CPU 負載，間接減少 502 發生的機率。

Eric 的總結：架構思維大於參數調整

解決 502/504 不只是「把數字調大」這麼簡單。如果你發現調大參數後，網站只是從「馬上掛掉」變成「轉了很久之後掛掉」，那你應該檢查的是程式碼品質。

• 是不是有外掛在做無限迴圈？
• 是不是資料庫查詢（SQL Query）沒加索引（Index）？
• 是不是外部 API（如串接物流或金流）卡住沒回應？

真正的高手，是從 Log 中聽出伺服器的求救訊號，而不是盲目地加大藥量。

推薦閱讀與延伸學習

想更深入了解伺服器架構與排錯？這裡有幾篇我之前寫的深度文章，建議搭配服用：

• Nginx 設定檔不再是天書！WordPress 效能調校實戰：從 Worker 到 PHP-FPM，親手打造火箭級網站
• 網站半夜又掛了？別再瞎猜！終極 WordPress 伺服器 Log 監控指南，揪出隱形殺手！
• 網站更新還在掛「維護中」？資深工程師揭秘 WordPress 零停機部署 (Zero Downtime) 的終極魔法