502 Bad Gateway可能由NAT网关SNAT端口耗尽引发，表现为后端服务能接收请求但无法出站连接，需通过监控指标、网关日志和现象对比确认；缓解措施包括调低TCP空闲超时、关闭非必要连接、启用连接复用；根本解决需扩容NAT IP、分片部署、使用Private Link或内网直连。
当NAT网关因SNAT端口耗尽，导致后端服务无法建立出站连接（如调用依赖API、数据库、第三方服务等），上游网关（如Nginx、ALB或API网关）在尝试转发请求时连接失败或超时，就会返回502 Bad Gateway。这不是后端应用本身挂了，而是它“连不出去”，从而无法完成业务逻辑——网关收不到有效响应，只能报502。
确认是否为SNAT端口耗尽引发的502
不能仅凭502就断定是NAT问题，需交叉验证：
- 检查NAT网关监控指标：重点关注SNAT连接总数（是否持续接近上限）、丢弃的数据包数（是否有突增）、Port Exhausted计数（华为/阿里云等厂商日志中直接出现该关键词）；
- 查看网关错误日志：Nginx error.log中若频繁出现 "connect() failed (113: No route to host)" 或 "Connection refused"，且目标地址是内网服务（如Redis、内部HTTP服务），大概率是SNAT出口不通；
- 对比现象：同一时刻，部分实例报502，其他正常；重启后短暂恢复，几小时后复现；后端服务自身CPU、内存、进程数均正常——这些是典型端口耗尽特征。
快速缓解：释放和优化SNAT资源
不改架构也能立竿见影：
- 调低TCP空闲超时：将NAT网关或后端VM的TCP idle timeout设为4分钟（最低允许值），避免长连接长期占用端口；
- 检查并关闭非必要出站连接：如应用中未关闭的HTTP Client连接池、未配置超时的gRPC长连接、轮询式健康检查等；
- 启用连接复用：确保后端服务使用HTTP Keep-Alive，并合理设置max_connections与keepalive_timeout；
- 对高频短连接场景（如微服务间调用），改用异步轮询或消息队列，减少同步阻塞型SNAT占用。
根本解决：扩容与架构优化
长期稳定需从设计层面入手：
- 为NAT网关增加公网IP：每个IP提供64,512个SNAT端口，最多可绑16个IP，总端口池可扩展至百万级；
- 按流量分片部署NAT网关：将不同业务子网绑定独立NAT网关，避免单点端口争抢；
- 对Azure/AWS等云平台，优先使用Private Link或VPC Endpoint访问PaaS服务（如Azure Storage、AWS S3），绕过SNAT；
- 关键服务直连：数据库、缓存等核心依赖，尽量通过内网直连，而非经NAT出口再走公网或对等连接。
规避误判：区分502的真实责任方
502常被误归咎于后端代码，但端口耗尽时：
- 后端日志可能无错误，甚至显示“请求已接收”，但它在尝试发起下游HTTP请求时卡住，最终超时或抛异常；
- Nginx日志里upstream prematurely closed connection往往比"connection refused"更常见，说明后端已启动连接但未完成；
- 务必查清502发生前的“最后一跳”：是连数据库失败？调认证服务超时？还是发邮件SDK卡住？定位到具体出站目标，才能确认是否NAT路径问题。
