TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
WordPress 504 Gateway Timeout：依日誌排查根因
WordPress 504 Gateway Timeout 代表閘道等不到上游回應。本文依 Cloudflare、主機、PHP、資料庫與外掛日誌，整理低風險的定位與修復順序。
用 AI 摘要這篇文章：
WordPress 504 Gateway Timeout 表示閘道或代理伺服器在期限內等不到上游回應。它不是單一外掛錯誤碼；可能出在 Cloudflare、Nginx、Apache、PHP-FPM、資料庫、外部 API 或主機資源，先保留日誌再修才不會遮掉根因。
504 多半是主機端超時，反覆重載沒有用；確定要升級或搬家的人，換主機的完整搬遷與設定教學有照著做的順序。
若全站正在大量回傳 504，先停止批次匯入、備份、爬蟲或部署，保留錯誤時間與 request ID；不要一開始就把所有 timeout 數值調大。
先分辨 504 從哪一層產生
如果網站使用 Cloudflare，先閱讀官方 502／504 排查說明，觀察錯誤頁外觀、回應標頭與 Cloudflare 狀態。Cloudflare 品牌錯誤頁通常代表 CDN 無法從來源站取得有效回應；沒有品牌的 504 則更可能由來源端代理產生。
| 範圍 | 優先檢查 |
|---|---|
| 只有單一頁面 | 該頁查詢、短碼、外部 API、頁面建構器 |
| 登入或儲存才發生 | 後台外掛、REST API、PHP worker、資料庫鎖 |
| 全站間歇發生 | CPU、RAM、磁碟 I/O、PHP-FPM 佇列、來源連線 |
| 所有網站都異常 | 主機、反向代理、網路與供應商事件 |
若錯誤碼其實是 502，可對照 WordPress 502 Bad Gateway 排查；若服務暫時不可用或維護中，則參考 503 Service Unavailable 修復。三者原因可能重疊，但要以實際狀態碼與日誌為準。
低風險排查順序
- 記錄時間與網址：包含時區、操作、登入狀態、request ID 與是否能重現。
- 查看服務狀態：確認 CDN、DNS、主機與依賴的外部 API 是否正在故障。
- 查三層日誌：反向代理、PHP／應用程式與資料庫日誌要對齊同一分鐘。
- 查看資源：CPU、記憶體、swap、磁碟、PHP worker 與資料庫連線是否已滿。
- 縮小頁面範圍：判斷是前台、wp-admin、REST、WP-Cron 或單一查詢。
- 在 staging 重現：先停用可疑外掛或切換主題；正式站不要盲目全停。
常見根因與對應修法
| 證據 | 可能根因 | 修法 |
|---|---|---|
| PHP slow log 指向同一函式 | 外掛或主題長任務 | 更新、替換或把工作改成背景佇列 |
| 資料庫出現 lock／慢查詢 | 索引不足、查詢過大 | 優化查詢與索引，縮小批次 |
| PHP-FPM max children reached | worker 用盡 | 先降低耗時，再依 RAM 合理調整池 |
| 外部 API 等待很久 | 第三方逾時 | 設短 timeout、重試上限、快取與降級路徑 |
| 匯入或備份時發生 | 同步工作太大 | 分批、排程到離峰並監控資源 |
只有在工作本來合理、資源也足夠，但代理期限過短時，才同步調整 Nginx、負載平衡器與 PHP 的 timeout。只改其中一層可能仍在更短的那層逾時；無限制拉長則會讓卡住的 worker 佔用更久。
修復後怎麼驗證
- 重做原本會觸發問題的操作，記錄總時間與狀態碼。
- 同時觀察 PHP worker、資料庫連線、CPU、RAM 與 5xx 比例。
- 用低流量逐步增加，不要直接在正式站做未授權壓力測試。
- 為外部 API、慢查詢與佇列長度加告警，避免只等使用者回報。
- 保留修復前後日誌與設定差異，確認不是把 504 延後成更久的等待。
常見問題
清快取能修好 WordPress 504 嗎？
快取損壞或 cache miss 暴增時可能有幫助，但不是通用解法。先看日誌與資源，否則清快取還可能短時間增加來源負載。
要先停用所有外掛嗎？
正式站不建議盲目全停。先用日誌定位，再在 staging 逐一停用或用二分法縮小範圍；緊急事故則依回復計畫執行。
