upstream returned 5xx：服务端内部错误时用户能做什么
upstream returned 5xx严重程度 Medium目标服务器或它背后的上游服务出现内部错误，问题在服务端一侧。用户能做的主要是确认问题不在自己、记录准确的状态码与时间，然后等待或反馈；第一步是间隔几分钟重试，区分瞬时故障与持续故障。
结论
5xx 家族的语义很直白：服务器承认是自己的错。请求正确到达、格式没有问题，是服务端在处理时栽了跟头。因此这一页的基调与其他错误页不同——用户侧的"排查"更多是取证与确认，真正的修复发生在服务端。但取证并非可有可无：一份带着准确状态码和时间点的反馈，与一句"你们服务挂了"的价值差着数量级。
适用环境
- 全部平台
- 网站、API、订阅服务器的所有 5xx 场景
一分钟快速判断
先把 5xx 的四个常客分清，它们指向服务端的不同部位：
| 状态码 | 含义 | 服务端的哪里出了问题 |
|---|---|---|
| 500 | 内部错误 | 应用代码抛了异常 |
| 502 | 坏网关 | 反向代理连不上或读不懂后端 |
| 503 | 服务不可用 | 过载保护或主动维护中 |
| 504 | 网关超时 | 后端处理太慢，代理等不下去了 |
接着做两个动作：间隔 5 分钟重试一次（区分瞬时抖动与持续故障）；换一个网络出口重试一次（排除极小概率的"仅对你的出口 5xx"——某些风控会用 5xx 伪装拒绝）。
这条错误代表什么
现代服务几乎都是多层结构：CDN → 负载均衡 → 反向代理 → 应用 → 数据库/第三方依赖。5xx 是这条链上某一环的悲鸣被逐层传回：502/504 多产自代理层与应用层之间的裂缝（应用崩了、卡了、部署到一半），500 来自应用内部，503 则常常是主动的——过载熔断或发布窗口。理解分层的意义在于预期管理：502/503 在发布高峰期出现又迅速消失是很多服务的日常，而持续数小时的 500 意味着真正的故障。
ConnProof 如何判断
connproof subscription "https://目标地址"证据要点：具体状态码（500/502/503/504 分开记录，别笼统说"5xx"）、发生时间、DNS/TLS 层正常的佐证（说明你与服务器之间的路没问题）、响应体类型（CDN 的错误页 vs 空响应，能提示故障发生在哪一层——CDN 能返回精美错误页说明 CDN 自身健康，挂的是它身后的源站）。
最常见原因
- 源站服务崩溃、过载或发布中：最大宗；
- CDN 与源站之间回源失败：源站防火墙误拦 CDN 回源段、源站证书过期导致回源 TLS 失败；
- 反向代理配置错误：超时阈值过短（504 高发原因）、upstream 地址失效；
- 服务端依赖故障：数据库、缓存、第三方 API 拖垮应用。
用户侧步骤（全平台一致）
- 两次对照重试（隔 5 分钟 + 换出口）确认持续性与普遍性；
- 查服务方状态页或公告渠道——大范围故障通常已有通报，你的反馈重点就从"报告故障"变为"补充影响范围"；
- 向服务方提交三元组证据：具体状态码 + 精确时间（含时区）+ 你的出口地区。服务端日志检索靠这三个键；
- 等待。持续刷新的意义为零，还可能撞上限流。
服务维护者侧入口
从状态码倒推检查顺序：504 先查后端响应时间与代理超时配置的差距；502 查后端进程存活与 upstream 地址；500 直接进应用错误日志；503 确认是主动熔断还是容量不足。回源类问题用"绕过 CDN 直击源站"的对照检测切割责任段——源站直连正常而经 CDN 5xx，问题在回源链路（防火墙放行 CDN 回源地址段、核对回源协议与证书）。
间歇性 5xx 的取证方法
持续性的 5xx 好办——谁都能复现，服务方无从抵赖。真正折磨人的是间歇性 5xx：十次请求失败一次，你报障时它偏偏正常。这种情形的取证要靠时间序列而不是单次截图：在问题时段每隔几分钟运行一次检测（手动即可，不要写高频循环——那会撞上限流），把每次的状态码和时间记成一列。十几个数据点通常就能显出模式：失败集中在整分/整点（定时任务或发布窗口）、失败与流量高峰同步（容量不足）、或纯随机（某个后端实例不健康，负载均衡把你轮到它头上就失败）。带着这个序列去找服务方，对话会从"我们这边看不到异常"直接跳到"定位到那台实例了"。
如何区分本地问题和节点问题
| 证据 | 结论 |
|---|---|
| 换出口仍 5xx、他人也复现 | 服务端故障（等待/反馈） |
| 仅你的出口 5xx | 罕见的伪装拒绝，按 403 思路 处理 |
| 间歇出现于固定时段 | 服务端发布窗口或高峰过载 |
| DNS/TLS 层也异常 | 不是纯 5xx 问题，先修连接层 |
仍未解决时收集什么信息
- ConnProof 错误码（HTTP-003）与脱敏报告；
- 具体状态码序列与各自时间点；
- 两次对照重试的结果；
- 服务方状态页的当时截图或记录。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof subscription "https://目标地址" --format markdown --output http-report.md服务端修复后应恢复 2xx；若长期反复 5xx，把多次检测的时间序列一并提供给服务方，帮助定位周期性根因。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，确立"状态码三元组"反馈规范。