阿里雲帳號購買 阿裡雲 SLB 健康檢查頻繁失敗（Health Check Failed）的常見原因與解決
先看懂健康檢查為什麼會失敗
阿里云 SLB 的健康檢查，本質上是在替你持續確認後端服務是否真的可用。它不是單純地測一下埠開沒開，而是依照你設定的協議、埠、請求路徑與回應條件，去判斷一臺後端伺服器是不是還能正常承接流量。當健康檢查頻繁失敗，SLB 便會把該後端標記為不健康，進而停止轉發或降低權重，最終表現為請求波動、部分使用者無法訪問，甚至整體服務抖動。
很多人一看到 Health Check Failed，第一反應是去懷疑 SLB 本身有問題，但實際上，大多數情況都出在後端服務、網路策略、應用響應或檢查配置不匹配。也就是說，健康檢查只是把問題放大了，真正需要解決的是後端鏈路中的某個環節。若不先理解健康檢查的工作方式，很容易把時間浪費在錯誤方向上。
最常見的幾類原因
後端服務本身沒有穩定回應
這是最常見的一類原因。健康檢查雖然很短，但它對後端的即時回應非常敏感。如果應用正在重啟、依賴的資料庫尚未連上、執行緒池被打滿、GC 頻繁停頓，或者某些請求路徑在高峰期偶發超時，都可能讓健康檢查連續失敗。很多服務平時看起來還能對外提供部分功能，但健康檢查打到的那個入口卻剛好卡住，於是 SLB 便認定它不可用。
還有一種情況是業務接口本身可以返回結果，但返回速度太慢。健康檢查不是等到天荒地老，它有固定的超時時間。只要後端在這個時間內沒有正確回應，即便最終回來了，也會被判定失敗。這也是為什麼同一臺機器在壓力不大時正常，一到流量上來就開始反覆掉線。
健康檢查協議、埠或路徑配置不對
配置不匹配是另一個高頻問題。比如後端服務實際只開了 HTTPS，卻把健康檢查設成 HTTP；或者服務真正提供健康頁面的埠是 8080，SLB 卻在檢查 80 埠。再比如檢查路徑寫成了 /health，但應用實際返回健康資訊的地址是 /healthz。這類問題通常不會造成服務立刻崩潰，但會讓健康檢查永遠拿不到期望回應。
阿里雲帳號購買 有些團隊還會忽略回應碼的限制。健康檢查常常不是只要有內容就算通過，而是需要符合特定的狀態碼或字串內容。若後端在登入態不足時返回 302 跳轉到登入頁，或者反向代理把請求導到 403、404，SLB 也會認為檢查失敗。看起來是應用活著，實際上對健康檢查來說，它返回的不是預期內容。
安全組、防火牆或白名單攔截了探測請求
健康檢查流量雖然來自 SLB，但在後端視角裡仍然是外來請求。如果安全組規則只放行了業務流量，卻沒有放行健康檢查來源，探測包會被直接擋住。Windows 防火牆、Linux iptables、雲防火牆、WAF、甚至應用層的來源白名單，都可能成為阻擋點。
這類問題的特徵通常很明顯：業務流量看似正常，但健康檢查就是失敗，且失敗非常穩定。你在伺服器上抓包或查看日誌時，會發現根本沒有相關請求進來，或者請求到了但立刻被拒絕。這說明問題不在應用邏輯，而在入口策略。
後端資源過高，導致檢查被拖慢
CPU、記憶體、磁碟 I/O、網路帶寬任何一項接近瓶頸，都可能讓健康檢查失敗頻率升高。特別是在尖峰期，業務接口大量佔用資源，健康檢查往往排在隊尾，等輪到它時已經超時。若是容器環境，還要再加上容器配額限制、探針與服務資源爭用、節點壓力過大等問題。
這類故障最麻煩的地方在於，它不是永久性的。你在某個時間點看到的可能只是短暫失敗，但當失敗次數累積到閾值後，SLB 會把後端摘除，於是原本只是抖一下的系統，變成了明顯不可用。很多看似神秘的健康檢查異常，其實只是資源不足的外在表現。
回應內容與健康檢查規則不一致
健康檢查不只是看通不通，還會看內容。若你設定了特定回應字串，後端一旦改版、調整了返回模板、切換了編碼，或者把原本固定的健康頁改成動態頁面，檢查也可能失敗。有些系統升級後把健康接口一起改壞了，但業務主流程又沒立刻受影響，這就很容易誤判成 SLB 抽風。
另一個常見細節是重定向。某些框架在沒有命中正確 Host、沒有帶上必要 Header，或未通過身份判斷時，會自動返回跳轉。對人工訪問來說，這可能只是正常流程；但對健康檢查來說，這往往等同於失敗。健康檢查應該盡量使用一個簡單、固定、無需認證的返回入口。
排查時應該怎麼走
先確認是哪一層出了問題
排查的第一步，不是急著改配置，而是判斷失敗發生在入口、網路、還是應用層。可以先看 SLB 的後端健康狀態變化，確認是哪幾臺機器不健康，以及是偶發還是持續。若只有單臺後端失敗，通常更像是機器自身或本地配置問題；若所有後端一起失敗，就要優先懷疑檢查配置、網路規則或共同依賴故障。
接著直接在後端機器上模擬健康檢查請求，用相同協議、埠和路徑去訪問。不要只在瀏覽器里看首頁，而要盡量還原 SLB 真正打進來的請求形態。很多問題一旦在本機復現，排查速度會快很多，因為你能立刻看見返回碼、響應時間和日誌。
重點查看返回碼、超時與跳轉
如果檢查失敗頻繁，請特別留意是否返回了 301、302、403、404、500 之類的狀態碼。301 和 302 往往意味著路徑或協議不對，403 多半與權限或白名單有關，404 是路徑錯誤，500 則通常代表應用內部異常。若是超時，則要看服務是不是卡在資料庫、外部依賴、鎖競爭或資源耗盡上。
有時候請求本身已經到了後端，但回應內容不符合預期，日誌未必會出現明顯錯誤。此時要對照健康檢查規則逐條核實，包含協議、埠、路徑、預期狀態碼、返回字串，以及是否需要特定 Host。只要其中一項不一致，健康檢查就可能失敗。
從系統和應用日誌一起看
單看 SLB 日誌，通常只能知道失敗了，卻不一定知道為什麼失敗。更有效的做法，是把 SLB 健康狀態變化與後端的應用日誌、系統日誌、資源監控放在同一時間線上。當健康檢查開始失敗時，CPU 是否飆高，資料庫是否抖動，程序是否重啟，磁碟是否滿了，這些線索往往能直接定位問題根因。
若是容器或 Kubernetes 環境，還要額外查看 Pod 是否經歷了重啟、探針是否互相影響、服務是否切換到了未就緒的實例。很多健康檢查失敗並不是網路不通，而是編排系統在頻繁調度，導致短時間內可用性波動。
阿里雲帳號購買 對症下藥的修復方式
把健康檢查入口做得更穩定
最好的做法，是給 SLB 準備一個獨立、輕量、無業務依賴的健康檢查接口。這個接口只做最基本的存活回應，不查資料庫，不讀外部服務，不走複雜中間件。這樣一來，即使業務功能短暫受影響，也能讓 SLB 準確判斷後端是否真的完全失去能力，而不是被業務波動誤傷。
健康接口還應該保持返回穩定，避免在版本迭代中隨手改掉。若必須修改，也要同步更新 SLB 的健康檢查規則，並先在灰度環境驗證。這個細節看似簡單，但能少掉大量低級故障。
阿里雲帳號購買 統一協議、埠和路徑設定
修復時要把 SLB 設定和後端實際服務逐項對齊。HTTP 與 HTTPS 不要混用，埠號不要寫錯，路徑也不要依賴容易變動的業務接口。若服務會自動跳轉到 HTTPS，健康檢查也應直接採用對應協議，避免檢查請求在跳轉鏈路上耗時或被視為異常。
如果後端經過反向代理，還要確認代理層是否把健康檢查請求轉發到了正確位置。有些問題表面看是 SLB 設錯，實際上是 Nginx、應用閘道或服務網格把請求轉錯了地方。
放行必要的探測流量
對安全策略做最小且準確的調整。該放行的健康檢查來源要放行，該限制的業務端口仍然保持限制。不要為了圖快把整個安全組打開，也不要把防火牆規則放寬到失去邊界。健康檢查的放行應建立在明確的來源與協議基礎上，並且隨著架構變動及時更新。
若有 WAF 或額外防護設備，記得確認它們是否把探測請求識別成異常流量。很多時候問題不在 SLB，也不在應用，而是在防護設備過度攔截。這種情況下，將健康檢查路徑加入白名單，通常可以快速恢復。
處理資源瓶頸與慢響應
如果根因是資源不足，就不能只靠調高超時或提高檢查閾值來掩蓋。這種做法只能拖延暴露時間，卻不能解決問題。真正有效的方法，是優化慢查詢、減少啟動耗時、拆分重任務、提升執行緒與連線池管理效率，必要時直接擴容或升級實例規格。
對於有明顯高峰特徵的業務，健康檢查也要考慮容量波動。平時可用，不代表高峰可用。應把尖峰期的資源水位當成真實標準，而不是以空閒時的表現做判斷。
如何避免同樣問題反覆出現
把健康檢查當成一條獨立產品線管理
很多團隊把健康檢查看得太輕，覺得它只是附屬配置。實際上，它是整個流量入口的風險閥門。建議把健康檢查路徑、回應格式、依賴關係和變更流程單獨管理，納入發布清單與回歸測試。只要這條路徑穩定，SLB 的判斷就穩定，整體可用性也會更穩定。
同時，最好建立監控告警聯動。當健康檢查連續失敗時，除了 SLB 狀態告警，還應同步通知應用、系統與基礎設施負責人。這樣可以縮短定位時間，避免故障只在使用者那邊先被發現。
在發布前做一次完整驗證
每次上線前，都應該用和正式環境一致的健康檢查規則做驗證。不要只驗證首頁能打開，而要確認健康接口、埠、協議、回應碼、回應內容都完全一致。若是多環境、多可用區部署，更要避免其中某個環境配置不同，導致一半正常、一半失敗。
如果發布包含網路策略修改、證書更新、容器探針調整，這些都屬於高風險變更。此時應增加灰度與回滾預案，確保一旦健康檢查異常，可以快速回退到上一個穩定版本。
結語
阿里云 SLB 健康檢查頻繁失敗，看似是告警訊息，實際上是系統在提醒你：某個後端節點已經不再符合可用標準。它可能是應用慢了、協議錯了、路徑變了、規則擋了，也可能是資源撐不住了。只要把這幾類原因分開看，再按入口、網路、應用、資源四個層面逐步排查，大多數問題都能很快定位。
真正值得重視的，不只是把告警消掉，而是讓健康檢查變成一個穩定、可信、低成本的可用性指標。當它能準確反映後端狀態時，SLB 才能在故障發生前及時切流，整個服務架構也才算真正經得起流量和波動的考驗。
