網站出現 502 Bad Gateway 怎麼辦？5 個常見錯誤碼代表誰壞了，非工程師也看得懂的排查步驟
網站跳出 502 Bad Gateway 的那一刻，多數老闆不是第一個知道的人——是客人截圖傳來的。更難受的是接下來那幾分鐘：你不知道是誰壞了、要等多久、該不該現在就花錢找人修。502 只是五個常見網站錯誤碼中的一個，每一個都指向不同環節壞掉，也對應不同的處理方式。這篇文章用非工程師也看得懂的講法，把 502、403 Forbidden、404 Not Found、503 Service Unavailable 與伺服器當機一次說清楚：各自代表誰的責任、出現當下該做的 3 件事、3 分鐘內判斷是自己還是主機商的問題，以及怎麼讓系統比客人更早通知你。
502 Bad Gateway 到底是什麼意思，壞的通常不是你的網路
先把最常見的誤會拆掉：看到 502，第一個該被排除的嫌疑犯就是你自己的網路和瀏覽器。這串訊息不是瀏覽器發明的，是伺服器那一端主動回給你的答案。既然對方有能力回話，就代表你的網路通得到它——真正卡住的是它背後的那一段。
我在諮詢時常遇到老闆花二十分鐘重開路由器、清快取、換 Wi-Fi，最後才發現全世界都連不上。方向從一開始就錯了。
閘道與代理伺服器：502 說的是中間那一層轉不動
依 HTTP 標準規範（RFC 9110），502 Bad Gateway 的定義是「伺服器作為閘道或代理角色時，從上游伺服器收到了無效的回應」。
把它翻成開店的語言：你的網站前面通常站著一個「櫃檯」，可能是 CDN、負載平衡器、Nginx 反向代理，或是虛擬主機商的前端伺服器。訪客的請求不會直接打進放你網站程式的那台機器，而是先到櫃檯，再由櫃檯轉進廚房。502 的意思是——櫃檯接到單、轉進去了，但廚房回了一個它看不懂的東西，或者根本沒有正常回覆。
所以 502 有兩個明確含意。第一，中間那層是活的，它還有力氣回你錯誤訊息。第二，壞的是後面那段，通常是網站主機、應用程式、資料庫，或是主機與櫃檯之間的連線。這也是為什麼重新整理有時候會突然好——那代表後端只是短暫沒回應，不是徹底死掉。
502 常見的顯示變體：看畫面就先分出責任歸屬
502 沒有統一長相。畫面上出現的字樣，其實已經洩漏了是誰在回答你，這對釐清責任很有用。
| 顯示訊息 | 常見出現位置 | 白話解讀 |
|---|---|---|
| 502 Bad Gateway（純文字白底頁） | 主機商前端伺服器、Nginx | 網站主機或程式沒有正常回應，多半是主機端問題 |
| 502 Bad Gateway nginx/1.xx.x | 自架主機、VPS、雲端主機 | Nginx 轉給後端服務時被拒絕，常見於程式當掉或未啟動 |
| Error 502 Bad gateway，畫面帶 Cloudflare 標誌 | 有掛 Cloudflare 的網站 | 依 Cloudflare 官方說明，帶品牌的錯誤頁代表來源主機（origin）回應了標準 502/504，問題出在主機端 |
| 502 Proxy Error | 企業內網、Apache 反向代理 | 代理伺服器轉送失敗，常見於公司內部系統 |
| 空白頁，只有 502 三個數字，沒有 Cloudflare 標誌 | 有掛 Cloudflare 的網站 | 沒有品牌訊息時，代表錯誤源自 Cloudflare 自身，該往 CDN 端查 |
Cloudflare 的支援文件把這件事講得很直白：帶有 Cloudflare 品牌的錯誤頁，代表來源主機（origin server）回了一個標準的 502 或 504，問題多半出在主機端；反過來，畫面裡完全沒提到 cloudflare 的空白錯誤頁，才代表問題出在 Cloudflare 自己身上，需要往 CDN 端查。這一條規則，非工程師照著看畫面就能用。
502、500 與 504 差在哪，三個都是伺服器端但責任不同
這三個數字常被混為一談，實際上指向的環節不一樣。500 Internal Server Error 是「程式自己出錯了」，通常是網站程式碼、外掛或資料庫查詢炸掉，錯誤發生在後端內部。502 是「中間層轉進去，拿到無效回應」。504 Gateway Timeout 則是「中間層轉進去，等到最後完全沒回應」——依 MDN 的說明，504 代表代理伺服器沒有收到任何 HTTP 回應。
判斷順序上，500 幾乎可以確定要找會改程式的人；502 和 504 要先確認主機資源是否吃緊，再看是不是程式沒啟動或回應太慢。我的經驗是，同一個網站短時間內 502 與 504 交替出現，八成是主機資源不足，而不是被攻擊。
502 比 504 更常自己好轉，背後有一個機制原因：多數雲端架構的負載平衡器會把回應異常的後端節點暫時移出名單、幾秒後再嘗試連回去，這個自動重試常常在你重新整理頁面之前就完成了，訊息因此消失。504 則不同——那代表連線確實建立了，只是後端等到天荒地老都沒有任何回應，通常表示程式真的卡住，需要人工重啟，不會自己好。
延伸閱讀：「網站弱點掃描是什麼？2026 最新費用、工具與 5 步驟自查教學一次搞懂」處理完眼前的 502 之後，這篇能幫你確認整站還有沒有其他沒被發現的洞。
5 個網站常見錯誤碼，各自代表誰壞了
錯誤碼真正的價值不在於「知道它叫什麼」，而在於它幫你省下打錯電話的時間。找主機商處理一個其實是自己設定錯的問題，來回三小時；反過來，自己埋頭改設定卻是機房線路出事，那三小時直接變成營業損失。
下面這張表是我給客戶的判斷起點。
一張表看完 502、403、404、503 與伺服器當機
| 錯誤碼 | 白話翻譯 | 常見成因 | 該找誰處理 | 網站擁有者能做的事 |
|---|---|---|---|---|
| 502 Bad Gateway | 櫃檯轉進去，廚房回了無效的東西 | 主機負載過高、程式服務停止、後端連線中斷 | 主機商為主，程式問題找工程師 | 確認範圍、查狀態頁、記錄發生時間 |
| 403 Forbidden | 門是開的，但你被擋在外面 | 檔案權限設定錯誤、防火牆規則、IP 被封鎖 | 網站管理者或工程師 | 回想近期是否改過權限或裝過安全外掛 |
| 404 Not Found | 伺服器好好的，只是這個網址不存在 | 網址打錯、頁面刪除、網址結構變更後未做轉址 | 網站管理者自行處理 | 檢查連結、為舊網址設定 301 轉址 |
| 503 Service Unavailable | 有人接電話，但說現在不能服務 | 主機維護中、流量超載、資源用罄 | 主機商，或等待維護結束 | 確認是否為公告中的維護時段 |
| 伺服器當機 | 連電話都沒人接 | 機器斷電、機房事故、網路中斷、遭受攻擊 | 主機商 | 立即聯絡主機商，並對外公告 |
看得出來規律了嗎？數字開頭是 4 的，責任多半在你這邊；開頭是 5 的，多半在伺服器那邊。這一條粗略但實用。
4xx 與 5xx 的分界：一個是請求有問題，一個是伺服器有問題
4xx 系列在標準裡叫「用戶端錯誤」，意思是伺服器聽懂了，但認為這個請求本身有問題——網址不存在（404）、沒有權限（403）、需要登入（401）。這類問題通常改得動，因為問題出在你的網站設定或內容管理。
5xx 系列叫「伺服器錯誤」，代表請求沒問題，是伺服器端無法完成。502、503、504 都在這一類。這類問題多數要主機商介入，你自己重開瀏覽器一百次也不會變好。
實務上最容易誤判的是 403。很多老闆看到 403 就打電話給主機商，但真正原因常常是自己前一天裝了一個安全外掛、或改了資料夾權限。反過來說，403 若是整站突然全面出現，那通常是主機端的防火牆規則被觸發，這時候才輪到主機商。
503 與伺服器當機的差別：一個接了電話說現在不行，一個根本沒人接
503 Service Unavailable 是有回應的錯誤。伺服器活著，程式也在跑，只是資源不足或正在維護，主動告訴訪客「現在不行，晚點再來」。很多內容管理系統在更新時會自動進入維護模式並回 503，這是設計好的行為，不算故障。
伺服器當機則沒有錯誤碼可看。瀏覽器轉圈圈到最後顯示「無法連上此網站」，因為根本沒有東西回應。這兩者的處理急迫性差很多：503 常常十分鐘內自己好，當機則需要立即聯絡主機商。
判斷方法很簡單——畫面上有沒有一組數字。有數字，代表對方還活著；連數字都沒有，才是真的斷線。
502 出現時，網站擁有者該做的 3 件事
慌張的老闆有兩種典型反應：一種是立刻打電話給主機商，把對方當成救火隊；另一種是自己開始亂改設定，改到最後連原本沒壞的地方也壞了。兩種都會讓事情變久。
有一套順序，會讓你在三分鐘內知道自己站在哪個位置。
STEP 1–4：從確認範圍到留下紀錄
STEP 1：確認範圍
目的是判斷這是「只有你看到」還是「全部人都看到」。用手機關掉 Wi-Fi、改用行動網路開一次網站；再請一位不同地區的朋友或同事開一次。輸出物是一句話的判斷：問題出在我這台裝置，或問題出在伺服器。這一步花不到兩分鐘，卻決定了後面所有動作的方向。
STEP 2：查看官方資訊
確認主機商是否已經知道這件事。多數主機商與雲端服務商都有獨立的狀態頁（status page），會即時公告機房事故與維護時段；主機後台的通知欄與註冊信箱的信件也要一起看。輸出物是：有沒有已知的維護或事故公告。若公告已存在，你要做的只剩下等待與對客戶說明，不必再排查。
STEP 3：判斷是否需要立即聯絡主機商
依 STEP 1–2 的結果與錯誤持續的時間決定。全站不通、持續超過十分鐘、狀態頁又沒有公告——這種組合就該主動聯絡。聯絡時同步提供錯誤截圖、精確發生時間（含時區）、受影響的網址，以及是否已確認多個網路環境皆無法連線。輸出物是聯絡與否的決定，以及一份能讓對方直接開始查的資訊包。
STEP 4：記錄與後續
事件結束後，用五分鐘寫下：發生時間、持續多久、當時的畫面、最後怎麼解決、主機商給的原因。輸出物是一則簡單的事件紀錄。這件事九成的人不會做，但它會在第二次發生時替你省下最多時間——因為你會發現，很多網站的 502 是重複出現在同一個情境裡的。
聯絡主機商時要提供什麼，決定你多快被處理
客服信箱裡最沒有效率的一句話是「我的網站打不開，請幫我看一下」。對方要回問三次才能開始查，一來一回半天就過了。
Cloudflare 在自家文件裡明確要求回報時附上發生時間與時區、受影響的網址，以及 你的網域/cdn-cgi/trace 這個診斷網址的輸出內容。這個要求背後的邏輯適用於所有主機商：他們需要能定位到那一筆請求的紀錄。
實務上建議準備四樣東西：錯誤畫面的完整截圖（含網址列）、發生的精確時間、你已經做過哪些測試、影響範圍是全站還是特定頁面。四樣齊全的工單，處理速度通常比只有一句抱怨的快上好幾倍。
什麼時候該等，什麼時候該升級
短暫的 502 很常見。Cloudflare 官方說明提到，當某個資料中心流量突然增加時，系統會自動把流量導到另一個資料中心，這個切換過程通常只需幾秒鐘，但期間部分訪客可能短暫遇到延遲或 502。這類狀況重新整理就會好，不需要做任何事。
我給客戶的判斷線是十分鐘。持續不到十分鐘、且能自行恢復的，先記錄不處理；超過十分鐘仍全站不通，或一週內重複發生三次以上，那就不是偶發，該進工單了。
本文的判斷流程屬於一般性建議。實際處理仍須依網站架構、主機商合約條款與技術支援範圍而定，複雜或持續性的問題建議直接洽詢主機商或專業工程師協助，本文不對特定情境的解決結果或恢復時間做出承諾。
怎麼判斷 502 Bad Gateway 是自己的問題還是主機商的問題
這是所有問題裡最值錢的一個。判斷對了，該找誰、該花多少錢、該不該緊張，全部有答案；判斷錯了，你會在錯的方向上燒掉整個下午。
好消息是，這個判斷不需要技術背景，只需要順序。
3 分鐘測試法：從最容易操作的動作排到需要外部工具
順序的設計原則是：先做你手邊就能做的，再動用外部工具。
第一步換裝置。用手機開同一個網址，看是否一樣打不開。電腦有問題、手機正常，那多半是你這台電腦的快取或擴充功能。
第二步換網路。手機關掉 Wi-Fi 改用行動網路再試一次。Wi-Fi 不行、行動網路可以，問題出在你的網路環境或 DNS 設定，不是網站。
第三步換瀏覽器。Chrome 打不開，換 Safari 或 Edge 試。只有單一瀏覽器有問題，通常是快取或某個擴充功能在作怪。
第四步用外部工具。前三步都指向「不是我的問題」時，用線上網站狀態檢測服務（例如 isitdownrightnow、downforeveryoneorjustme 這類服務）從第三方位置確認網站是否全球都連不上。這一步是最關鍵的證據，因為它把「我覺得壞了」變成「客觀上壞了」。
三分鐘做完這四步，你就能拿著結論去找對的人。
3 分鐘自我排查清單
打電話給主機商之前，下列項目建議逐一確認：
- 換一台裝置（手機／電腦）測試是否同樣打不開
- 換一個網路環境（行動網路 vs Wi-Fi）測試
- 換一個瀏覽器測試
- 用線上狀態檢測工具確認是否全球都連不上
- 查看主機商狀態頁或後台是否有維護公告
- 確認近期是否更改過網域 DNS 設定
- 確認 SSL 憑證是否即將到期或剛更新過
- 回想過去 48 小時內是否安裝、更新過任何外掛或主題
最後兩項最常被忽略，卻是自架站與 WordPress 站最高機率的肇因。網站不會無緣無故壞掉，多數時候前面有一個動作。
四種最常見的成因：流量突增、DDoS、DNS 變更、SSL 憑證
流量突增是電商最常見的一種。檔期開賣、電子報寄出、社群貼文爆紅，同一分鐘湧入的人數超過主機能負荷的量，後端來不及回應，前面的櫃檯只好回 502。這種狀況有明確的時間相關性——你會發現它通常發生在你做行銷動作之後。
DDoS 攻擊造成的服務中斷，規模已經跟幾年前不同。Cloudflare 的威脅報告指出，2025 年第一季單季就緩解了 2,050 萬次 DDoS 攻擊，年增 358%；到了 2026 年上半年，超過 1 Tbps 的網路層攻擊累計達 935 次，Q1 到 Q2 之間成長 519%。台灣這邊，數位發展部資安署統計 2025 年公務機關資安通報共 726 件，其中阻斷服務類占 4.96%、設備問題占 15.43%。這些數字對一人電商的意義不是「你會被鎖定」，而是攻擊成本已經低到攻擊方不需要挑對象。
DNS 變更是自己造成的最常見原因。換主機、改網域設定、調整 MX 紀錄，設定生效需要時間，期間會出現部分人看得到、部分人看不到的詭異狀態。
SSL 憑證問題則常被誤判成網站掛掉。憑證過期或自動續期失敗時，訪客看到的畫面可能是安全性警告，也可能因為前端代理與後端之間的加密連線建立失敗而變成 502。免費憑證多半是自動續期，一旦自動化流程斷掉，通常沒有人會發現，直到憑證到期那一天。
延伸閱讀：「Let's Encrypt 免費 SSL 憑證是什麼？中小企業老闆該不該用？完整申請與續期指南」憑證過期造成的連線異常，畫面看起來也像網站掛了，那篇整理了自動續期斷掉時的檢查方式。
案例：週年慶檔期消失的 40 分鐘
背景。 一位經營保養品電商的客戶，主力通路是自架商城，平時單日流量穩定，全年最重要的檔期是週年慶。那次活動前，她做了完整的預熱：電子報、社群倒數、KOL 開箱同步上線，開賣時間訂在晚上八點。
問題。 八點整流量湧入，主機端來不及回應，前台開始間歇出現 502 Bad Gateway。她自己完全不知情——後台是能進的，她那台電腦的頁面也還是快取版本，看起來一切正常。直到第一位下單失敗的顧客私訊反映「結帳一直跳錯誤」，她才去換手機測試，確認網站真的掛了。從第一筆錯誤到她知道，中間過了大約 40 分鐘。
那 40 分鐘正好是流量最高峰。損失的不只是當下的訂單，還有已經花在預熱上的行銷成本——把人帶到門口，門卻是關的。
解法。 當下能做的其實有限：聯絡主機商臨時升級資源，同時在社群公告延後半小時開賣，把還在等的客人留住。真正的修正在事後——導入基礎的網站正常運行監控，設定每分鐘從外部檢測一次首頁與結帳頁，異常時直接推播到手機。同時把檔期流量預估告訴主機商，提前調整方案。
後記。 隔年同一個檔期，開賣後十二分鐘出現一次短暫的 502。這次她在第三分鐘就收到通知，主機商在十分鐘內完成資源調度，客服完全沒有收到抱怨。同樣的錯誤發生了兩次，差別只在於誰先知道。
與其等客人告訴你網站掛了
前面講的都是「壞掉之後怎麼辦」。這一段要講的是另一件事：為什麼你會是最後一個知道的人。
這個問題比 502 本身更值得處理。
502 Bad Gateway 是一種事後才知道的錯誤碼
網站掛掉不會發簡訊給你。它沒有警報聲、沒有推播、後台不會跳紅字——因為後台跟前台常常走不同的路徑，前台已經回 502 了，你的管理介面還好好的。
更麻煩的是快取。你自己的瀏覽器可能存著幾分鐘前的正常版本，你重新整理看到的是舊畫面，主觀上完全感覺不到異常。這就是為什麼多數老闆是靠客人的截圖才知道出事。
而客人願意告訴你，其實已經是好結果。多數人的反應是關掉分頁走人，不會有人特地通知一家連不上的網站。你真正流失的訂單數，永遠比你聽到的抱怨多。
主動監控實際能做到的事
網站監控的概念不複雜：從外部固定間隔打你的網址，回應碼不是 200 就通知你。它做不到修好網站，只做一件事——把「你知道的時間」提前。
差別有多大？從 40 分鐘變成 1 分鐘，中間差的是三十幾分鐘的營業額，以及你能不能在客人抱怨之前先公告。這對品牌信任的影響，比實際損失的訂單更長遠。
不需要昂貴的維運方案就能開始。UptimeRobot、Better Stack（原 Better Uptime）這類服務都有入門方案，可設定每 5 分鐘（依方案而定）從外部檢測一次首頁與結帳頁，異常時直接推播到 LINE 或 Email，設定時間通常不到半小時，不需要工程背景。要留意的是，這類服務的免費方案多半只給個人非商業用途使用（UptimeRobot 官方條款已明訂免費方案禁止商業使用），電商網站屬於商業用途，建議直接選入門付費方案，費用通常每月數美元起，換算下來遠低於一次沒被通知到的訂單損失。真正該注意的是「檢測點必須在網站外部」——自己開瀏覽器看，看到的可能只是快取版本。
順帶提一件 SEO 上的事。Google Search Central 的官方文件寫得很清楚：當網站持續回應 5xx 錯誤，Googlebot 會降低抓取頻率；短期中斷（約兩天內）恢復後抓取會自動回升，但若「無法提供服務」的狀態持續超過幾天，Google 可能永久放慢或停止抓取，甚至把該網址從索引中移除。而且這個降速影響的是整個主機名稱，不只出錯的那幾頁。
換句話說，一次半小時的 502 對排名幾乎沒有影響；真正該擔心的是重複發生、長時間不修的狀況。
我的觀點：把「被通知」換成「先知道」
我看過太多老闆把網站當成家電——會動就不管，壞了再叫人來修。這個心態在實體世界成立，因為冰箱壞了你第一時間就會知道。網站不一樣，它壞掉的時候是安靜的。
讓我困惑的是，同樣一群老闆，倉庫少一箱貨會盤點、廣告花費超支會設上限、客服訊息未讀會焦慮，卻對「網站現在是不是活著」這件事完全沒有機制。可能因為它平常太可靠了，一年壞不到兩次，久了就忘記它會壞。
我不認為每個中小企業都需要昂貴的維運方案。但至少要知道自己現在的狀態是「有機制」還是「靠運氣」——這兩件事的成本差很多，風險差更多。
延伸閱讀：「網站被DDoS攻擊了嗎？中小企業3步驟自救教學」當網站連錯誤碼都不出現、整站完全無回應時，這篇說明了攻擊情境下的判斷與應變順序。
常見問題（FAQ）
網站總有壞的一天，但最後一個知道的人不該是老闆
502 Bad Gateway 不是災難，它只是一個訊號——中間那層轉不進去，後面出事了。真正決定損失大小的從來不是這串英文，而是從錯誤發生到你知道之間隔了多久。四十分鐘和一分鐘，技術難度差不多，成本差非常多。
這篇文章講的五個錯誤碼、三件該做的事、三分鐘判斷法，本質上都在做同一件事：把「不知道該找誰」變成「知道該找誰」。502 找主機商、403 先查自己的權限設定、404 自己補轉址、503 確認維護時段、完全無回應直接聯絡機房。判斷對了，多數狀況你不需要花錢，只需要花十分鐘。
我不認為中小企業老闆該去學伺服器維運。但網站是生意的門面，門有沒有開著，總該有人告訴你。與其等客人截圖傳 LINE，不如讓系統先講。
現在就加入老闆文學院電子報，訂閱就送價值千元 AI 工具箱——別等下一次網站掛掉，才想到自己什麼保護都沒有。
如果你覺得這篇對你有幫助，歡迎訂閱我的電子報。我每雙週寄一封到你信箱，談的都是這種會真正影響你決策的東西。👉 訂閱連結在這
也歡迎你轉給身邊需要的朋友。也許只是你的舉手之勞，就改變了另一個人的思維和習慣。
最後留一個問題給你：你的網站上次掛掉是什麼時候？你是怎麼知道的？
參考資料
- MDN Web Docs（Mozilla），「502 Bad Gateway」
- Cloudflare Support Docs，「Error 502 or 504」
- MDN Web Docs（Mozilla），「HTTP response status codes」
- IETF，「RFC 9110: HTTP Semantics」，2022
- Cloudflare Blog，「Cloudflare's 2025 Q1 DDoS Threat Report」，2025
- Cloudflare Blog，「DDoS Threat Report H1 2026」，2026
- 數位發展部資安署，「114 年度國家資通安全情勢報告」，2026 年 3 月
- Google Search Central，「HTTP Status Codes, Network and DNS Errors, and Google Search」