502、503、504 怎么查？代理连接与网站网关排障

使用代理时看到 502、503 或 504，先确认报错发生在建立代理连接时，还是目标网页返回响应时，再决定查哪一段。仅凭这三个数字，不能认定机场节点失效，也不能直接证明网站本身已经恢复或停止服务。

作者：小六｜资料核对日期：2026年10月28日

本文适合浏览网页、上传文件或调用接口时遇到 HTTP 错误的情况。浏览器自己的连接失败提示、客户端日志和网站返回的状态，需要分别记录。

三个状态码，分别在说什么？

定义见 RFC 9110 的服务端错误说明。这里的“上游”，可以理解为这一层网关为完成请求而联系的后端服务，不一定就是你正在使用的机场节点。

因此，先用状态码缩小范围，再结合请求和日志定位。看到 504 就立即更换套餐，通常缺少足够的判断依据。

网页可能先加载首页，再请求登录、文件列表或其他接口。首页能打开，不能证明后面的接口也正常；页面上显示一段“502”文字，也需要与实际 HTTP 状态区分。

在浏览器开发者工具的 Network（网络）面板中，找到操作时失败的请求，记录目标域名、路径、状态、发生时间及必要的响应说明。如果没有收到 HTTP 响应，就保留原始连接错误，不要自行给它补一个状态码。

响应头里的服务名称、错误页样式或请求编号可以作为线索，但单个标识不足以锁定故障归属。向维护者反馈时，时间和请求编号往往有助于对照日志，私人查询参数则应遮住。

使用 HTTP 代理访问 HTTPS 目标时，应用可以先通过 CONNECT 请求建立隧道，再进行后续通信。流程见 MDN 的 CONNECT 说明。

如果日志明确写着 CONNECT 阶段返回 502，应先核对实际使用的代理入口、隧道阶段日志和到目标的连接路径。此时不能把那个 502 直接当作目标网页的正常响应。

如果已经取得目标请求的 HTTP 响应，再出现网站网关错误，则应结合该请求的地址和网站支持信息继续查。单凭两种情况都写着“代理”，不能把本机客户端与网站反向代理当成同一个服务。

这一判断仅适用于相应的 HTTP 代理流程。若日志返回的是 407，可以另看本站代理认证检查方法，不要把认证问题按网关超时处理。

保持同一应用、同一目标和相近时间，每次只改变一个条件，并核对实际出口。

这些结果提供调查方向，不是故障归属的最终证明。一次恢复也不能说明其他节点永久不可用，不必为了比较而重复发送大量请求。

Retry-After 告诉客户端再次请求前应等待多久，可以写成等待秒数，也可以写成 HTTP 日期，格式见 MDN 的字段说明。

例如，Retry-After: 120 表示收到响应后等待 120 秒再试。这只是格式示例，不是某个网站的恢复承诺。等待结束后仍需检查实际结果；没有这个字段，也不适合连续刷新。

网关停止等待，并不能证明后端没有完成工作。微软的 5xx 错误处理说明提醒，重复提交某些 POST 请求可能造成重复操作。

普通使用者可以先查看文件列表、任务状态或提交记录，再按网站提供的恢复方式处理。自己编写调用程序时，应遵循接口的重复提交约定，而不是为所有错误统一开启无限重试。

如果上传稳定返回的是 413，则需要改查大小限制，相关步骤见大文件上传错误排查。如果请求已经返回 200，之后实时内容中断，也应按流式传输检查方法核对，不能仅凭停住就把它记成 504。

第三方网站的网关和后端设置，需要由网站维护者结合日志确认。你可以提供时间、目标、状态码、请求编号及少量对照结果；修改客户端的等待时间，不能保证改变远端网关的限制。

若错误发生在自己管理的代理入口，则保留该阶段日志继续调查。分享前去掉 Cookie、认证字段、完整订阅链接和私人内容。

想交流 502、503、504 的判读，可以带上报错阶段、实际状态和脱敏后的对照记录：Telegram 联系我