云负载均衡器健康检查失败时，负载均衡器可能把后端服务器标记为不健康，减少或停止向它转发请求。定位时不要先改阈值：按“端口是否可达、探测请求是否匹配、响应是否合格”的顺序检查。下面这组云负载均衡器健康检查失败的排查步骤适用于常见的四层和七层负载均衡场景，具体字段名称以所用云平台为准。
第1步：核对监听器与后端端口
先确认负载均衡器监听的前端协议、端口，以及后端服务器组配置的协议和端口。它们不一定相同：例如，客户端通过 HTTPS 访问 443 端口，负载均衡器可以将请求转发到后端的 HTTP 8080 端口；但健康检查通常使用服务器组中单独配置的端口，也可能使用业务端口。
- 在控制台查看监听器、转发规则和后端服务器组，记录协议与端口。
- 登录一台后端服务器，确认应用确实在目标端口监听；Linux 环境可用系统自带的端口查看工具检查。
- 在服务器本机访问服务，例如运行 curl -i http://127.0.0.1:8080/healthz，确认连接成功并查看响应状态。
本机访问成功只说明应用本地可用，不代表负载均衡器能从网络侧探测到它，继续检查安全策略和路由。
第2步：检查探测源地址的网络权限
健康检查请求来自云平台的探测节点，不一定使用客户端地址。检查后端安全组、主机防火墙、网络访问控制规则及路由，确认允许探测流量到达后端端口，并且返回路径可用。不同云平台的探测源地址和放行方式可能不同，不要直接套用其他平台的地址范围，应查当前平台关于健康检查来源的说明。
如果规则只允许办公网或应用调用方访问，业务请求可能正常，而探测仍被丢弃。查看防火墙拒绝日志或网络流日志，并确认规则作用于实际后端网卡和子网。
第3步：匹配协议、路径与请求条件
七层检查要核实 HTTP 或 HTTPS、请求路径、Host 请求头，以及平台是否支持设置查询参数或 SNI。应用可能只在指定域名下提供健康接口；探测若使用默认 Host，便可能落入错误虚拟主机。HTTPS 后端还需确认监听端口、证书和 TLS 配置符合平台要求。
四层检查关注 TCP 连接能否建立，不会验证网页内容或业务逻辑。因此，TCP 检查成功而 HTTP 检查失败，常见原因是路径、请求头或应用响应不符合预期。可为探测准备轻量、稳定的健康接口，避免依赖登录、外部数据库或耗时任务。
第4步：核对状态码、超时与检查阈值
查看健康检查的成功状态码范围、单次超时、检查间隔，以及连续失败或成功多少次才改变状态。HTTP 检查若只接受 200，而接口实际返回 204 或重定向，就可能被判失败；允许的状态码因平台配置而异，应以控制台设置为准。响应过慢也会在业务最终完成前触发超时。
不要仅为让状态变绿而无限放宽超时或接受所有状态码。先在后端直接复现同一协议和路径，观察状态码与响应时间；再按应用正常耗时和平台允许范围调整阈值。修改后等待足够的检查周期，并查看状态变化时间。
第5步：结合后端日志确认服务状态
对照健康检查失败时间检查应用访问日志、系统日志和资源指标，确认请求是否到达、由哪个进程处理，以及是否出现重启、连接耗尽或资源不足。若日志完全没有探测请求，优先回到网络权限、端口和路由；若请求已到达但返回错误，则检查应用路由、虚拟主机和依赖服务。
一次排查只改一个变量，并记录修改前后的健康状态。确认问题原因后，再检查同一服务器组中的其他后端是否存在相同配置差异。这样能避免把暂时恢复误判为根因已解决。以上云负载均衡器健康检查失败的排查步骤，重点是让探测链路与后端实际服务配置逐项对应。
常见问题
本机健康接口正常，为什么检查仍失败？
本机测试没有经过探测网络。继续核对探测源地址的放行规则、后端端口、路由及返回路径。
业务请求正常，但后端显示不健康怎么办？
业务流量与健康检查可能使用不同端口、协议或 Host。按控制台中的检查配置复现请求，并查后端日志。
应该选择 TCP 还是 HTTP 检查？
只需确认端口可连接时可考虑 TCP；还要确认应用能提供有效响应时，HTTP 检查信息更多，但需要正确配置路径和状态码。
调整检查间隔后多久会恢复？
通常需经过连续成功次数对应的多个检查周期；实际时长还受超时设置、调度延迟和平台实现影响，应以控制台状态为准。