網站突然跳出 502 Bad Gateway 或 503 Service Unavailable，最直覺的動作就是一直按重新整理。
偶發錯誤可能很快恢復，但若反覆發生，就值得記錄時間與頁面。比較有效率的做法，是先確認「哪一層回傳錯誤」，再依序檢查主機、PHP、WordPress、資料庫與 CDN，讓每個調整都有依據。
502 和 503 有什麼不同？先把錯誤碼看對
| 狀態碼 | 正式名稱 | 代表意思 | 常見方向 |
|---|---|---|---|
| 502 | Bad Gateway | 閘道器／代理從上游收到無效回應 | 反向代理、Web Server、PHP、上游服務 |
| 503 | Service Unavailable | 伺服器目前暫時無法處理請求 | 維護、過載、資源限制、服務暫停 |
| 504 | Gateway Timeout | 閘道器等待上游回應逾時 | 慢查詢、PHP 執行太久、上游服務過慢 |
因此，502 應優先追查代理與上游服務的回應；503 則要檢查維護狀態、資源負載與服務可用性。最終仍須結合發生時間、頁面範圍、錯誤紀錄與資源監控，才能確認真正原因。
先做 30 秒判斷：整站、單一功能，還是特定網路？
開始修改設定前，先測試幾個位置：
- 首頁能不能開？
- 一般文章頁能不能開？
- 登入頁與
/wp-admin/能不能進？ - 只有購物車、結帳、會員中心或課程頁出錯嗎？
- 手機網路與另一個網路環境結果是否相同？
如果只有特定功能出錯，優先懷疑該功能的 PHP、外掛、資料庫查詢或第三方 API；如果整站一起失敗，主機、PHP-FPM、資料庫服務、CDN／代理或整體資源更值得優先檢查。
第 1 步：記下錯誤發生的時間、網址與畫面來源
排查 502／503 最有價值的不是「現在又好了」，而是留下可以對照 log 的時間點。至少記錄：
- 發生日期與精確時間。
- 出錯網址。
- 實際狀態碼是 502、503 還是 504。
- 錯誤頁是否帶有 Cloudflare、Nginx、主機商或其他代理服務標記。
- 錯誤前是否剛更新外掛、主題、PHP 或伺服器設定。
- 當時是否正在備份、寄信、匯入或有流量尖峰。
記下時間點後，主機商更容易把錯誤和 PHP、網頁伺服器、資料庫與資源監控紀錄對起來，縮小故障範圍。
第 2 步：查看出錯當下的主機資源與程序狀態
502／503 很常發生在「某個瞬間資源被用完」。要看的通常包括 CPU、RAM、PHP workers／PHP-FPM 程序、I/O、程序數、同時連線與資料庫連線。
重點是看錯誤發生當下，並比對整天平均值與尖峰。即使平均 CPU 只有 20%，直播結束後的 10 分鐘仍可能衝到上限；平常首頁很快，也可能在會員集中登入或結帳時出現動態請求排隊。
如果監控反覆顯示 CPU、RAM 或 PHP 程序碰到方案限制，而且是正常營運流量造成，就有升級資源的依據；若資源很低卻仍出錯，就要繼續查 PHP、外掛、資料庫或代理層。
第 3 步：用 PHP 與網頁伺服器紀錄定位故障
WordPress 的動態頁面要經過 PHP。PHP 程序崩潰、記憶體耗盡、執行過久、PHP-FPM 沒有正常回應，前面的 Nginx、Apache 或反向代理就可能無法取得正常結果。
比較有價值的資料通常是：
- PHP error log。
- Web Server error log。
- 主機控制台的資源限制紀錄。
- 資料庫錯誤與慢查詢。
- 錯誤前最後一次更新或部署紀錄。
WordPress 的除錯功能可以協助開發與測試。正式站應將敏感錯誤資訊保留在受保護的紀錄中，並關閉前台除錯顯示；完成排查後，確認相關安全設定已恢復。
第 4 步：如果剛更新過，先查外掛、主題與 PHP 相容性
如果錯誤剛好從更新外掛、主題、WordPress 核心或 PHP 版本之後開始，「最近變更」就是最重要的線索。
確認既有備份可用後，優先在測試環境或維護時段重現問題，一次只改一個變因，再驗證該項修改是否有效。正式站的會員與付款流程也要一併保護。
完整流程可延伸看課程網站外掛衝突怎麼查？WordPress 10 步安全排錯流程。
第 5 步：503 也可能只是 WordPress 正在維護
WordPress 在更新核心、外掛或主題時會進入維護狀態。若更新中斷或流程沒有正常結束，網站可能持續顯示暫時無法使用的訊息。
如果 503 剛好發生在更新之後，可以先確認 WordPress 是否仍在維護模式。WordPress 的核心機制會檢查根目錄的 .maintenance 檔案及其時間戳記；只有確認更新已完成、維護狀態仍異常殘留時，再由技術人員評估如何處理。
第 6 步：資料庫慢，也可能讓 PHP 最後變成 502／503
資料庫負載過高、某個外掛建立大量查詢、排程同時跑、資料表膨脹或查詢被鎖住，都可能讓 PHP 長時間等資料庫，最後讓上游代理拿不到正常回應。
這時應先查明哪個頁面出錯、哪個查詢變慢，以及是否有固定排程或外掛在同一時間大量讀寫。確認原因後，再評估優化查詢、整理資料、調整排程或增加資料庫資源。
第 7 步：有 CDN／反向代理時，要分清楚錯誤是哪一層產生
網站前面若還有 CDN、網站應用程式防火牆（WAF）或反向代理，訪客看到的 502／503 可能發生在其中任何一層。可能是代理連不到 Origin 原始主機，也可能是 Origin 本身就已經回傳錯誤。
排查的重點是確認：
- Origin 直接測試是否正常。
- DNS 是否指向正確來源。
- 代理層有沒有自己的錯誤紀錄。
- 防火牆／WAF 是否阻擋來源。
- 錯誤是否只在開啟 CDN 後發生。
如果原始主機（Origin）直接測試就出現 503，應優先檢查主機服務與資源；如果原始主機正常，再檢查代理層及 DNS。測試原始主機時要由具權限的管理者操作，並維持必要的安全防護。
第 8 步：固定時段出錯，優先查備份、掃描、寄信與排程
如果網站每天平常都正常，卻固定凌晨、寄電子報後或某個排程時間出現 503，很可能是重工作撞在一起。
- 網站完整備份。
- 惡意程式／資安掃描。
- 圖片壓縮與縮圖重建。
- 大量 Email。
- 商品／會員資料匯入。
- WooCommerce Action Scheduler 或其他背景工作。
把高耗用的背景工作錯開，有機會降低尖峰資源壓力。先從監控紀錄找出耗用資源的工作與時段，再決定要調整排程還是評估主機升級。
502／503 和 WordPress 記憶體不足有什麼關係？
PHP 記憶體不足可能讓某個請求失敗，但 Memory Limit 只是其中一層。主機整體 RAM、PHP workers、CPU、資料庫連線與程序限制都可能造成類似症狀。
如果 log 出現 allowed memory size exhausted，或錯誤明顯和大型外掛／匯入工作有關，可延伸看WordPress 記憶體不足怎麼辦？Memory Limit 調高前先判斷根因。
什麼情況才真的該升級主機？
如果已確認外掛、維護模式、第三方 API 與代理設定正常，而營運流量仍反覆把 CPU、RAM、PHP workers、I/O 或資料庫連線推到方案上限，就有較充分的證據評估升級主機。
- 直播、廣告或 Email 導流時固定出現 503。
- 登入、結帳或後台尖峰固定排隊／逾時。
- 主機監控持續顯示資源限制。
- 正常排程與網站流量已無法在目前方案共存。
- 主機商明確確認目前方案資源已不足。
如果根因是單一外掛、外部 API 或 CDN 規則，應優先修正該項設定或程式；升級 VPS 則留給確實需要更多伺服器資源的情況。若需要比較代管與主機責任，可看代管 VPS 是什麼？自管、代管與一般主機差在哪。
一張表快速判斷 502／503 要先查哪裡
| 現象 | 優先檢查 |
|---|---|
| 剛更新後出錯 | 維護模式、外掛、主題、PHP 相容性 |
| 流量一高就出錯 | CPU、RAM、PHP workers、資料庫 |
| 只在結帳／會員頁出錯 | 相關外掛、查詢、第三方 API |
| 固定時間出錯 | 備份、掃描、Cron、Action Scheduler |
| CDN 錯誤頁 | 先分辨代理層與 Origin |
| 整站持續 502 | Web Server、PHP-FPM、Origin／代理連線 |
| 整站持續 503 | 維護、過載、服務暫停、資源限制 |
修復後，再完成 4 項預防與驗收工作
- 記錄真正根因：寫下出錯層級、實際修正與驗證結果。
- 錯開高耗用工作：把備份、掃描、匯入與大量寄信分散到合適時段。
- 建立監控：至少能對照 uptime、CPU、RAM 與錯誤時間。
- 保留變更紀錄：外掛、PHP、CDN、DNS 與主機調整都留日期。
對正在收款、經營會員或銷售課程的網站，穩定性要從完整流程驗收：重要時刻是否能順利登入、付款並取得課程內容。
看到 502／503，先採取這 6 項安全排查原則
- 減少重複請求：在主機可能過載時，保留錯誤畫面與時間，避免短時間大量重整。
- 一次調整一個變因：在合適環境逐項測試外掛與版本差異，保留可追溯的結果。
- 先保留錯誤線索：記下代理和原始主機回應，再評估是否需要清除快取。
- 按實際需求調整 Memory Limit：核對 PHP 限制與主機 RAM，並追查記憶體持續增加的原因。
- 比對 CDN 與原始主機：由管理者確認兩端的錯誤紀錄與回應狀態。
- 先保留資料再重啟：記錄故障時間、狀態碼、資源與服務日誌，讓重啟後仍有證據可查。
排錯的目標是讓網站恢復服務，同時找到可驗證的根因。修正後再以相近的流量或操作情境測試，確認下一次尖峰能順利登入、付款和交付。
聯絡主機商時，這樣提供資訊會比只說「網站 503」有效很多
如果你使用代管主機或 VPS，送客服工單時可以一次附上以下資訊：
- 錯誤發生的日期與時間，最好精確到分鐘。
- 出錯網址與實際 HTTP 狀態碼。
- 整站都錯，還是只有登入、結帳或特定頁面。
- 當時是否有流量尖峰、備份、掃描、匯入或大量寄信。
- 最近 24 小時是否更新 WordPress、外掛、主題或 PHP。
- 錯誤頁截圖與可辨識的 request ID／Ray ID 等資訊。
- 請對方協助查當時 PHP、Web Server、資料庫與 CPU／RAM／程序限制紀錄。
這些資訊能讓技術人員直接對照伺服器 log，而不是先來回詢問基本資料。對反覆發生、又會影響付款或會員登入的錯誤，建立固定的事故紀錄也會讓後續判斷是否需要升級主機更有依據。
如果錯誤只發生在結帳、會員或後台，代表什麼？
公開首頁正常，但結帳、會員中心或後台出現 502／503，通常代表「能被快取的公開頁」和「必須即時運算的動態頁」負載不同。這時候比起繼續優化首頁圖片，更值得查 PHP workers、資料庫查詢、會員權限、WooCommerce、第三方 API 與相關外掛。
如果只有高峰時段才出現，而低流量時完全正常，更要把同時動態請求與主機資源放在前面檢查；若只有某一個固定功能觸發，則優先查該功能使用的外掛、查詢或外部服務。
若錯誤已影響付款或會員登入，修復後也要重新跑一次完整流程，確認網站不只是「能開」，而是真的能正常完成交易與交付。
WordPress 502／503 常見問題
502／503 發生後，應該如何確認是否已恢復？
短暫過載或維護可能自行恢復。若同類錯誤反覆出現，建議保存錯誤時間、網址與監控紀錄，確認問題是否固定出現在某種功能、流量或排程條件下。
出現 503 時，怎麼判斷是否需要升級主機？
先確認維護模式、外掛、PHP、排程、代理層及第三方服務，再比對錯誤當下的監控與日誌。若正常流量持續觸及方案限制，才有充分理由評估升級。
清快取可以修好 502／503 嗎？
如果根因在快取或代理層，清除對應快取可能有幫助；若原始主機因 PHP、資料庫或資源問題失敗，應先修復原始主機。
WordPress Recovery Mode 能處理 502／503 嗎？
WordPress 復原模式（Recovery Mode）主要協助處理特定 PHP 致命錯誤與相關外掛、主題問題。若 502／503 發生在 Web Server、PHP 服務或代理層，則需從對應服務的日誌與設定確認原因。
網站恢復後還需要找原因嗎？
如果只是極少數偶發事件，可以先觀察；若網站有收入、會員或廣告流量，而且錯誤已出現多次，建議保留時間、網址、log 與資源紀錄，找出規律，避免在下一次尖峰再發生。
結論：確認故障層級，再逐步修復 502／503
502 與 503 都是伺服器端錯誤，但意義不同。先確認真正狀態碼與錯誤頁來源，再依序看主機資源、PHP／Web Server log、最近更新、維護模式、資料庫、CDN／代理與排程，會比一次清快取、停全部外掛、升級主機更有效率。
網站恢復之後，還要記錄根因與修正內容，並在相近的流量或排程條件下重新驗證。登入、付款與課程交付都穩定運作，才算完成這次排查。
參考資料
MDN Web Docs｜502 Bad Gateway｜2026 年查閱
MDN Web Docs｜503 Service Unavailable｜2026 年查閱
WordPress.org Documentation｜Site Health screen｜2026 年查閱
WordPress Developer Resources｜Recovery Mode｜2026 年查閱
Cloudflare｜Error 502 or 504｜2026 年查閱
WordPress Developer Resources｜wp_is_maintenance_mode()｜2026 年查閱
