ALB-NLB-ALB三层路由架构间歇性返回502错误的排查咨询

核心现象锚定 #

先基于已知信息排除非故障点，缩小排查范围：

• 流量经R53直连ALB2无502，排除后端Fargate应用、ALB2本身的业务配置、证书配置问题
• ALB2访问日志、后端应用日志均无对应502记录，NLB存在大量Target reset计数，说明故障发生在NLB到ALB2的TCP传输层，请求根本没到达ALB2的HTTPS处理层
• 502响应由ALB1返回，本质是ALB1尝试向下游转发请求时，收到TCP重置包或连接建立失败触发的Bad Gateway报错

第一优先级排查（覆盖90%同场景故障） #

• NLB目标组配置校验
  • 确认挂载ALB2的NLB目标组类型为instance类型，直接关联ALB2对应的托管弹性网卡实例，禁止手动填写ALB2的单个私有IP作为目标：ALB是多可用区分布式部署，节点IP会随平台维护动态变更，手动填IP会出现流量打到已下线节点、漏发流量到其他可用区ALB节点的问题，触发连接重置。
  • 确认NLB目标组的客户端地址保留开关为关闭状态：ALB作为托管负载均衡不支持该模式，开启后NLB会用用户原始公网IP作为源IP发流量给ALB2，ALB2回包不会经过NLB直接发往公网，导致TCP三次握手失败直接回RST，且不会生成ALB2访问日志，是该架构下最高发的配置错误。
  • 调整NLB目标组健康检查规则：将默认的TCP健康检查替换为HTTPS协议检查，路径使用ALB默认健康检查路径，合理设置健康检查阈值。TCP健康检查仅能探测端口存活，无法识别ALB节点TLS协商失败、服务临时不可用的状态，会导致流量被转发到无法正常处理请求的节点上。
• ALB2安全组配置校验
  • 确认ALB2绑定的安全组入方向规则，放通NLB所属所有子网的私有网段443端口访问，不要仅放通NLB的公网/服务IP：NLB转发流量时会使用所在子网的临时源IP发起请求，漏配对应网段会出现随机连接被安全组拦截、返回RST的问题。
  • 临时测试可先将ALB2安全组443入方向临时放通0.0.0.0/0，如果测试期间502、Target reset计数消失，可直接定位为安全组放通范围问题，再逐步收窄放通网段即可。
  • 检查安全组是否配置了连接数、新建连接数限流规则，突增流量触发限流时也会直接返回RST包。

第二优先级排查（链路适配问题） #

• ALB1到NLB的目标组配置校验
  • 确认ALB1挂载NLB的目标组为ip类型，固定填写NLB的静态公网/私有IP，不要通过NLB域名动态解析填写IP，避免NLB节点IP变更时出现无效连接。
  • 调整ALB1侧目标组的闲置连接超时时间：将该值设置为比NLB侧TCP会话超时时间小10-15秒（比如NLB默认TCP超时是350秒，就把ALB1侧超时设为330-340秒），避免NLB提前断开空闲连接后，ALB1复用已失效连接发请求触发RST。
  • 关闭ALB1到NLB目标组的慢启动配置，避免流量分发倾斜导致单ALB2节点连接数突增触发限流。
• TLS配置适配校验
  如果ALB1到NLB、NLB到ALB2配置了HTTPS转发，确认三层的TLS协议版本、加密套件策略匹配，避免出现TLS协商失败触发连接重置的问题。建议简化链路：ALB1到NLB、NLB到ALB2均使用TCP四层透传，TLS解密全放在ALB2层处理，减少多层TLS协商的异常点。

快速调试方法 #

• 在和ALB1、NLB同可用区的跳板机上，直接向NLB的443端口发起持续压测请求，同时在跳板机、ALB2侧弹性网卡上抓包，定位RST包的发送源，可直接判断是安全组拦截、路由错误还是目标节点不可达。
• 查看ALB1的访问日志，筛选502响应对应的target_processing_time字段，如果该值小于10毫秒，即可确认请求未到达下游应用层，是TCP连接阶段触发的重置，和上述配置类问题特征完全匹配。

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