负载均衡器Target Group实例健康检查异常排查求助

一、先核对健康检查核心配置 #

• 确认目标组健康检查的协议、端口、路径和实例上运行的服务完全匹配。比如实例服务跑在8080端口的HTTP，健康检查设成80端口HTTPS的话，肯定会失败。
• 直接在实例内部用命令验证健康路径的返回：比如curl -I http://localhost:8080/health，看返回的状态码是否在目标组设置的健康范围内（一般是200-399）。

二、检查实例自身服务状态 #

• 登录实例，先确认服务是否活着：用systemctl status your-service（Systemd系统）或者ps aux | grep your-service看进程是否存在。
• 拉取服务日志排查：比如tail -f /var/log/your-service.log，看有没有启动失败、端口被占或者请求处理报错的情况。

三、深挖网络层面问题（别只盯入站规则） #

• 检查实例安全组的出站规则：健康检查是负载均衡发请求到实例，实例得能把响应发回去，所以要允许向负载均衡IP段返回流量，或者先开全出站权限测试。
• 排查实例本地防火墙：比如iptables、firewalld，确认有没有拦截健康检查端口的流量。可以用iptables -L -n看规则，或者临时关防火墙试试能不能恢复健康。
• 在实例上抓包验证连通性：用tcpdump port 8080（换成你的健康检查端口），看是否收到负载均衡的请求，以及实例有没有发响应。

四、验证目标组高级配置 #

• 检查健康检查的超时、间隔、重试次数：如果实例服务响应慢，超时设太短会误判，比如把超时从2秒改成5秒试试。
• 确认实例所在可用区是否被添加到目标组：要是实例的可用区不在目标组覆盖范围内，健康检查也会失败。
• 查看负载均衡的健康检查日志：大部分云厂商会提供详细日志，里面会明确标失败原因，比如连接超时、状态码不对。

五、其他潜在问题 #

• 检查实例资源使用率：CPU、内存跑满会导致服务没法响应健康请求，用top或者htop看看资源占用情况。
• 排查健康路径的依赖：如果健康检查路径依赖数据库、缓存这些后端服务，后端挂了也会导致返回异常状态码。

内容的提问来源于stack exchange，提问作者sai harinadh