- 1. 健康检查的原理是什么?
- 2. 推荐的健康检查配置是什么?
- 3. 是否可以关闭健康检查?
- 4. TCP监听如何选择健康检查方式?
- 5. ECS实例权重设置为零对健康检查有什么影响?
- 6. HTTP监听向后端ECS实例执行健康检查使用的方法是什么?
- 7. HTTP监听向后端ECS实例执行健康检查的IP地址是什么?
- 8. 为什么健康检查监控频率与web日志记录不一致?
- 9. 健康检查是否会消耗系统资源?
- 10. 负载均衡因后端数据库故障导致健康检查失败,如何处理?
- 11. 负载均衡服务TCP端口健康检查成功,为什么在后端业务日志中出现网络连接异常信息?
- 12. 为什么业务本身没有异常但是健康检查显示异常?
1. 健康检查的原理是什么?
负载均衡通过健康检查来探测后端ECS实例的可用性。开启健康检查功能后,当后端某个ECS实例健康检查出现异常时,来自客户端的新请求将不会再被转发到该ECS实例,直到该ECS实例恢复正常。
如下图所示,负载均衡健康检查使用的地址段是100.64.0.0/10,后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略,但如有配置iptables等安全策略,请务必放行(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。
更多详细信息,请参见健康检查概述。

2. 推荐的健康检查配置是什么?
为了避免频繁的健康检查失败引起的切换对系统可用性的冲击,健康检查只有在健康检查时间窗内连续多次检查成功或失败后,才会进行状态切换。更多详细信息,请参见配置健康检查。
以下是TCP/HTTP/HTTPS监听建议使用的健康检查配置。
配置 | 推荐值 |
---|---|
响应超时时间 | 5秒 |
健康检查间隔 | 2秒 |
不健康阈值 | 3 |
以下是UDP监听建议使用的健康检查配置。
配置 | 推荐值 |
---|---|
响应超时时间 | 10秒 |
健康检查间隔 | 5秒 |
不健康阈值 | 3 |
健康阈值 | 3 |
3. 是否可以关闭健康检查?
您只可能关闭HTTP和HTTPS监听的健康检查,不能关闭TCP和UDP监听的健康检查。具体操作,请参见关闭健康检查。
4. TCP监听如何选择健康检查方式?
TCP监听支持HTTP和TCP两种健康检查方式:
- TCP协议健康检查通过发送SYN握手报文,检测服务器端口是否存活。
- HTTP协议健康检查通过发送HEAD或GET请求,模拟浏览器的访问行为来检查服务器应用是否健康。
TCP健康检查方式对服务器的性能资源消耗相对要少一些。如果您对后端服务器的负载高度敏感,则选择TCP健康检查;如果负载不是很高,则选择HTTP健康检查。
5. ECS实例权重设置为零对健康检查有什么影响?
该状态下,负载均衡不会再将流量转发给该ECS实例,监听的后端服务器健康检查不会显示异常。
将负载均衡后端ECS实例的权重置为零,相当于将该ECS实例移出负载均衡。一般是在ECS实例进行重启和配置调整等主动运维时将其权重设置为零。
6. HTTP监听向后端ECS实例执行健康检查使用的方法是什么?
HEAD方法。
curl -v -0 -I -H "Host:" -X HEAD http://IP:port
7. HTTP监听向后端ECS实例执行健康检查的IP地址是什么?
负载均衡健康检查使用的地址段是100.64.0.0/10(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)。如果后端ECS实例启用了iptables等访问控制,需要在内网网卡对100.64.0.0/10(100.64.0.0/10 是阿里云保留地址,其他用户无法分配到该网段内,不会存在安全风险)做访问放行。
8. 为什么健康检查监控频率与web日志记录不一致?
负载均衡健康检查服务也是集群方式的,这样可以避免单点故障。负载均衡的代理分布到很多节点上,因此看到的健康检查日志访问频率和控制台设置的频率不一致,这是正常现象。
9. 健康检查是否会消耗系统资源?
HTTP模式的健康检查对后端ECS实例的资源消耗不大。
10. 负载均衡因后端数据库故障导致健康检查失败,如何处理?
问题现象:
ECS实例内配置了两个网站,www.test.com是静态网站,app.test.com是动态网站,都配置了负载均衡。后端数据库服务异常,导致访问www.test.com静态网站出现502错误。
问题原因:
负载均衡健康检查配置的检查域名是app.test.com,RDS或者自建数据库故障导致app.test.com访问异常,所以健康检查失败。
解决方案:
将负载均衡健康检查域名配置为www.test.com即可。
11. 负载均衡服务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地址段的相关请求做日志过滤,忽略相关错误信息。
12. 为什么业务本身没有异常但是健康检查显示异常?
问题现象:
curl -I
得到的状态码是正常的。 echo -e ‘HEAD /test.html HTTP/1.0\r\n\r\n’ | nc -t 192.168.0.1 80
问题原因:
如果返回的状态与控制台配置的正常状态码不一致,则判定健康检查异常。如果您配置的正常状态码为http_2xx,则所有返回的非HTTP 2xx状态码均被认为是健康检查失败。
Tengine/Nginx配置会发现curl没有问题,但是echo测试会匹配到默认站点,导致测试文件test.html返回404错误,如下图所示。

解决方案:
- 修改主配置文件,将默认站点注释掉。
- 在健康检查配置中添加检查域名。
在文档使用中是否遇到以下问题
更多建议
匿名提交