使用迁移向导创建的NLB健康检查失败，求教配置方法

我来帮你梳理下排查方向和针对性的配置建议，结合你已经做的操作，咱们一步步来定位问题：

• 先确认健康检查核心规则是否匹配实例状态
  很多时候健康检查失败的根源不是安全组，而是检查规则本身和实例实际情况不匹配：

  • 先在目标实例上执行命令 netstat -tulpn | grep 7443，确认7443端口确实处于监听状态，并且对应的服务正常运行。
  • 核对NLB目标组的健康检查配置：你用的是Custom TCP检查，那要确保健康检查的端口就是7443，超时、间隔阈值是否合理（比如默认2秒超时如果你的服务响应慢，可以适当调大到3-5秒）。

• 修正安全组配置的合理性（避免手动加IP的坑）
  你手动添加NLB IP到实例安全组的方式存在隐患——NLB的ENI IP是动态变化的（比如扩容、AZ调度时都会更新），所以这种方式不可持续，而且可能已经遗漏了部分IP：

  • 更可靠的做法是：在目标实例的安全组入站规则中，选择NLB对应的前缀列表（Prefix List）——AWS会自动为每个NLB生成包含其所有ENI IP的前缀列表，选择它就能自动适配IP变化。
  • 另外要确认实例安全组的出站规则：因为健康检查的应答包需要从实例返回给NLB，出站规则要允许TCP协议的应答流量（一般默认允许所有出站，如果自定义了规则，要确保放开1024-65535端口的TCP出站，因为NLB的请求源端口是这个范围）。

• 排查网络层面的其他阻碍

  • 检查目标实例所在子网的网络ACL（NACL）：NACL是无状态的，所以要同时配置入站允许TCP 7443，出站允许TCP 1024-65535（对应NLB请求的源端口范围），否则会阻断流量。
  • 用AWS的VPC可达性分析器：创建一个分析任务，从NLB的ENI到目标实例的7443端口，工具会自动检测路由表、安全组、NACL等环节的阻塞点，快速定位问题。

• 验证目标组的配置细节

  • 确认目标组的端口映射：NLB的监听端口是否正确映射到了实例的7443端口？如果映射端口错误，健康检查肯定无法通过。
  • 检查目标实例在目标组中的状态：有没有被手动标记为“不健康”？如果有，先重置状态再观察。

• 辅助排查的小技巧

  • 查看NLB的CloudWatch指标：重点看HealthyHostCount、UnHealthyHostCount和TargetResponseTime，如果TargetResponseTime很高，说明实例响应慢；如果没有流量到达，那就是网络阻塞。
  • 在目标实例上抓包验证：执行tcpdump port 7443，观察是否有来自NLB IP的连接请求。如果没有请求，说明网络层（安全组/NACL/路由）有问题；如果有请求但无响应，说明实例上的服务未正常监听或处理请求。

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