AWS NLB所有流量仅转发至单个目标的原因及排查修复方案

你已经排除了健康检查异常、跨可用区负载均衡未开启两个常见问题，剩余常见诱因及对应修复方案如下：

• 诱因1：四层转发哈希规则+长连接/源端五元组离散度不足
  NLB默认基于源IP、源端口、目标IP、目标端口、协议五元组做一致性哈希转发，只要单条流的五元组不发生变化，流量会持续转发到首次哈希命中的后端实例。如果业务普遍使用长连接（如数据库连接、TCP长连接复用、MQ持久连接），或者访问流量全部来自单NAT出口的固定公网IP、源端口范围被限制，就会出现所有流量持续落到单台实例的现象。
  修复方案：
  1. 短连接业务检查客户端连接池配置，调小空闲连接超时、最大连接生命周期参数，定期重建连接触发重新选路
  2. 强依赖长连接的业务，可评估切换为七层ALB实现请求维度的负载均衡，或在业务客户端侧做主动负载分担
  3. 单NAT出口场景可评估增加出口公网IP数量、扩大源端口可用范围，提升五元组离散度
  4. 检查目标组的负载均衡算法配置，若当前配置为流哈希且选择了源IP二元组/三元组哈希策略，可调整为五元组哈希，提升流量离散度
• 诱因2：目标组内实例权重配置错误
  NLB目标组支持为每个注册目标单独设置0-999范围的转发权重，若其中一台实例权重被误设为0（健康检查正常也不会接收流量），或两台实例权重差异过大（如一台100、一台1），流量规模较小时就会出现全量流量落到高权重实例的情况。
  修复方案：
  进入EC2控制台目标组详情页，在「目标」栏检查两台EC2的权重配置，将两台实例权重调整为相同值（默认值为1），等待1-2分钟配置生效后再观察流量分布。
• 诱因3：监听器开启源IP会话保持，且访问源单一
  NLB的TCP、TLS、UDP监听器支持源IP维度的会话保持，开启后同一源IP的所有流量会固定转发到同一台后端实例。如果验证负载均衡效果时用的是单个固定出口IP（如办公网出口、单台测试机）发起请求，自然会出现所有流量落到单台实例的现象。
  修复方案：
  1. 检查对应监听器配置，若业务无强会话保持需求，直接关闭源IP粘性功能即可
  2. 必须开启会话保持的场景，验证负载均衡效果时需要使用多个不同源IP的客户端发起请求，才能观测到多实例的流量分布。
• 诱因4：后端实例侧拦截流量或应用未正常监听，造成无流量的假象
  NLB健康检查流量来自平台预留的健康检查专属网段，和实际转发的业务流量源地址（开启客户端IP透传时为真实客户端IP，未开启时为NLB内部服务IP）存在差异。如果其中一台EC2的安全组、操作系统防火墙（iptables/firewalld/Windows防火墙）仅放通了健康检查网段，未放通业务流量源段，或是实例上的业务应用仅监听127.0.0.1回环地址、未监听0.0.0.0的业务端口，就会出现健康检查显示正常，但业务流量实际被拦截、应用无法接收处理的情况，从业务监控看就像完全没有流量转发到该实例。
  修复方案：
  1. 检查两台EC2关联的安全组入站规则，确认放通NLB监听的业务端口，源段覆盖实际业务访问地址范围
  2. 登录实例检查本机防火墙规则，确认无对应业务端口的拦截策略
  3. 检查业务应用的监听配置，确认绑定到0.0.0.0而非本地回环地址，可通过netstat -tulpn、ss -tulpn命令验证端口监听状态
  4. 可在两台EC2上对业务端口抓包，确认是否有流量到达网卡，定位流量丢弃的具体节点。
• 诱因5：测试流量规模过小，未达到四层负载均衡的离散阈值
  NLB是流级别四层负载均衡，不是七层请求级别的轮询分发，当总活跃TCP/UDP流数量极低（如仅个位数连接）时，受一致性哈希的概率分布影响，所有流全部命中单台后端属于正常现象，不代表负载均衡功能异常。
  修复方案：
  使用多源IP、高并发压测工具生成至少数百条不同五元组的独立连接，再观察两台实例的流量指标，正常情况下流量会按配置的权重比例均匀分发。

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