您在使用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錯誤，如下圖所示。
解決方案
修改主設定檔，注釋預設網站。
在健全狀態檢查配置中添加檢查網域名稱。