亚马逊云绑卡账号 为什么 ALB 报 502 Bad Gateway？后端 EC2/Target Group 响应异常诊断

ALB 报 502 Bad Gateway，先别急着换负载均衡

遇到 ALB 报 502 Bad Gateway，大多数情况下不是“ALB 坏了”，而是后端 EC2、Target Group、应用进程或网络链路里有一环不正常。排查时最容易走偏的地方，是一上来就重建负载均衡，而忽略了目标实例实际返回了什么、健康检查是否真的覆盖了业务接口、以及安全组和端口是否对齐。

如果你要快速判断问题方向，先看三件事：Target Health 状态、后端应用日志、ALB 访问日志。这三处基本能把 80% 以上的排查方向定下来。

亚马逊云绑卡账号 经验上，502 和 503 很多人会混在一起看。ALB 502 更偏向“后端返回异常或连接异常”，而不是简单的“没有后端实例”。

为什么 ALB 报 502 Bad Gateway：常见根因先分成四类

1. 后端应用返回了不符合预期的响应

这是最常见的一类。比如 EC2 上的 Nginx、Apache、Node.js、Java、Go 服务在收到请求后：

• 直接断开连接
• 返回了格式不完整的 HTTP 响应
• 响应头过大或格式错误
• 上游应用抛异常后没有正确输出

这类问题经常发生在刚发布新版本之后，尤其是改了反向代理、改了端口、改了证书链、改了响应头处理逻辑的时候。

2. 端口、协议或 TLS 配置不匹配

Target Group 监听的协议和端口，必须和后端服务实际监听一致。常见错误包括：

• Target Group 配成 HTTP:80，后端实际监听 8080
• 亚马逊云绑卡账号 ALB 走 HTTPS，后端却只支持 HTTP
• 后端要求 HTTPS，但证书或 SNI 配置不完整
• 应用只允许特定 Host Header，ALB 转发后不匹配

亚马逊云绑卡账号 这类问题通常表现为：健康检查偶尔通过，但业务请求仍然 502，或者只有某些路径、某些域名报错。

3. 安全组、NACL 或路由导致连接被挡住

ALB 能把请求转发给 Target，不代表后端一定收得到。实际部署里，经常出现以下情况：

• EC2 安全组没有放行来自 ALB 安全组的入站流量
• NACL 把回包所需的临时端口挡住
• 实例路由表或子网配置有误
• 只允许了公网访问，没允许内网 ALB 访问

如果后端日志里完全看不到请求，优先怀疑网络放行问题，而不是应用逻辑。

4. 后端资源耗尽或处理超时

很多 502 不是配置错，而是后端在高峰期扛不住了。常见表现：

• CPU 持续高位，进程响应变慢
• 内存不足，服务被系统杀掉
• 文件句柄、连接数、线程池耗尽
• 数据库慢查询拖死接口，最终上游超时

这种情况在活动页、登录页、支付回调、批量查询接口上特别常见。看起来像 ALB 报错，实际上是后端已经来不及正常返回。

亚马逊云绑卡账号 排查顺序：先定位是“连不上”还是“返回坏了”

1. 先看 Target Group 的健康状态
   不要只看“Healthy/Unhealthy”，还要看失败原因。很多时候原因里已经写了是超时、连接失败、响应码不对，还是协议问题。
2. 从 ALB 所在网络环境直接 curl 后端
   用同样的协议、端口、路径访问后端实例，确认是不是能拿到完整响应。尽量模拟 ALB 实际转发的 Host Header 和路径。
3. 检查应用日志和反向代理日志
   如果后端根本没有请求记录，重点查安全组、NACL、端口和路由；如果有请求但返回异常，重点查应用本身。
4. 核对健康检查配置
   健康检查路径、返回码、超时、成功阈值、检查端口，最好都和业务真实接口接近。只拿一个“/health”放行，不代表业务接口一定正常。
5. 看 ALB 访问日志
   关注 target_status_code、elb_status_code、target_processing_time。它们能帮助判断是 ALB 层拒绝、目标层异常，还是超时。

一张表看懂：502 常见症状、原因和处理方式

几个最容易忽略的配置点

• Target Group 的协议和端口：不要只看目标实例“能不能访问”，要看它是不是在 ALB 预期的端口上稳定监听。
• 健康检查的成功码：有些应用返回 301、302、204、403，不一定是坏，但可能被你配置成失败。
• ALB idle timeout：后端处理太慢、连接保持时间太长时，可能在业务还没返回前就被切断。
• 反向代理层：如果 EC2 上还有 Nginx、Envoy、Apache，ALB 看到的是代理响应，不是最终应用响应，问题会多一层。
• 后端 Keep-Alive：连接复用配置不稳时，会出现一部分请求正常、一部分请求 502 的情况。

按业务场景判断，能少走很多弯路

场景一：刚发布完就出现 502

亚马逊云绑卡账号 先别怀疑 ALB。优先回看发布内容：端口、环境变量、证书、启动脚本、容器或守护进程是否变更。很多团队在发布时只改了服务监听端口，却忘了同步修改 Target Group 或反向代理配置。

场景二：访问量一上来就报错

这种通常是后端资源被打满了。常见不是“请求太多”本身，而是慢查询、外部依赖超时、线程池耗尽、连接池不足。先看应用和数据库，再看 ALB。

场景三：只有海外用户或某个区域用户报 502

如果你做的是海外业务部署，要特别留意跨区访问、DNS 解析、链路延迟和安全策略。部分用户看到的 502，实际是上游链路超时，而不是应用本身错误。

场景四：扩容了实例，502 还在

这通常说明问题不在“机器数量”，而在“新实例没有正确加入 Target Group”或“新实例虽然加入了，但应用还没真正可用”。看实例健康状态只是第一步，还要确认端口、进程和依赖都已经 ready。

如果你还在做账号购买、实名认证、企业认证，先把这些前置条件理顺

有些团队在国际云上排查 502 时，实际上还卡在账号开通或资源申请阶段。比如：

• 账号购买后没有完成实名认证，部分资源申请会受限
• 企业认证没过，额度、配额或某些区域资源开通不完整
• 充值续费没及时处理，实例或负载均衡相关资源被限制
• 支付方式被风控审核拦住，导致临时扩容、补充实例或新建 Target Group 失败

这些情况不会直接制造 502，但会让你在“想修复”的时候，发现资源根本没法按计划调整。尤其在海外部署和临时扩容场景里，先确认账号、支付和资源配额是否正常，再谈流量切换，会更稳。

常见错误：很多人不是不会查，而是查错方向

• 只看 ALB 控制台，不看后端日志
• 只改健康检查路径，不查真实业务接口
• 把 502 当成“实例不健康”，其实是应用返回格式异常
• 一看到错误就重建 ALB，结果把问题隐藏得更深
• 发布后没做灰度，出问题只能全量回滚

什么时候该考虑重建 Target Group 或重配 ALB

不是每个 502 都需要重建资源。一般只有在下面这些情况，才考虑重建或重配：

• Target Group 规则长期混乱，历史配置很多，已经无法确认哪项生效
• 健康检查和转发规则被多次改动，排查成本高于重建成本
• 协议、端口、证书、监听规则全部不一致，且没有清晰变更记录

如果只是单次异常，建议先修应用和网络配置，不要一上来就推倒重来。对业务来说，重建资源往往比定位问题更慢，也更容易带来额外成本。

FAQ

Q1：健康检查是正常的，为什么还是 502？

A：因为健康检查只证明某个路径能通，不代表所有业务路径都正常。很多应用会把 /health 做得很轻，但真实接口还依赖数据库、缓存、第三方接口，仍然可能报 502。

Q2：502 和 503 怎么区分排查？

A：502 更像是“后端返回异常或连接异常”，503 更像是“没有可用目标或服务暂时不可用”。如果 Target Group 全部 unhealthy，先看 503；如果有 healthy 目标但仍报错，优先看 502。

Q3：ALB 报 502，先查 EC2 还是先查 Target Group？

A：先查 Target Group 的健康原因，再查 EC2 上的服务日志。健康原因能快速告诉你是连不上、超时，还是返回码不对。

Q4：能不能只靠重启 EC2 解决？

A：短期能恢复不代表问题消失。重启能掩盖进程挂掉、内存泄漏、连接池耗尽等问题，但如果不修根因，过一段时间还会再来。

决策建议：先按这个顺序处理

1. 确认是否是单个路径、单个域名，还是全站都 502
2. 查看 Target Group 健康状态和失败原因
3. 直接从内网访问 EC2 服务，确认协议、端口、返回内容
4. 核对安全组、NACL、路由和监听配置
5. 查看应用日志、系统资源和数据库依赖
6. 如果是发布后问题，优先回滚或灰度切换

按这个顺序处理，基本不会把时间浪费在无关项上。对大多数 ALB 502 场景来说，真正的关键不是“哪里报错”，而是“后端为什么没有按 ALB 预期返回”。把这点查清楚，问题通常就能落到具体配置、具体进程或具体依赖上。