从ALB切换至NLB后目标组健康检查失败的排查求助

我来帮你梳理下问题的核心和解决方案——从ALB切换到NLB后健康检查失败，本质是两者在健康检查流量来源和安全组模型上的关键差异导致的，咱们一步步来解决：

核心差异：NLB vs ALB的健康检查流量来源 #

首先得明确一个关键区别：

• ALB的健康检查流量是从ALB所在VPC的内网CIDR范围发起的，所以你之前用VPC安全组或者VPC CIDR作为源就能匹配到流量；
• NLB工作在四层（TCP/UDP），它的健康检查流量是从AWS管理的NLB节点IP发起的——这些IP不在你的VPC CIDR范围内，也不属于你创建的任何安全组，这就是你设置VPC安全组作为源没生效的原因！

正确的安全组配置方法（无需开放任意访问） #

要让NLB的健康检查流量通过，同时限制仅内部+NLB访问，你需要用**NLB专属的前缀列表（Managed Prefix List）**来配置EC2安全组的入站规则：

1. 找到你的NLB对应的前缀列表

   • 登录EC2控制台，进入「前缀列表」页面；
   • 搜索你的NLB名称，AWS会为每个NLB自动生成一个前缀列表，里面包含了该NLB所有节点的IP范围；
   • 或者在配置安全组入站规则时，直接选择「源」为「前缀列表」，然后搜索你的NLB名称即可找到。

2. 配置EC2安全组入站规则
   添加两条入站规则（根据你的需求调整）：

   • 第一条（NLB流量）：协议TCP，端口80，源选择上述NLB的前缀列表——这会允许NLB的健康检查流量和业务流量访问EC2的80端口；
   • 第二条（内部访问）：协议TCP，端口80，源设置为你的VPC CIDR范围（比如10.0.0.0/16）或者内部实例的安全组——这会限制只有VPC内的资源才能访问EC2，实现你要的「仅内部访问」需求。

额外的NLB健康检查注意事项 #

除了安全组，还要确认目标组的健康检查配置：

• NLB的TCP健康检查只验证端口是否能建立TCP连接，不需要配置HTTP路径（和ALB的七层健康检查不同）；
• 检查目标组的「健康检查端口」是否设为80，「协议」是否为TCP，和EC2实例的监听配置一致；
• 如果你的EC2实例上的应用需要特定的TCP握手行为，确保没有防火墙或iptables规则阻止NLB的连接。

这样配置后，既解决了NLB的健康检查问题，又严格限制了访问范围，不需要开放任意地址的TCP流量。

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