安全组未放行健康检查流量是后端实例被误判下线的常见原因，需确认100.64.0.0/10网段及健康检查端口协议是否在入方向规则中放行，并排查iptables/firewalld等主机防火墙拦截。

安全组未放行健康检查流量，是负载均衡后端实例被误判下线的常见原因。这类问题往往表现为：后端ECS在控制台显示“健康检查失败”，但手动访问服务正常；或NLB/SLB持续将流量切走，业务偶发503或连接拒绝。

确认健康检查来源IP是否被拦截

NLB健康检查使用的是其Local IP地址段，不是客户端IP，也不是SLB VIP。这个地址段由阿里云内部分配，无需也不应手动添加到安全组白名单——但前提是你的ECS没有额外启用iptables、firewalld或第三方主机防火墙。

• 登录ECS，执行iptables -L -n或systemctl status firewalld，检查是否存在主动拦截规则
• 若启用了iptables，确认是否屏蔽了NLB Local IP（如100.64.0.0/10网段），该网段用于健康探测，必须放行
• 企业级安全组默认拒绝所有出方向，若后端服务需主动回连NLB（极少数场景），也需配置对应出方向规则

验证安全组入方向规则是否覆盖健康检查端口与协议

健康检查使用的端口和协议，必须与你在NLB/SLB控制台配置的完全一致。例如：你配置了HTTP健康检查，目标端口8080，路径/health，那么安全组必须放行TCP 8080，而非仅放行80或443。

• 进入ECS实例详情页 → 安全组 → 查看入方向规则，确认存在类似“允许TCP 8080，授权对象为0.0.0.0/0或指定IP段”的条目
• 不要依赖“全通”规则（如0.0.0.0/0 + 全端口），应精确匹配业务端口，避免掩盖真实问题
• 若使用HTTPS健康检查，注意SSL握手阶段也可能因TLS版本、SNI等被中间设备拦截，此时需排查Nginx或应用层配置，而非仅看安全组

区分VPC内网与公网健康检查路径

即使ECS无公网IP，NLB仍可通过VPC内网发起健康检查。此时流量走的是内网路径，安全组规则对“内网+公网”同时生效——一条规则即可控制双向访问，无需分别配置。

• 检查安全组规则的“授权对象”字段：若填的是192.168.0.0/16等私网段，可能遗漏NLB Local IP；建议优先用0.0.0.0/0测试，确认后再收敛范围
• 若ECS部署在不同安全组，且需跨组通信（如管理节点调用业务节点健康接口），要确保双方安全组互相授权，不能只单向放开
• 普通安全组默认允许所有出方向，但企业级安全组默认拒绝出方向——若健康检查响应包被出方向规则拦截，也会导致超时

快速定位是否为安全组问题的三步验证法

不重启、不改配置，用最小动作判断问题根因：

• 本地模拟检查：在另一台同安全组的ECS上，执行curl -v http://[目标ECS内网IP]:8080/health，观察是否返回200及耗时。若失败，基本锁定网络或应用层；若成功，再对比NLB检查行为
• 临时放宽规则：新增一条入方向规则：TCP全部端口 + 授权对象0.0.0.0/0，保留5分钟。若健康状态立即恢复，说明原规则有遗漏
• 抓包确认来源：在目标ECS上运行tcpdump -i any port 8080 -nn -c 10，触发NLB健康检查，查看抓到的源IP是否属于100.64.0.0/10，并确认SYN包是否到达、是否有RST响应