AWS國際帳號註冊 AWS負載均衡設定中常見的502與504錯誤如何解決

第一章：為什麼會看到 502、504？先把概念釐清

AWS國際帳號註冊 在 AWS 做負載均衡時，502 與 504 是最常見、也最容易被「籠統怪到後端」的錯誤碼。要解決問題，第一步不是急著改程式，而是先理解它們在負載均衡鏈路中各自代表什麼含義。當你知道它是「哪一段」出了問題，你的排查就會快很多，也不會一直在錯的方向上浪費時間。

簡單來說：

• 502（Bad Gateway）：負載均衡器在嘗試把請求轉發到上游（通常是目標群組/後端）時，收到無法理解或無法建立的回應。它偏向「連線或回應本身就有問題」。
• 504（Gateway Timeout）：負載均衡器已經把請求轉發出去，但等不到後端在規定時間內回應。它偏向「後端太慢或卡住」，或是超時設定層級不一致。

但注意，這不是絕對定律。即便錯誤碼含義清楚，仍可能因為你用的是不同服務（ALB、NLB、API Gateway、CloudFront）或你的架構很複雜而混淆。因此更務實的做法，是把問題限制在「你這次到底用的是哪個入口」以及「錯誤發生在請求生命週期的哪個環節」。

第二章：先確認你用的是哪種負載均衡與流量路徑

在 AWS 世界裡，502/504 的來源常常不是單一元件。你可能是用 ALB 直接對應 EC2 或 ECS，也可能是 NLB 接到私有服務，再由應用層代理轉發；更複雜的還會有 CloudFront、WAF、API Gateway 疊在前面。

AWS國際帳號註冊 因此建議你從「流量入口」開始確認，至少回答三個問題：

• 你看到錯誤碼的請求，是從 哪個 URL/域名 進來？背後對應的服務是 ALB、NLB、CloudFront 還是 API Gateway？
• 請求到達負載均衡後，下一跳是什麼？是 EC2、ECS、Lambda（若走整合）、還是其他內部服務？
• 你是否使用了多層代理或多個負載均衡（例如先 ALB、再反向代理、再進到服務）？

如果你已經知道是 ALB（最常見），那後續的排查會主要圍繞：目標群組健康檢查、listener 規則、target 的回應、以及各種 timeout 設定（ALB idle timeout、target response timeout、連線耗盡等）。

第三章：502 常見根因與解法（目標未就緒、連線失敗、回應不正確）

502 通常不像 504 那樣暗示「等待太久」，而是表示負載均衡在把請求轉發到目標時，遇到不可用或無法取得正確回應的情境。下面列出實務上最常見的幾類根因與處理方法。

小節 3.1：目標群組健康檢查未通過，或健康狀態在抖動

許多團隊第一次踩坑時會忽略健康檢查。明明服務看起來是「跑著的」，但只要健康檢查不通，就會被 ALB 視為不可用，導致轉發失敗或回應異常，進而出現 502。

你要做的檢查包括：

• 目標群組的 health check protocol/path/port 是否正確。
• 應用是否能在健康檢查的路徑回應（例如 /healthz），且回應速度足夠快。
• 安全群組/NACL 是否允許負載均衡到目標的健康檢查流量。
• 目標群組是否包含錯誤的埠或目標類型（Instance vs IP vs Lambda/其他）。
• 健康狀態是否在發生事件（部署、擴縮容、重啟）時短暫轉黃，造成「一瞬間的不可用」而累積錯誤。

解法通常是：修正健康檢查設定、確保健康端點可用且權限/網路通、以及調整健康檢查的間隔/超時/成功次數，讓它更符合你的應用啟動時間。

AWS國際帳號註冊 小節 3.2：listener 規則導致請求路徑被送到錯誤的目標群組

ALB 的 listener rules（條件式轉送）如果配置錯誤，例如：

• 路徑比對順序錯誤（更精細的規則應該放在更前面）。
• host-header 條件與實際請求不一致（你用內網測試時是 localhost，正式環境是自訂網域）。
• 權重/固定回傳規則導致流量被分配到沒有期望的目標群組。

也可能造成 502，因為某些目標群組根本沒有正確回應你的請求類型。

AWS國際帳號註冊 解法是：用同一份測試請求（帶上真實 host header）去確認規則命中哪個 target group，並在維運日誌中建立「規則命中」或「回應路徑」的觀測。

小節 3.3：安全群組/網路 ACL 阻擋了連線或回包

502 的另一個常見來源是網路層的問題。即使應用正常，只要負載均衡到目標的連線沒建立起來，就會出現錯誤。

你需要檢查：

• ALB 的安全群組是否允許對目標安全群組的特定連接埠。
• 目標安全群組是否允許從 ALB 的安全群組來源連到服務埠。
• VPC 子網路路由表、跨 AZ、以及是否存在 NACL 針對某些埠/方向做了限制。

尤其在多環境（dev/staging/prod）共用 VPC 或重用安全群組時，很容易出現「來源/目標沒對到」的問題。這類問題解法通常不是改應用，而是把網路規則補齊到最小必要集合。

小節 3.4：目標服務回應了不符合協定或大小/格式問題

如果你的後端偶爾回應錯誤內容（例如直接關閉連線、回傳非預期格式、或在反向代理層出現協定問題），ALB 可能把它視為無法處理的上游回應，導致 502。

要排查這件事，可以從兩端觀測：

• 目標服務端的 Web 伺服器日誌：是否有 request 進來、是否在同一時間大量失敗。
• 負載均衡提供的存取日誌：可以看到對應的請求是否被轉發，以及回傳狀態。

若是反向代理（例如 Nginx/Envoy）配置問題，常見例如 upstream 逾時後連線行為不一致、或在特定路徑返回不完整 header。解法是對上游錯誤做一致的回傳策略，並避免在超時/重試時讓連線層級留下不一致狀態。

第四章：504 常見根因與解法（後端逾時、資源耗盡、超時層級不一致）

504 的訊號相對直觀：負載均衡等待後端回應時超時。這通常比 502 更像「可預期的效能或超時設定問題」。但要真正解決，仍需釐清它是：

• 後端真的慢（演算法、資料庫、外部 API 變慢）。
• 後端卡住（死鎖、連線池耗盡、等待某個鎖或 I/O）。
• 負載均衡的 timeout 設太短。
• timeout 在不同層級設置不一致，導致某層提前斷開。

小節 4.1：ALB 與後端的 timeout 不一致

在 ALB 架構中，你要特別留意兩類超時概念：

• Idle timeout：連線在「沒有傳輸資料」時的空閒超時。
• 後端響應/連線的其他逾時設定（視你的架構而定，例如應用程式/反向代理/服務框架的 request timeout）。

常見情境是：你的應用在處理很久，但只要處理中間沒有持續輸出資料（例如沒有 chunked encoding 或心跳），連線就可能在某一層被當成空閒而終止。最後你看到的是 504，但真正原因是「資料沒在規定時間內被送回」。

解法包括：

• 調整 ALB idle timeout，使其大於你實際的最大處理時間或至少大於「中間無輸出的時間」。
• 同步調整反向代理與應用程式的 timeout，讓最短的那層能容納你的工作流程。
• 對於長任務，改用非同步模式：例如先回 202/任務 ID，再由背景處理與通知結果，避免前端請求被迫等待到超時。

小節 4.2：後端資源耗盡（CPU、記憶體、執行緒、連線池）造成排隊

在流量上升或後端某段時間不可用時，504 不一定是「後端處理時間變長」，也可能是「排隊變長」。例如：

• 應用層的執行緒/worker 數量不足，請求在應用內排隊。
• 資料庫連線池耗盡，導致等待連線。
• AWS國際帳號註冊 外部服務（第三方 API、內部服務）回應變慢，使請求線程一直被卡住。

解法不是只調大 timeout，而是先確保容量與背壓策略。你可以採取：

• 量測端到端耗時：ALB 到後端的處理時間、後端到資料庫的時間、外部依賴的耗時。
• 監控後端的 saturation：CPU 使用率、記憶體、GC、連線池等待時間、錯誤率。
• 限制並發與實作降載：對某些低優先級 API 先排隊或回退。
• 必要時擴縮容：讓後端增加 worker/節點數量，以降低排隊時間。

如果你的系統在高峰時經常出現 504，通常已經不是「單純超時」問題，而是吞吐與容量設計需要修正。

小節 4.3：後端死鎖或特定查詢造成長時間阻塞

504 常會在「特定路徑」或「特定參數」出現。例如生成報表、批次匯出、或執行複雜查詢。當這些流程遇到資料鎖競爭或效率差的查詢，請求可能在後端停住，最後由負載均衡超時。

解法包含：

• 針對發生 504 的路徑做分組統計：時間分布、參數分布。
• 檢查資料庫慢查詢、鎖等待（deadlock/lock wait）、執行計畫。
• 為長任務加上取消/超時機制：讓後端可在合理時間內終止並回傳可追蹤的錯誤。
• 必要時調整查詢策略：加索引、改寫 SQL、拆分批次、預先計算。

小節 4.4：重試與多層超時疊加，導致整體等待超出預期

在某些架構中，你會在多層做重試：例如負載均衡層、應用程式層、以及外部呼叫層都各自重試。當後端本來就慢，重試會讓請求更久才成功或更快失敗。

你看到的 504 可能不是單次等待超時，而是「多次重試」把整體時間拉爆。解法是：

• 統一重試策略：只在最適合的層重試，並設定全局最大耗時。
• 重試採取指數退避並限制次數。
• 針對非冪等操作避免重試或改成具冪等性的設計（例如帶請求 ID）。

第五章：建立可操作的排查流程：從錯誤現象到根因

光列原因不夠，最重要的是把它變成你面對事故時能直接照做的流程。以下是一套偏實務、容易落地的排查路徑。你可以在 ALB 為入口的架構套用；若你是 NLB 或有其他入口，也能類似映射。

小節 5.1：先鎖定「哪個 listener/哪個 target group」

先不要看整個系統。你要找出錯誤碼主要發生在哪個規則。常見做法：

• 從存取日誌或指標中找出出錯的時間區間、路徑、以及是否集中於特定 host/path。
• 確認該路徑命中的 listener rule。
• 確認對應的 target group 是不是當時健康狀態在波動。

小節 5.2：用健康檢查狀態判斷是 502 還是「錯誤被掩蓋」

如果你看到大量 502，第一步就看 target group 的健康檢查是否正常。如果不正常，優先處理網路、健康檢查端點與啟動時延。

AWS國際帳號註冊 如果健康狀態看起來正常，但仍有 502，下一步才是：

• 檢查目標端的錯誤率（5xx）、連線中斷、以及是否有容器重啟或崩潰。
• 檢查安全群組與 NACL 是否在事故時間被改動。
• 檢查是否有部署剛完成但後端尚未完全熱身（例如快取沒載入、緩啟動造成延遲）。

小節 5.3：如果是 504，先判斷「是慢」還是「卡住」

面對 504，你需要用時間線去判斷：

• 如果錯誤是隨著流量增加而逐步上升，通常是資源耗盡/排隊。
• 如果在特定路徑或特定參數集中爆發，通常是死鎖或慢查詢。
• 如果在部署或擴縮容後短時間出現，可能是新實例尚未穩定就開始承接流量，或冷啟動造成處理時間超出 timeout。

這一步的目的，是讓你決定要優先查效能（metrics）還是查應用行為（logs/traces）。

小節 5.4：同時比較各層 timeout，找出最短那個

許多 504 的根因不是「後端慢」本身，而是「某一層 timeout 比你想的短」。你要把超時相關設定列出來：

• 負載均衡層 timeout / idle timeout。
• 反向代理（如 Nginx/Envoy）request/read timeout。
• 應用程式框架的 request timeout。
• 資料庫查詢 timeout、外部 API timeout。
• 重試總耗時。

解法是讓它們符合你的服務 SLA：如果你允許最長處理 30 秒，就要確保所有層級的超時都至少大於 30 秒（或設計成能中途返回可接受的資訊）。否則你永遠會用「加長負載均衡 timeout」掩蓋真正的設計不一致。

第六章：具體修復策略（不只調參，要讓系統更穩）

當你定位根因後，修復通常分為三類：網路與健康檢查修正、超時與連線行為調整、以及容量與架構性的改善。以下給出更具體的落地建議。

小節 6.1：把健康檢查端點做成真正可觀測與可用

很多健康檢查端點只是回傳 200，但沒有反映依賴是否可用。建議：

• 健康檢查要覆蓋「服務本體」至少一個必要依賴（例如資料庫可連、快取可用），但不要太重導致健康檢查本身變慢。
• 對啟動期做 grace：讓新實例能完成快啟或快取預熱再變健康。
• 把健康檢查與監控綁在一起：你不只要知道健康狀態，還要知道它為什麼不健康。

AWS國際帳號註冊 小節 6.2：對長任務採非同步化，避免 504 成為常態

如果你的某些 API 本來就可能跑超過數十秒，強行用同步 HTTP 等待很容易在高峰時爆掉。非同步化常見作法：

• 前端呼叫回傳任務 ID。
• 後端背景處理，處理完成後以輪詢或推送通知。
• 任務狀態可查，並提供可追蹤的錯誤訊息。

這種改造能顯著降低負載均衡層的超時壓力，也讓錯誤更可控。

小節 6.3：容量與背壓設計，讓系統「慢下來但不崩」

504 往往代表系統已在飽和。解法不一定是「立刻擴到無限大」。更合理的是：

• 設計背壓：在隊列或併發超過阈值時，拒絕非必要流量或回退到降級模式。
• AWS國際帳號註冊 針對不同重要度設不同策略：例如登入與支付必須更高 SLA。
• 對資料庫與外部 API 做連線池上限、超時與熔斷（避免拖垮整個服務）。

小節 6.4：建立事故用的儀表板與告警，把「觀測」變成日常

如果你每次出錯都靠猜，修復會變得非常痛苦。建議你至少準備以下告警/指標：

• AWS國際帳號註冊 負載均衡的 4xx/5xx 比例與錯誤碼分佈（502/504 分開）。
• target group 的 healthy/unhealthy 數量變化。
• 目標端的 request latency、錯誤率、重啟/崩潰事件。
• 資料庫的慢查詢與鎖等待指標。
• 應用層的併發、排隊長度、連線池等待時間。

當下一次出現 502/504，你會立刻知道是健康狀態問題、效能排隊問題，還是某個依賴開始慢了。

第七章：常見案例拆解（用你可能遇到的場景對號入座）

小節 7.1：部署後短時間 502，接著恢復

這類最常見的原因是部署造成「新實例尚未就緒」但已被接收流量。你可能看到：

• target group 從 unhealthy 變健康需要較長時間。
• AWS國際帳號註冊 或健康檢查端點回應很快，但真正處理業務時依賴尚未就緒。

解法通常是：調整啟動時間 grace、讓健康檢查更貼近真實業務依賴、以及確保部署策略有足夠的緩衝（例如逐步滾動、避免一次替換過多）。

小節 7.2：報表匯出大量 504，只在特定時段

這通常是慢查詢或卡住的任務。例如：

• 同時匯出很多資料造成資料庫負載飆升。
• 查詢缺索引或執行計畫不穩。
• 外部服務依賴在特定時段變慢。

解法是：針對匯出任務做非同步、優化查詢、加上任務取消/超時，並建立能針對任務類型分開觀測的指標。

小節 7.3：整體 504 上升但 target group 都健康

這代表後端還在回應，但回應「太慢」或「排隊」。你需要檢查：

• CPU/記憶體是否飽和。
• 連線池是否耗盡。
• 是否有新的依賴（例如外部 API）造成平均延遲上升。

解法通常是容量擴充、熔斷與降級、調整資料庫連線/索引、或修正特定瓶頸。

第八章：預防勝於修補——讓 502/504 變少的日常做法

真正好的系統不是等事故發生後才修，而是把常見失敗模式提前設計好。以下是一些「低成本但高效」的預防策略：

• 讓健康檢查更有意義：不是只要回 200 就好，而要貼近依賴可用性，但同時保持輕量。
• 統一超時策略：把 timeout 當成契約，而不是單點調整。把最短層級找出來並對齊 SLA。
• 長任務非同步化：避免把所有工作都塞進同步 HTTP。
• 設計背壓與熔斷：讓系統在飽和時拒絕或降級，而不是一直堆隊列直到超時。
• 建立端到端追蹤：當出現 502/504，你不應該只知道「錯了」，你需要知道「卡在哪裡」。

當你做到這些，你會發現 502/504 不再是神秘的錯誤碼，而是可被理解、可被定位、可被修復的工程問題。

結語：把錯誤碼變成線索，而不是結論

502 與 504 的差異，對技術排查來說是巨大的分水嶺：一個偏向「無法連到或回應不正確」，一個偏向「等待超時」。但真正的解決，仍然取決於你是否能把鏈路拆開，逐步驗證健康狀態、網路通行、listener 命中、後端處理時間與超時層級一致性。

下次你再看到 502/504，先別急著猜「一定是程式壞了」。把它當作一張地圖：用正確的觀測點（健康檢查、存取日誌、目標端延遲與錯誤、資料庫慢查詢、timeout 統計）一步步走到根因。當你能做到這點，錯誤碼就不再是壓力來源，而是你系統健康度的直觀指標。