阿里雲帳號認證代辦 阿裡雲 SLB/ALB 負載均衡提示 502 Bad Gateway 診斷與後端 ECS 排查

先理解 502 的真正意思

阿里雲帳號認證代辦 在阿里雲的 SLB 或 ALB 場景裡，看到 502 Bad Gateway，很多人第一反應是「後端掛了」。其實這個判斷只對了一半。502 的本質是：負載均衡已經收到來自用戶的請求，但在轉發給後端 ECS 之後，沒有拿到一個它認得懂、也來得及回來的正常回應。也就是說，問題不一定出在入口，也不一定只出在伺服器宕機，還可能出在應用進程、網路連線、超時設定、健康檢查、協議不匹配，甚至是後端資源耗盡。

這也是排查 502 時最容易犯的錯：看到報錯就直接重啟服務，結果短暫恢復後又反覆出現。真正有效的方法，是先把鏈路拆開，分別確認「請求有沒有到達」「後端有沒有接住」「後端有沒有正常回應」「回應是否符合負載均衡預期」。只要這四個問題依序釐清，絕大多數 502 都能定位到具體層面。

先看是哪一層先出問題

SLB 和 ALB 都是流量入口，但它們處理流量的方式不完全相同。SLB 更偏向傳統負載均衡，常見於四層或七層轉發；ALB 則更偏向應用層，通常和域名、路由規則、Host、Path 這些條件綁得更緊。也正因為如此，同樣是 502，在兩者身上的表現和排查重點會有細微差異。

如果是 SLB 場景，先確認後端 ECS 是否都被標記為健康，因為健康檢查失敗時，流量可能被分配到少數節點，甚至被錯誤導向異常實例。若是 ALB 場景，除了健康檢查，還要特別看轉發規則是否命中，因為規則沒命中時，請求可能根本沒有進到你以為的服務。很多看似後端故障的問題，最後其實是 Listener、Server Group、Target Group 或路由規則配錯了。

排查的第一步，不是登入 ECS，而是先從控制台和監控看入口層狀態：目標實例是否全部健康、最近是否做過擴縮容、是否調整過證書、是否更換過後端埠、是否剛修改過健康檢查路徑。這些變更往往比服務本身更容易直接觸發 502。

從後端 ECS 開始，先確認服務到底在不在

阿里雲帳號認證代辦 最基礎也最重要的一步，是確認 ECS 上的服務程序真的在運行，而且還在監聽對外提供的埠。不要只看進程名，還要看監聽狀態。很多服務表面上還活著，但已經卡死、拒絕新連線，或者只綁定在 127.0.0.1，本機能訪問，外部卻完全接不進去。

在 Linux 上，通常會先檢查 `systemctl status`、`ps -ef`、`ss -lntp` 或 `netstat -lntp`，確認應用程序是否啟動、是否在預期埠上監聽、是否只綁了本地回環地址。如果是容器化部署，還要額外確認容器內部埠與宿主機映射是否一致，因為 ALB 或 SLB 看到的是對外埠，不是容器內部埠。

這裡有一個常見誤區：服務顯示 running，不代表它能對外正常提供流量。舉例來說，Web 程序可能在啟動過程中載入失敗但沒有退出，或者應用本身啟動成功，卻因資料庫連線池耗盡而在收到請求時一直阻塞。對負載均衡來說，這種情況最終都會表現成 502，因為它拿不到有效回應。

先做本機回環測試

登上 ECS 後，不要急著從外部測。先在本機用 `curl 127.0.0.1:埠` 或服務健康檢查路徑直接訪問，確認應用自己能否正常回應。如果本機都失敗，問題多半在應用、依賴服務、配置檔或程序本身。如果本機成功、外部失敗，才更像是安全組、監聽地址、Nginx 轉發、健康檢查或負載均衡配置問題。

若後端前面還有一層 Nginx、Apache、Tomcat 或其他反向代理，測試也要分層做。先測應用直接服務端口，再測代理層端口，最後再從 SLB/ALB 經由域名測試。只測最外層，往往只會得到一個模糊的 502，無法知道到底是哪一層把請求卡住了。

健康檢查是 502 的高發區

很多 502 不是突發故障，而是健康檢查配置和實際服務不一致造成的。比如健康檢查路徑寫成 `/health`，但應用實際返回的是 `/healthz`；又或者檢查要求 200，服務卻因為重定向返回 301；再或者檢查使用 HTTP，但後端實際只開了 HTTPS。這些情況下，負載均衡會把實例判定為不健康，流量分配就會異常。

健康檢查除了路徑和協議，還要看埠號、返回碼範圍、超時時間和失敗閾值。超時設得太短，後端一旦遇到資料庫抖動、磁碟 IO 飆高或 GC 停頓，就可能被誤判；失敗閾值設得太低，短暫波動就會把節點踢出服務池。這種配置在高峰期尤其容易放大問題。

排查時，建議把健康檢查和真實業務請求分開看。健康檢查是用來判斷節點是否適合接流量，不代表業務一定健康；同樣，業務請求能正常返回，也不代表健康檢查一定通過。最理想的做法，是讓健康檢查路徑盡量輕量、穩定、無依賴，返回值簡單明確，避免被其他業務邏輯拖累。

安全組、網路 ACL 和埠放行別漏掉

如果 ECS 服務在本機正常，但外部仍然 502，就要看網路層是否放通。首先檢查安全組是否允許負載均衡來源地址訪問後端埠。很多人只放行了自己的辦公 IP，卻忘了負載均衡訪問後端時使用的是雲上內網流量，不是自己電腦的出口地址。這會導致健康檢查失敗，或者外部請求在到達 ECS 之前就被攔掉。

其次要看網路 ACL、主機防火牆和雲上策略是否疊加限制。即使安全組放通了，`firewalld`、`iptables`、`ufw` 仍然可能把埠擋住。尤其在運維人員臨時加固機器後，常會出現「昨天還正常，今天開始 502」的情況，原因其實只是防火牆規則被改了。

如果是使用私網 SLB/ALB，更要注意後端 ECS 與負載均衡是否在同一可訪問網段內，路由表是否正確，跨 VPC、跨交換機、跨可用區的配置是否有遺漏。這些問題平時不一定暴露，一旦擴容或切換流量，就容易直接變成 502。

後端應用層問題最容易被忽略

真正讓 502 反覆出現的，很多時候不是網路，而是應用層。負載均衡器只負責轉發，它不理解你的業務邏輯。只要後端返回不及時、格式異常、連線被提前關閉，對前端來說都可能是 502。

阿里雲帳號認證代辦 常見的應用層問題包括：程式異常退出、記憶體洩漏、執行緒池耗盡、連線池耗盡、資料庫慢查詢、第三方接口超時、應用在高峰期排隊過長。這些問題在單機測試時不一定明顯，但一旦前面掛上 SLB/ALB，並發流量進來，就會迅速暴露。

特別是 Java、PHP-FPM、Node.js、Go 這類服務，超時和資源耗盡的表現各不相同。Java 可能是 GC 造成長時間停頓；PHP-FPM 常見的是 worker 不夠、請求堆積；Node.js 則可能因事件迴圈被阻塞而表現出大量超時；Go 雖然併發能力強，但如果上游依賴卡住，照樣會把連線拖死。排查時不能只看錯誤碼，還要結合應用日誌、訪問日誌和資源監控一起看。

看日誌要抓住兩個時間點

第一個時間點是用戶請求到達的時間，第二個時間點是服務內部開始處理和最終結束的時間。把這兩個時間點對上，通常就能發現請求是卡在入口、卡在業務邏輯，還是卡在依賴服務上。若日誌裡根本沒有收到請求，問題大概率在前面一層；若收到了請求但遲遲沒有結束，通常是應用阻塞或下游依賴超時；若開始與結束都很快，但對外仍然 502，則要回頭看返回頭、協議和代理配置。

訪問日誌也很重要。要看狀態碼分佈是否集中在某一時間段，是否只有某一台 ECS 出問題，還是整個服務池一起抖動。如果只有單節點異常，先懷疑該機器的資源或配置；如果是全量異常，先看上游變更、共用依賴和發布版本。

代理層配置錯誤會把問題放大

很多 ECS 前面並不是應用直出，而是還有 Nginx、Apache、Envoy 或其他代理層。代理層一旦配置錯誤，502 幾乎是最常見的結果。常見問題包括 upstream 地址寫錯、埠不對、keepalive 配置不合理、Header 太大、HTTP 與 HTTPS 混用、WebSocket 支援缺失、最大連線數不足等。

尤其是反向代理轉發到後端應用時，如果後端程序因超時主動斷開連線，而代理還在等回包，就會看到 502。這種情況常見於代理超時設太長、應用超時設太短，兩邊沒有對齊。排查時應同時檢查代理層和應用層的 timeout、read_timeout、send_timeout、proxy_connect_timeout 等參數，保證整條鏈路的超時策略一致。

對 ALB 來說，還要注意 HTTP/2、HTTPS 終止、SNI、證書鏈是否完整。證書過期或鏈不完整，不一定總是顯示為證書錯誤，有時也會以 502 或握手失敗的形式出現。當你看到 502 卻又伴隨少量 400、499 或握手異常，通常意味著問題不只一層。

資源耗盡時，502 只是表面現象

當 ECS CPU 飆高、記憶體不足、磁碟 IO 爆滿、負載過重時，負載均衡看到的往往只是請求超時或連線被重置。此時 502 不是根因，而是症狀。真正要看的，是機器是否還有能力在合理時間內完成請求。

CPU 高時，程序可能排不到執行時間；記憶體緊張時，系統可能開始 swap，整體延遲迅速放大；磁碟 IO 慢時，日誌寫入、資料庫查詢、快取落盤都會受到影響；連線數打滿時，新請求只能排隊或失敗。這些問題往往同時存在，造成連鎖反應。

因此，在排查 502 時，監控圖不能只看錯誤率。要同步看 CPU、Load Average、內存、Swap、磁碟 IO、網卡流量、TCP 連線數、應用延遲、後端依賴延遲。只要其中一項持續高位，就能解釋為什麼負載均衡一直拿不到穩定回應。

一個實用的排查順序

面對阿里雲 SLB 或 ALB 的 502，最有效的不是憑經驗亂試，而是固定一個排查順序。先確認入口層健康狀態，再確認後端 ECS 服務是否存活，接著檢查本機自測是否正常，然後看代理層與應用層日誌，最後再回頭驗證健康檢查和安全組配置。這個順序的好處是，可以把「猜測」變成「證據」。

你可以把它簡化成六步：第一，看負載均衡後端實例是否健康；第二，看 ECS 服務是否在監聽；第三，本機 `curl` 是否成功；第四，檢查安全組和防火牆；第五，看代理與應用日誌；第六，看 CPU、記憶體、IO、連線池等資源狀態。只要依序往下排，通常不需要太久就能縮小到具體原因。

如果故障發生在發布後，還要優先回看最近一次變更。包括程式版本、配置文件、證書、負載均衡規則、健康檢查、WAF 規則、容器映射、埠號調整。大量 502 其實不是系統自然老化，而是一次看似很小的變更把原本穩定的鏈路打斷了。

常見場景對應的處理方式

如果健康檢查失敗，先對齊路徑、協議、返回碼和超時，再確認該路徑是否依賴資料庫或外部服務。若本機測試正常、外部仍失敗，重點查安全組、防火牆和監聽地址。若只有部分請求 502，則要看是否存在長請求、慢接口、上游依賴卡頓或某些特定路由出問題。若是所有流量都失敗，則要懷疑後端服務整體不可用、代理層配置錯誤或負載均衡規則未命中。

對於反覆重啟後短暫恢復的情況，不要只把它當成修復。那通常只是暫時清空了連線、釋放了資源、刷新了狀態，根因沒有被處理，過一會兒還會回來。要真正穩定，就必須把卡住請求的依賴、超時、資源瓶頸和異常流量模式一起處理掉。

把 502 當成一張故障地圖

502 不是單一錯誤，而是一張故障地圖。它告訴你：入口已經把流量送出去了，但後面某一段沒接住。你要做的不是盯著錯誤碼本身，而是沿著請求路徑一段段往下拆。從 SLB/ALB，到安全組和網路，再到 ECS 服務、代理層、應用邏輯、資料庫和第三方依賴，每一層都可能是答案。

當你把這個思路建立起來，502 就不再是讓人頭痛的黑盒問題。它只是系統在提醒你：某一層超時了、斷線了、回應慢了，或者根本沒有按預期工作。真正成熟的排查方式，不是靠運氣碰對，而是用層次化的方法快速定位，讓每一次故障都能沉澱成可重複的經驗。

對運維、後端和架構設計來說，這也是最值得建立的基本功。因為只要服務還在跑，502 就一定還會再來。差別只在於，下次你是花半小時定位，還是五分鐘就能看出問題在哪一層。