负载均衡通过健康检查来判断后端服务的可用性，避免后端服务异常影响前端业务，从而提高业务整体可用性。
开启健康检查后，无论后端服务器权重是多少（包括权重为0），负载均衡实例都会进行健康检查。您可在实例列表页面的“健康状态”列查看健康检查状态，或者在监听器的绑定后端服务详情页面查看健康检查状态。
当后端服务器实例被判定为异常后，负载均衡实例自动将新的请求转发给其他正常的后端服务器，而不会转发到异常的后端服务器。
当异常实例恢复正常后，负载均衡将其恢复至负载均衡服务中，重新转发请求给此实例。
若健康检查探测到所有后端服务都有异常时，请求将会被转发给所有后端服务器。
关闭健康检查，负载均衡将向所有后端服务器转发流量（包括异常的后端服务器），因此强烈建议您打开健康检查，允许负载均衡帮您自动检查并移除异常的后端服务器。
默认被动健康检查，针对四层 TCP SSL 监听器、七层 HTTP/HTTPS 监听器，将默认配置被动健康检查能力（默认开启，不支持关闭）。CLB 向后端服务转发流量的同时并记录后端服务的健康状态。若转发失败则重试将流量转发至其他后端服务上，同时累计此后端服务失败次数1次，累计失败达到3次，则屏蔽该后端服务10秒，屏蔽时间结束后，恢复流量转发并继续记录后端服务的健康状态。
健康检查状态
根据健康检查探测情况，后端服务器的健康检查状态如下所示：
状态 | 说明 | 是否转发流量 |
探测中 | 新绑定的后端服务器在检查间隔 × 健康阈值时间内的状态，例如，检查间隔2s，健康阈值3次，则是6s内的状态。 | CLB 不向处于“探测中”的后端服务转发流量。 |
健康 | 后端服务正常 | CLB 向“健康”的后端服务转发流量。 |
异常 | 后端服务异常 | CLB 不向“异常”的后端服务转发流量。 在一个四层监听器或者七层 URL 规则下，如果 CLB 探测到所有后端服务都不健康，将会激活全死全活逻辑，即请求将会转发给所有后端服务。 |
已关闭 | 关闭健康检查 | CLB 向所有后端服务转发流量。 |
TCP 健康检查
针对四层 TCP 监听器，您可以配置 TCP 健康检查，通过 SYN 包即发起 TCP 三次握手来获取后端服务器的状态信息。您还可以通过自定义协议的请求内容和返回结果来获取后端服务器的状态信息。
1. 负载均衡向后端服务器（内网 IP 地址+健康检查端口）发送 SYN 连接请求报文。
2. 后端服务器收到 SYN 请求报文后，若相应端口处于正常监听状态，则会返回 SYN+ACK 响应报文。
3. 若在响应超时时间内，负载均衡收到后端服务器返回的 SYN+ACK 响应报文，则表示服务运行正常，判定健康检查成功，并向后端服务器发送 RST 复位报文中断 TCP 连接。
4. 若在响应超时时间内，负载均衡未收到后端服务器返回的 SYN+ACK 响应报文，则表示服务运行异常，判定健康检查失败，并向后端服务器发送 RST 复位报文中断 TCP 连接。
UDP 健康检查
针对四层 UDP 监听器，您可以配置 UDP 健康检查，通过
Ping命令和向健康检查端口发送 UDP 探测报文来获取健康状态。您还可以通过自定义协议的请求内容和返回结果来获取后端服务器的状态信息。
1. 负载均衡向后端服务器的内网 IP 地址发起
Ping命令；2. 负载均衡向后端服务器（内网 IP 地址+健康检查端口）发送 UDP 探测报文；
3. 若
Ping成功，且在响应超时时间内，后端服务器未返回port XX unreachable的报错信息，则表示服务正常，判定健康检查成功；4. 若
Ping失败，或者在响应超时时间内，系统收到后端服务器返回的port XX unreachable报错信息，则表示服务异常，判定健康检查失败；注意：
UDP 健康检查依赖 ICMP 协议，需要后端服务器开放回复 ICMP 包（支持
Ping）、开放回复 ICMP 端口不可达包（支持探测端口）；如果后端服务器是 Linux 服务器，在大并发场景下，由于 Linux 有防 ICMP 攻击保护机制，会限制服务器发送 ICMP 的速度。此时，即使后端服务已经出现异常，但由于无法向 CLB 返回
port XX unreachable，CLB 由于没收到 ICMP 应答进而判定健康检查成功，最终导致后端服务的真实状态与健康检查不一致。
解决方案：在配置 UDP 健康检查时，配置自定义输入和输出，向后端服务器发送您指定的字符串，且 CLB 收到您指定的应答后才判断健康检查成功。此方案依赖后端服务器，后端服务器需处理健康检查输入并返回指定输出。HTTP 健康检查
针对四层 TCP 监听器和七层 HTTP/HTTPS 监听器，您可以配置 HTTP 健康检查，通过发送 HTTP 请求来获取后端服务器的状态信息。
1. 负载均衡根据健康检查配置，向后端服务器（内网 IP 地址+健康检查端口+检查路径）发送 HTTP 请求（可选择设置检查域名）。
2. 后端服务器收到请求后返回相应的 HTTP 状态码。
3. 若在响应超时时间内，负载均衡收到了后端服务器返回的 HTTP 状态码，若与设置的 HTTP 状态码匹配成功，则判定健康检查成功，反之则判定健康检查失败。
4. 若在响应超时时间内，负载均衡未收到后端服务器的响应，则判定健康检查失败。
说明
针对七层 HTTPS 监听器，当 HTTPS 监听器的转发规则中的后端协议选择 HTTP 时，健康检查使用 HTTP 健康检查；当选择 HTTPS 时，健康检查使用 HTTPS 健康检查。
HTTPS 健康检查与 HTTP 健康检查 基本类似，不同的是 HTTPS 健康检查是通过发送 HTTPS 请求，根据返回的 HTTPS 状态码判断后端服务器的状态信息。
健康检查时间窗
负载均衡的健康检查机制有效提高了业务的可用性。为了避免频繁的健康检查失败引起的切换对系统可用性的冲击，健康检查只有在健康检查时间窗内连续多次检查成功或失败后，才会进行健康或异常的状态切换。健康检查时间窗由以下因素决定：
健康检查配置 | 说明 | 默认值 |
响应超时 | 健康检查响应的最大超时时间。 如果后端服务器在超时时间内没有正确响应，则判定为健康检查异常。 可配置范围：2 - 60秒。 | 2秒 |
检测间隔 | 负载均衡进行健康检查的时间间隔。 可配置范围：2 - 300秒。 | 5秒 |
不健康阈值 | 如果连续 n 次（n 为填写的数值）收到的健康检查结果失败，则识别为不健康，控制台显示为失败。 可配置范围：2 - 10次。 | 3次 |
健康阈值 | 如果连续 n 次（n 为填写的数值）收到的健康检查结果为成功，则识别为健康，控制台显示为成功。 可配置范围：2 - 10次。 | 3次 |
四层健康检查时间窗的计算方法如下：
说明：
响应超时时间要小于检查间隔时间。
四层健康检查，即 TCP 健康检查或 UDP 健康检查，无论检查成功还是响应超时，前后两次之间发包的检查间隔都是已设置的检查间隔。
健康检查失败时间窗 = 检查间隔 ×（不健康阈值 - 1）
下图以健康检查响应超时时间为2s，检查间隔为5s，不健康阈值为3次为例，健康检查失败时间窗 = 5 x（3-1）= 10s。
健康检查成功时间窗 = 检查间隔 ×（健康阈值 - 1）
下图以健康检查成功响应时间为1s，检查间隔为5s，健康阈值为3次为例，健康检查成功时间窗 = 5 x（3-1）= 10s。
七层健康检查时间窗的计算方法如下：
健康检查失败时间窗 = 响应超时时间 × 不健康阈值 + 检查间隔 ×（不健康阈值 - 1）
下图以健康检查响应超时时间为2s，检查间隔为5s，不健康阈值为3次为例，健康检查失败时间窗 = 2 x 3 + 5 x（3-1）= 16s。
健康检查成功时间窗 = 健康检查成功响应时间 × 健康阈值 + 检查间隔 ×（健康阈值 - 1）
下图以健康检查成功响应时间为1s，检查间隔为5s，健康阈值为3次为例，健康检查成功时间窗 = 1 x 3 + 5 x（3-1）= 13s。
健康检查探测标识
在 CLB 开启健康检查后，后端服务器除接收正常的业务请求外，还会接收到健康检查探测请求。健康检查探测请求有如下标识：
健康检查探测请求的源 IP 是 CLB 的 VIP 或100.64.0.0/10网段。
四层（TCP、UDP、TCP SSL）监听器的健康检查方式若为自定义，且检查请求为空，则默认请求中会带“HEALTH CHECK”标识。
七层（HTTP、HTTPS）监听器的健康检查请求 Header 中的 user-agent 为“clb-healthcheck”。
说明：
传统型内网负载均衡，健康检查源 IP 为
169.254.128.0/17 网段。基础网络内网负载均衡，健康检查源 IP 为服务器物理 IP。