API 报错 502 Bad Gateway？区分网络抖动与服务端崩溃的排查逻辑

在调用第三方 AI 接口或自家后端服务时，502 Bad Gateway 是常见且令人困惑的错误。它通常意味着网关或代理服务器无法从上游服务器获取有效响应。对于普通开发者或网站运营者而言，区分是“网络抖动”还是“服务端崩溃”是解决问题的关键第一步，这直接决定了后续是重试请求还是检查代码。 首先，检查请求的响应时间。如果请求在几毫秒内立即返回 502，通常问

在调用第三方 AI 接口或自家后端服务时，502 Bad Gateway 是常见且令人困惑的错误。它通常意味着网关或代理服务器无法从上游服务器获取有效响应。对于普通开发者或网站运营者而言，区分是“网络抖动”还是“服务端崩溃”是解决问题的关键第一步，这直接决定了后续是重试请求还是检查代码。

首先，检查请求的响应时间。如果请求在几毫秒内立即返回 502，通常问题出在网关层或负载均衡器，而非上游业务逻辑。此时应重点检查网关配置，确认上游服务器地址、端口是否正确，以及防火墙是否拦截了内部通信。若响应时间较长（如超过 30 秒）后返回 502，则极可能是上游服务处理超时。此时需查看上游服务的日志，确认是否因数据库查询缓慢、死锁或资源耗尽导致进程挂起。注意，不要仅凭耗时短就断定未进入业务逻辑，需结合网关日志中的“upstream status”字段确认。

其次，排查网络连接状态。使用 curl 或 telnet 直接访问上游服务的 IP 和端口，测试连通性。如果连接被拒绝，检查上游服务进程是否存活；如果连接成功但无响应，检查是否存在端口被其他进程占用或网络防火墙策略变更。在云环境中，还需确认安全组规则是否允许网关子网访问上游子网。这一步能排除大部分因网络配置错误导致的假性 502 错误。

最后，分析上游服务的资源状态。查看服务器监控面板，关注 CPU、内存和磁盘 I/O 使用率。若内存使用率接近 100%，检查是否发生 OOM（Out of Memory）Kill，具体可查看系统日志中的 dmesg 或进程退出码。若 CPU 持续高负载，检查是否有异常循环或未优化的代码逻辑。对于 AI 接口，还需确认模型加载状态，若显存不足，服务可能无法初始化，导致网关收不到有效握手信号。

适用边界：本方法适用于基于 HTTP 协议的 API 调试及 Web 服务故障排查。对于 WebSocket 长连接或 gRPC 协议，502 的表现形式可能不同，需参考具体协议文档。建议建立自动化监控，当 502 错误率超过 1% 时触发告警，以便及时介入。