您在使用CLB的過程中如果遇到健康檢查相關的問題，您可參考本文進行定位及處理。
健康檢查的原理是什么？
負載均衡采用集群部署。四層集群或七層集群內的相關節點服務器同時承載了數據轉發和健康檢查職責。
四層集群內不同服務器分別獨立、并行地根據負載均衡策略進行數據轉發和健康檢查操作。如果某一臺四層集群中的服務器對某一臺后端服務器健康檢查失敗，則該四層集群中的服務器將不會再將新的客戶端請求分發給相應的異常的后端服務器。四層集群內所有服務器同步進行該操作。
如下圖所示，傳統型負載均衡CLB健康檢查使用的地址段是100.64.0.0/10，后端服務器務必不能屏蔽該地址段。您無需在ECS安全組中額外針對該地址段配置放行策略，但如有配置iptables等安全策略，請務必放行（100.64.0.0/10 是阿里云保留地址，其他用戶無法分配到該網段內，不會存在安全風險）。
更多信息，請參見CLB健康檢查工作原理。
推薦的健康檢查配置是什么？
為了避免由于健康檢查頻繁失敗引起的切換對系統可用性造成的沖擊，健康檢查只有在健康檢查時間窗內連續多次檢查成功或失敗后，才會進行狀態切換。更多信息，請參見配置和管理CLB健康檢查。
以下是TCP、HTTP和HTTPS監聽建議使用的健康檢查配置。
配置 | 推薦值 |
健康檢查響應超時時間 | 5秒 |
健康檢查間隔時間 | 2秒 |
健康檢查健康閾值 | 3次 |
健康檢查不健康閾值 | 3次 |
以下是UDP監聽建議使用的健康檢查配置。
配置 | 推薦值 |
健康檢查響應超時時間 | 10秒 |
健康檢查間隔時間 | 5秒 |
健康檢查健康閾值 | 3次 |
健康檢查不健康閾值 | 3次 |
此配置有利于您的服務和應用狀態的盡快收斂。如果您有更高要求，可以適當地降低響應超時時間值，但必須優先保證服務在正常狀態下的處理時間小于這個值。
是否可以關閉健康檢查？
可以關閉。具體操作，請參見關閉健康檢查。
如果關閉健康檢查，當后端某個服務器健康檢查出現異常時，負載均衡還是會把請求轉發到該異常的ECS實例上，造成部分業務不可訪問。
如果您的業務對負載敏感性高，高頻率的健康檢查探測可能會對正常業務訪問造成影響。您可以結合業務情況，通過降低健康檢查頻率、增大健康檢查間隔、七層檢查修改為四層檢查等方式，來降低對業務的影響。但為了保障業務的持續可用，不建議關閉健康檢查。
TCP監聽如何選擇健康檢查方式？
TCP監聽支持HTTP和TCP兩種健康檢查方式：
TCP協議健康檢查通過發送SYN握手報文，檢測服務器端口是否存活。
HTTP協議健康檢查通過發送HEAD或GET請求，模擬瀏覽器的訪問行為來檢查服務器應用是否健康。
TCP健康檢查方式對服務器的性能資源消耗相對要少一些。如果您對后端服務器的負載高度敏感，則選擇TCP健康檢查；如果負載不是很高，則選擇HTTP健康檢查。
ECS實例權重設置為零對健康檢查有什么影響？
該狀態下，負載均衡不會再將流量轉發給該ECS實例，監聽的后端服務器健康檢查不會顯示異常。
將負載均衡后端ECS實例的權重置為零，相當于將該ECS實例移出負載均衡。一般是在ECS實例進行重啟和配置調整等主動運維時將其權重設置為零。
HTTP監聽向后端ECS實例執行健康檢查默認使用的方法是什么？
HEAD方法。
如果后端ECS實例的服務關閉HEAD方法，會導致健康檢查失敗。建議在ECS實例上用HEAD方法訪問自己IP地址進行測試：
curl -v -0 -I -H "Host:" -X HEAD http://IP:portHTTP監聽向后端ECS實例執行健康檢查的IP地址是什么？
CLB健康檢查使用的地址段是100.64.0.0/10，后端服務器務必不能屏蔽該地址段。您無需在ECS安全組中額外針對該地址段配置放行策略，但如有配置iptables等安全策略，請務必放行（100.64.0.0/10 是阿里云保留地址，其他用戶無法分配到該網段內，不會存在安全風險）。
為什么健康檢查監控頻率與Web日志記錄不一致？
負載均衡健康檢查服務也是集群方式的，這樣可以避免單點故障。負載均衡的代理分布到很多節點上，因此看到的健康檢查日志訪問頻率和控制臺設置的頻率不一致，這是正常現象。
負載均衡因后端數據庫故障導致健康檢查失敗，如何處理？
問題現象
ECS實例內配置了兩個網站：
www.example.com是靜態網站，aliyundoc.com是動態網站，都配置了負載均衡。后端數據庫服務異常，導致訪問www.example.com靜態網站出現502錯誤。問題原因
負載均衡健康檢查配置的檢查域名是
aliyundoc.com，RDS或者自建數據庫故障導致aliyundoc.com訪問異常，所以健康檢查失敗。解決方案
將負載均衡健康檢查域名配置為
www.example.com即可。
負載均衡服務TCP端口健康檢查成功，為什么在后端業務日志中出現網絡連接異常信息？
問題現象
負載均衡后端配置TCP服務端口后，后端業務日志中頻繁出現類似如下網絡連接異常錯誤信息。經過抓包分析，發現相關請求來自負載均衡服務器，同時負載均衡主動向服務器發送了RST數據包。
問題原因
該問題和負載均衡的健康檢查機制有關。
由于TCP對上層業務狀態無感知，同時，為了降低負載均衡健康檢查成本和對后端業務的沖擊，當前負載均衡針對TCP協議服務端口的健康檢查只會做簡單的TCP三次握手，而后直接發送RST包斷開TCP連接。數據交互流程如下：
負載均衡服務器向后端負載均衡服務端口發送SYN請求包。
后端服務器收到請求后，如果端口狀態正常，則按照正常的TCP機制返回相應的SYN+ACK應答包。
負載均衡服務器成功收到后端服務端口應答后，則認為端口監聽是正常的，判定健康檢查成功。
負載均衡服務器向相應TCP服務端口直接發送RST包主動關閉連接，結束本次健康檢查操作，且沒有繼續發送業務數據。
如上所述，由于健康檢查成功后，負載均衡服務器直接發送TCP RST包中斷了連接，并沒有做進一步的業務數據交互，導致上層業務（例如Java連接池等）認為相應的連接是異常的，所以會出現
Connection reset by peer等錯誤信息。解決方案
更換TCP協議為HTTP協議。
在業務層面，對來自SLB服務器IP地址段的相關請求做日志過濾，忽略相關錯誤信息。
為什么業務本身沒有異常但是健康檢查顯示異常？
問題現象
負載均衡HTTP方式的健康檢查始終失敗，但測試
curl得到的狀態碼是正常的。問題原因
如果返回的狀態碼與控制臺配置的正常狀態碼不一致，則判定健康檢查異常。如果您配置的正常狀態碼為http_2xx，則所有返回的非HTTP 2xx狀態碼均被認為是健康檢查失敗。
Tengine/Nginx配置執行
curl命令會發現沒有問題，但是執行echo命令會匹配到默認站點，導致測試文件test.html返回404錯誤，如下圖所示。
解決方案
修改主配置文件，注釋默認站點。
在健康檢查配置中添加檢查域名。