AWS负载均衡器目标组EC2实例健康检查持续失败排查求助

一、网络与安全组连通性排查 #

• 确认EC2实例安全组是否放行目标组健康检查使用的端口入站流量：需允许负载均衡器所在VPC的CIDR范围或负载均衡器安全组的流量访问该端口，而非仅放行业务流量端口。
• 检查负载均衡器安全组是否允许出站至EC2实例健康检查端口的流量，避免负载均衡器无法发起健康检查请求。
• 在VPC内的测试实例（或通过EC2实例的私有IP）手动执行健康检查请求，验证连通性：

  curl http://<EC2私有IP>:<健康检查端口>/<健康检查路径>
  

  若请求失败，优先排查实例网络或服务本身问题。
• 核对EC2实例所在子网的路由表，确保存在通向负载均衡器子网的有效路由，无网络隔离情况。

二、目标组健康检查配置验证 #

• 核对健康检查路径是否与EC2实例上服务的实际健康端点匹配：例如服务的健康端点为/taskA/health，但目标组配置为/，会导致404错误。
• 确认健康检查的端口、协议与EC2实例上服务的监听配置一致：比如服务监听8080端口、HTTP协议，目标组却配置为80端口、HTTPS协议，必然导致检查失败。
• 检查健康检查的响应码规则：若服务返回的成功响应码（如204）未被目标组配置的允许响应码包含，会被判定为不健康。
• 确认健康检查的间隔、超时时间是否合理：若服务启动较慢，过短的检查间隔可能导致实例初始化阶段被误判为不健康，可适当调大间隔时间。

三、EC2实例服务状态排查 #

• 登录EC2实例，检查业务服务是否正常运行：

  # 以systemd管理的服务为例
  systemctl status your-service-name
  # 查看进程是否存在
  ps aux | grep your-service-process
  

• 查看服务日志（如Nginx的access.log/error.log、应用程序日志），确认是否收到健康检查请求，以及请求返回的具体错误（如404、500、连接拒绝等）。
• 检查EC2实例本地防火墙（如iptables、firewalld）是否拦截了健康检查端口的入站流量，即使安全组已放行，本地防火墙也可能存在限制。
• 查看EC2实例的资源使用率（CPU、内存、磁盘），若资源耗尽会导致服务无法响应请求，可通过top、free -m等命令排查。

四、负载均衡器与目标组关联验证 #

• 确认负载均衡器监听器的转发规则是否正确：检查/taskA/*路径是否正确关联至目标组，无优先级更高的冲突规则覆盖。
• 检查负载均衡器状态是否为active，确认其所在子网有可用IP、无配置错误导致的异常。
• 核对目标组中注册的EC2实例私有IP是否正确，避免误注册其他实例或IP填写错误。

五、HTTPS健康检查特殊排查（若适用） #

• 若目标组使用HTTPS健康检查，确认EC2实例的SSL证书是否有效、域名是否匹配，或是否在目标组配置中开启了“跳过证书验证”（针对自签证书场景）。

内容的提问来源于stack exchange，提问作者Joe Jones