您在使用CLB的过程中如果遇到健康检查相关的问题，您可参考本文进行定位及处理。
健康检查的原理是什么？
健康检查是通过定期发送请求来确认服务器的状态。
CLB采用集群部署，集群内的节点服务器同时负责数据转发和健康检查。如果某台服务器健康检查失败，则不会再将新的客户端请求分发给该异常服务器。
CLB健康检查使用的地址段是100.64.0.0/10，后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外配置放行策略，但如有配置iptables等安全策略，请务必放行（100.64.0.0/10 是阿里云保留地址，不会存在安全风险）。
更多信息，请参见CLB健康检查。
推荐的健康检查配置是什么？
以下是建议使用的健康检查配置。
配置 | TCP/HTTP/HTTPS监听推荐值 | UDP监听推荐值 |
配置 | TCP/HTTP/HTTPS监听推荐值 | UDP监听推荐值 |
健康检查响应超时时间 | 5秒 | 10秒 |
健康检查间隔时间 | 2秒 | 5秒 |
健康检查健康阈值 | 3次 | 3次 |
健康检查不健康阈值 | 3次 | 3次 |
为了避免频繁切换影响系统可用性，健康检查需在时间窗口内连续多次成功或失败后才会切换状态。更多信息，请参见配置和管理CLB健康检查。
此配置有助于服务和应用状态的快速收敛。如有更高要求，可适当降低响应超时时间，但需确保服务处理时间小于该值。
是否可以关闭健康检查？
可以关闭。具体操作，请参见关闭健康检查。
关闭健康检查后，负载均衡仍会将请求转发到异常的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三次握手，然后发送RST包断开连接。具体流程如下：
负载均衡服务器发送SYN请求包。
后端服务器返回SYN+ACK应答包。
负载均衡服务器收到应答后，认为端口正常，健康检查成功。
负载均衡服务器发送RST包关闭连接，未继续发送业务数据。
由于健康检查成功后直接断开连接，上层业务（如Java连接池）认为连接异常，出现
Connection reset by peer等错误信息。解决方案
更换TCP协议为HTTP协议。
在业务层面，对来自SLB服务器IP地址段的请求做日志过滤，忽略相关错误信息。
为什么业务本身没有异常但是健康检查显示异常？
问题现象
负载均衡HTTP方式的健康检查始终失败，但测试
curl得到的状态码是正常的。问题原因
如果返回的状态码与控制台配置的正常状态码不一致，则判定健康检查异常。例如，配置的正常状态码为http_2xx时，所有非HTTP 2xx状态码均被认为是健康检查失败。
Tengine/Nginx配置中，执行
curl命令没有问题，但执行echo命令会匹配到默认站点，导致测试文件test.html返回404错误。
解决方案
修改主配置文件，注释默认站点。
在健康检查配置中添加检查域名。
- 本页导读 （1）
- 健康检查的原理是什么？
- 推荐的健康检查配置是什么？
- 是否可以关闭健康检查？
- TCP监听如何选择健康检查方式？
- ECS实例权重设置为零对健康检查有什么影响？
- HTTP监听向后端ECS实例执行健康检查默认使用的方法是什么？
- HTTP监听向后端ECS实例执行健康检查的IP地址是什么？
- 为什么健康检查监控频率与Web日志记录不一致？
- 负载均衡因后端数据库故障导致健康检查失败，如何处理？
- 负载均衡服务TCP端口健康检查成功，为什么在后端业务日志中出现网络连接异常信息？
- 为什么业务本身没有异常但是健康检查显示异常？
