如果你搜尋的是 503 Bad Gateway，先釐清一件事：HTTP 標準裡，503 的正式名稱是 Service Unavailable，也就是「服務暫時無法使用」；Bad Gateway 則是 502。這兩個錯誤都可能出現在 WordPress、主機、反向代理或 CDN 架構裡，但代表的問題並不完全相同。
最容易浪費時間的做法，是看到 503 就立刻停用全部外掛、清快取、改 PHP 記憶體、重啟服務，全部一起試。網站偶爾可能因此恢復，但你也失去了判斷真正原因的線索。
比較有效率的方法是：先確認錯誤碼與發生範圍，再找出是哪一層回傳 503，最後才針對那一層處理。
503 Bad Gateway 和 502 Bad Gateway 到底差在哪裡？
根據 HTTP Semantics 與 MDN 對狀態碼的定義：
| 狀態碼 | 正式名稱 | 代表意思 | 常見方向 |
|---|---|---|---|
| 502 | Bad Gateway | 閘道器或代理伺服器從上游服務收到無效回應 | 代理層、Web Server、PHP、上游服務 |
| 503 | Service Unavailable | 伺服器目前暫時無法處理請求 | 維護、過載、資源耗盡、服務暫時不可用 |
| 504 | Gateway Timeout | 閘道器等待上游服務太久，最後逾時 | 慢查詢、PHP 執行過久、上游回應過慢 |
所以，「503 Bad Gateway」比較像搜尋者常用的混合說法，而不是正式 HTTP 狀態名稱。實際排錯時，第一步一定要看清楚瀏覽器、主機或 CDN 真正回傳的是 502、503 還是 504。
如果你希望先看三種錯誤放在同一條架構裡比較，可以先讀WordPress 出現 502／503 錯誤怎麼辦？從主機、PHP、外掛到 CDN 逐步排查。
不一定。
503 本來就是用來表示暫時性的服務不可用。例如網站正在更新、伺服器暫時過載、PHP 工作程序被占滿，或某個前端代理層正在限制請求，都可能回傳 503。
MDN 也指出，伺服器在維護或過載時可能使用 503；如果能預估恢復時間，可以搭配 Retry-After 回應標頭，告訴用戶端多久後再試。
對 WordPress 網站經營者來說，真正要分辨的是：
- 它只出現幾秒鐘，還是持續幾分鐘以上？
- 整站都錯，還是只有後台、結帳、搜尋或特定頁面？
- 錯誤發生前是否剛更新 WordPress、外掛、佈景主題或 PHP？
- 是否只在流量高峰、備份、掃描或排程執行時發生？
- 錯誤頁是主機產生的、Cloudflare 產生的，還是 WordPress 維護模式？
這幾個線索，比先猜「是不是主機太爛」更有用。
WordPress 出現 503，先用這個順序排查
第 1 步：先記下錯誤發生時間、網址與範圍
先不要急著改設定。把錯誤發生的時間、網址、畫面文字記下來，接著測試幾個不同位置：
- 首頁是否正常？
- 一般文章頁是否正常？
/wp-admin/是否正常？- 登入後才會出現嗎？
- 只有 WooCommerce 結帳、會員課程、搜尋或匯出頁面出錯嗎？
如果只有單一頁面出錯，問題通常更接近該頁使用的功能、查詢或外掛；如果整站一起 503，才更應該優先看主機、PHP、維護模式或代理層。
這一步的目的不是修復，而是先縮小問題範圍。排錯最怕一開始就同時改五個地方，最後網站恢復了，卻不知道是哪一個動作真的有效。
第 2 步：確認是不是 WordPress 維護模式
WordPress 在更新核心、外掛或佈景主題時，會進入維護模式。官方程式本身會在這種狀態送出 HTTP 503，並顯示「Briefly unavailable for scheduled maintenance」之類的維護訊息。
WordPress 會在網站根目錄建立 .maintenance 檔案。官方文件指出，如果更新結束後這個檔案沒有正確移除，網站可能持續顯示維護訊息。
如果你剛好是在更新中斷後發生問題，可以先確認：
- 畫面是不是 WordPress 的維護提示？
- 網站根目錄是否存在
.maintenance？ - 更新是否真的已經完成，而不是仍在執行？
若確認只是殘留的維護檔案，再依 WordPress 官方方式停用維護模式或移除殘留檔案。不要看到任何 503 都直接刪檔，因為 503 還有很多其他來源。
第 3 步：看主機資源是不是在錯誤當下撞到限制
503 很常和「資源暫時用完」有關。需要看的不只有磁碟容量，而是：
- CPU 使用率。
- 記憶體。
- PHP workers／PHP-FPM 工作程序。
- 程序數與同時連線。
- 資料庫連線。
- 主機方案本身的資源限制。
重點是看錯誤發生當下。例如平均 CPU 只有 20%，不代表某一分鐘沒有衝到 100%；平常網站很快，也不代表直播招生、會員登入、WooCommerce 結帳或機器人流量同時進來時不會把動態請求塞滿。
如果你不確定規格要怎麼看，可延伸閱讀課程網站主機規格怎麼看？CPU、記憶體、資料庫與尖峰流量 9 項判斷。
第 4 步：檢查 PHP 與伺服器錯誤紀錄，不要只靠猜
WordPress 的動態頁面需要 PHP 執行。PHP 工作程序不足、執行時間太久、記憶體耗盡、服務異常或程式發生錯誤，都可能讓網站前面的 Web Server 或代理層無法正常取得結果。
這時候最有價值的資料，通常是：
- 主機控制台的錯誤紀錄。
- PHP error log。
- Web Server 錯誤紀錄。
- 錯誤發生前後的資源監控。
- 最近更新、安裝或修改過的項目。
如果你使用代管主機，與其只跟客服說「網站 503」，更有效的問法是把發生時間、網址、是否整站、最近做過什麼變更一起提供，請對方對照 PHP、Web Server 與資源紀錄。
WordPress 官方也提供 WP_DEBUG 與 WP_DEBUG_LOG 等除錯功能，不過官方明確提醒，這類除錯設定主要適合開發或測試環境，不建議直接把除錯訊息顯示在正式網站前台。
第 5 步：如果錯誤發生在更新後，再查外掛與佈景主題
如果 503 剛好出現在「更新某個外掛後」、「切換 PHP 版本後」或「新增某段程式碼後」，最近變更就是很重要的線索。
這時候不要把所有外掛同時停掉就算完成。正確目標是找出：
- 錯誤能不能穩定重現。
- 停用哪一個變更後錯誤消失。
- 重新啟用後是否再次出現。
- 問題是外掛本身、版本相容性，還是它把主機資源推到上限。
課程網站、會員站或 WooCommerce 網站通常不適合在正式站隨意大量停用外掛。需要更完整流程時，可以看課程網站外掛衝突怎麼查？WordPress 10 步安全排錯流程。
第 6 步：有 Cloudflare 或 CDN 時，先分清楚錯誤來自哪一層
很多 WordPress 網站前面還有 CDN、WAF 或反向代理，所以訪客看到的錯誤頁，不一定是 WordPress 本身產生的。
Cloudflare 目前的官方 503 說明建議，先判斷錯誤是來自原始主機（Origin）還是 Cloudflare。若 503 回應內容沒有 Cloudflare 或 cloudflare-nginx 的標記，問題較可能來自原始主機；如果錯誤頁明顯帶有 Cloudflare 資訊，才需要進一步檢查 Cloudflare 端。
這個概念很重要：Origin 已經 503 時，一直清 CDN 快取通常不會解決主機本身的 PHP 或資源問題；Origin 正常而代理層失敗時，才應把重點放回 CDN、WAF、DNS 或代理規則。
第 7 步：如果 503 只在特定時間發生，檢查排程與流量尖峰
有些網站平常完全正常，卻每天固定時間 503。這種情況就要特別看排程。
常見會在短時間增加負載的工作包括：
- 網站備份。
- 惡意程式或安全掃描。
- 大量圖片處理。
- 匯入商品或會員資料。
- 資料庫最佳化。
- 寄送大量通知。
- WooCommerce、會員系統或其他外掛的背景工作。
如果幾個重工作剛好在同一時間執行，即使平常主機資源足夠，也可能在那個時間點把 PHP、CPU、記憶體或資料庫連線推到上限。
為什麼不建議看到 503 就先「升級主機」？
因為升級資源只能解決「資源真的不夠」這一類問題。
如果根本原因是：
- 外掛進入錯誤迴圈。
- 某個 API 長時間卡住。
- 更新後相容性出問題。
- CDN／WAF 規則異常。
- 資料庫查詢失控。
- 某個排程每隔一段時間大量消耗資源。
換到更大的主機，有時只是讓問題晚一點發生。
反過來說，如果你已經排除程式錯誤，而且正常營運流量就持續把 CPU、記憶體、PHP workers 或連線數推到方案上限，那麼升級主機或改用更適合的架構才有意義。
503 一直重複出現，真正要留下的是「證據」
偶發一次的 503 可能很快恢復，但對正在招生、收款、會員登入或提供線上課程的網站來說，反覆 503 不能只用「現在可以開了」當結案。
至少要留下：
- 發生日期與時間。
- 錯誤網址。
- 實際 HTTP 狀態碼。
- 錯誤頁是哪一層產生。
- 當時 CPU、記憶體、PHP workers 與資料庫狀況。
- 最近的更新或設定變更。
- 同時間執行的排程工作。
只要累積兩三次紀錄，通常就比較容易看出規律：是每次更新後發生、每天備份時發生、流量高峰發生，還是只有某個功能會觸發。
如果你只是網站訪客，看到 503 要怎麼辦？
如果你不是站長，只是進入某個網站時看到 503，通常不需要改瀏覽器設定或重裝任何東西。
因為 503 主要是伺服器端狀態。你可以：
- 稍後再試。
- 不要短時間大量重整。
- 若是付款、報名或重要操作，先確認是否已成功送出，再決定要不要重試。
- 長時間無法使用時，聯絡網站管理者。
若只有你看不到、其他人完全正常，才需要進一步排查本機網路、DNS、瀏覽器快取或特定防火牆問題。
從症狀反推：503 最可能卡在哪一層？
503 的麻煩在於，同一個錯誤碼可以由不同層產生。與其一看到 503 就照網路教學把所有方法做一遍，不如先看「什麼情境會觸發」。
| 你看到的現象 | 優先懷疑方向 | 先查什麼 |
|---|---|---|
| 剛更新 WordPress、外掛或佈景主題後出現 | 維護模式、更新失敗、版本相容性 | 維護訊息、最近更新項目、錯誤紀錄 |
| 平常正常，流量一高就 503 | CPU、記憶體、PHP workers、連線數 | 錯誤當下的主機資源與 PHP 狀態 |
| 只有後台或特定功能出錯 | 外掛、慢查詢、特定 PHP 程式 | 該頁使用的功能、PHP／伺服器紀錄 |
| 固定每天某個時間出現 | 備份、掃描、排程、批次工作 | WP-Cron、主機排程與背景工作時間 |
| 錯誤頁帶有 Cloudflare 資訊 | CDN／代理層或 Origin 連線 | 先分辨 Cloudflare 與原始主機哪邊回傳錯誤 |
| 主機監控正常，但網站仍反覆 503 | 應用程式、PHP、資料庫、代理設定 | 錯誤紀錄與最近變更，不只看平均資源圖 |
這張表不是用來直接判定根因，而是幫你決定「下一個要收集什麼證據」。真正的修復仍要以紀錄與可重現結果為準。
503 修好之後，還要做 4 件事避免再次發生
網站重新打得開，不代表問題已經結束。如果 503 曾經影響付款、會員登入、課程觀看或廣告流量，最好再做一次後續整理。
- 記錄真正根因。是某個外掛、主機資源、PHP workers、維護模式，還是 CDN？不要只寫「重開後好了」。
- 把重工作錯開。備份、掃描、資料庫整理與大量寄信若同時執行，很容易製造不必要的尖峰。
- 建立監控。至少能看到網站可用性、CPU、記憶體與錯誤時間。下次再發生時，才不會只靠回憶猜原因。
- 重新評估主機餘裕。如果正常營運已經長期接近資源上限，就要提早規劃升級，而不是等招生、促銷或流量尖峰時才處理。
對一般形象網站來說，短暫 503 可能只是一次干擾；但對線上課程、會員、WooCommerce 或正在投放廣告的網站，503 發生的時間點可能直接影響報名、付款與使用體驗。穩定性不是「網站能不能打開」這麼簡單，而是重要時刻能不能正常完成交易與交付。
503 Bad Gateway 常見問題
503 Bad Gateway 是正確的錯誤名稱嗎？
按照 HTTP 標準，503 的正式名稱是 Service Unavailable；Bad Gateway 是 502。如果你在錯誤頁或搜尋結果看到「503 Bad Gateway」，排查前最好先確認真正的 HTTP 狀態碼。
503 是主機問題還是 WordPress 問題？
兩邊都有可能。503 可以由 WordPress 維護模式、PHP、Web Server、主機資源、反向代理或 CDN 回傳。先判斷是哪一層回應，再處理，比直接認定是外掛或主機更準確。
清快取可以修好 503 嗎？
只有在快取或 CDN 本身與問題有關時才可能有效。如果原始主機因 PHP 工作程序耗盡、資源不足或程式錯誤而 503，單純清快取不會處理根本原因。
503 會影響 SEO 嗎？
短暫的 503 本來就是用來表示暫時不可用，搜尋引擎能理解這種狀態；真正需要擔心的是網站長時間或頻繁回傳 503，讓使用者與搜尋引擎反覆無法取得正常頁面。因此修復後還要追查是否會再次發生。
503 一定要換 VPS 才能解決嗎？
不一定。只有確認目前正常流量與功能確實長期超過主機資源能力時，升級規格才是合理解法。如果根本原因是外掛、排程、程式錯誤或代理設定，換 VPS 並不等於問題自動消失。
結論：看到 503，先找是哪一層說「現在忙不過來」
如果你是因為搜尋「503 Bad Gateway」來到這裡，先記住最重要的差別：502 才是 Bad Gateway，503 是 Service Unavailable。
接著不要急著亂改設定。先確認錯誤碼、發生範圍與最近變更，再依序看維護模式、主機資源、PHP／伺服器紀錄、外掛與佈景主題、CDN／代理層，以及排程與流量尖峰。
真正有效的排錯，不是試最多方法，而是每一步都讓你更接近根本原因。網站恢復只是第一步；知道它為什麼出錯、怎麼避免再次發生，才算真的處理完成。
參考資料
- RFC 9110 — HTTP Semantics, 15.6.3 502 Bad Gateway、15.6.4 503 Service Unavailable
- MDN Web Docs — 503 Service Unavailable
- Cloudflare Support — Error 503: service temporarily unavailable
- WordPress Developer Resources — Common WordPress errors
- WordPress Developer Resources — wp_maintenance()、wp_is_maintenance_mode()