代理IP 502 Bad Gateway怎么排查？用四组对照定位网关与上游

使用代理IP访问已获授权的接口时，502 Bad Gateway 最让人困惑的一点是：客户端已经收到了 HTTP 响应，却不代表请求真正到达并完成了目标业务。它通常说明某个网关从下一跳拿到无效响应，但返回 502 的设备可能是本地反向代理、代理服务入口，也可能是目标站前置网关。直接换 IP 或无限重试，很容易掩盖根因并放大故障。

本文给出一套可复现的代理IP 502 Bad Gateway排查方法。它只适用于自有系统、公开允许访问的页面或已获授权接口。遇到 401、403、429、验证码或明确拒绝时，应先核对权限与服务规则，不应通过轮换出口规避限制。

先确认“谁”返回了 502

502 是链路中的网关响应，不等于某一方已经被自动定责。先为一次失败请求保留脱敏证据：发生时间、任务编号、目标域名类别、代理资源别名、入口地区、请求方法、状态码、响应头摘要、响应体特征、总耗时与重试序号。不要记录完整代理连接串、密码、Token、Cookie、验证码或个人信息。

重点看三类线索：响应头中的服务标识是否与自有网关一致；错误页版式是否来自目标站；失败是否集中在某个代理入口。标识只能作为线索，不能单独下结论，因为中间设备可能删除或改写响应头。

如果连 HTTP 响应都没有，而是 DNS、TCP、TLS 或客户端超时，就不应计入 502。可以先按代理IP异常响应码占比统计方法把传输失败、HTTP 异常和业务异常分开，避免把不同问题混成一个故障率。

用四组对照快速缩小范围

保持相同时间窗口、请求方法、请求体和超时设置，依次做以下对照。测试目标应是团队自有健康端点或明确允许访问的轻量接口。

对照一次只改一个变量，并保留原始计数。例如“资源 A 20 次出现 12 次 502，资源 B 20 次为 0 次”，比“偶尔失败”更有诊断价值。样本过小时先观察，不要立即执行全局切换。

按请求阶段检查配置

第一阶段是客户端到代理入口。核对代理协议、主机、端口、鉴权方式和白名单是否与当前订单一致。HTTP 代理访问 HTTPS 目标时通常需要先建立 CONNECT 隧道；如果把 HTTP 入口误当成 HTTPS 代理，或反过来，可能在握手阶段失败。需要复现命令时，可参考curl代理HTTPS访问的分段排查方法，同时保存 curl -v 输出中的阶段信息，但必须先脱敏。

第二阶段是代理出口到目标上游。检查目标域名解析是否正常、SNI 与 Host 是否匹配、目标端口是否开放，以及失败是否只发生在某个地区或运营商线路。若自有健康端点也在同一资源上持续 502，可暂停该资源进入生产池并提交时间窗、入口和脱敏请求编号给服务支持。

第三阶段是目标站内部。若多个代理资源和直连都在同一时间返回相似 502，更可能是目标网关无法从应用服务获得有效响应。此时应查看自有目标的负载均衡、反向代理和应用日志，检查进程重启、连接被提前关闭、上游响应格式异常或超时边界不一致。

重试前先设预算

502 可能是瞬时故障，但并不意味着所有请求都适合自动重试。只对幂等请求或有幂等键保护的操作进行有限重试；采用指数退避和随机抖动；把首次请求与重试请求分别统计；设置单任务、单目标和全局重试上限。POST、下单、扣费等操作如果无法确认服务端是否已执行，应先查业务结果，不能盲目重放。

还要避免“502 就换 IP”的单一路径。若故障来自目标上游，频繁切换只会制造更多连接并放大压力。请求节奏和上限可以结合代理IP请求频率控制方法统一管理。

用恢复证据关闭故障

修复后应在相同目标、地区、请求版本和并发下复测，并确认三项指标连续多个窗口恢复：502 原始计数和占比回到基线，P95 耗时不再恶化，业务内容断言通过。随后逐级放量，而不是一次恢复全部任务。

一条完整记录至少包含“首次发现—四组对照—定位层级—处置动作—恢复证据”。代理IP 502 Bad Gateway排查的核心不是快速换出口，而是找出哪个网关、哪一段链路、在哪种条件下拿到了无效上游响应。需要核对代理产品接入方式时，可查看悟空代理官网公开说明，并以当前订单和接口文档为准。