浏览 AI 知识库
线上报错先看浏览器、应用、代理还是上游
线上 502 可能来自浏览器到上游之间的任何一层。固定同一个请求，沿代理、应用和依赖保存时间线，才能避免多人同时改动把证据抹掉。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
所有人一起改以后错误消失了，根因反而更难找到
用户看到 502，前端团队改请求，运维重启 Nginx，后端更换上游地址。多个层同时变化后错误暂时消失，却无法知道根因。
- 同一 requestId 贯穿各层
- 每层状态和耗时可见
- 修复后从公开入口复测
同一个 502 先按请求 ID 找第一处异常
| 层 | 证据 | 可能结论 | 下一步 |
|---|---|---|---|
| 浏览器 | URL、时间、响应和网络请求 | 用户确实命中目标路径 | 继续查边缘 |
| 代理 | server/location、上游地址和状态 | 代理命中错误 upstream | 核对配置和健康 |
| 应用 | 请求 ID、版本、异常和资源 | 应用返回 500 或未收到请求 | 区分应用和代理 |
| 数据/上游 | 慢查询、队列、第三方状态 | 下游超时或限流 | 做最小请求和安全缓解 |
状态和日志必须统一时间与请求 ID；最后一层错误不自动等于根因。
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 14:05 公开 URL 返回 502；浏览器 requestId、代理 access/error log、应用日志和上游状态均可查。 |
| 不能越过的边界 | 沿同一请求时间线检查浏览器、DNS/TLS、代理、应用和上游；一次只验证一个层；不以重启代替诊断。 |
| 要交付的结果 | 故障层级与请求时间线 |
线上服务报错排查，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 |
|---|---|
| 从用户现场开始 | 记录 URL、账号范围、步骤、时间、地区、浏览器、实际和预期，保留网络请求与响应。 |
| 确认边缘与代理 | 检查 DNS、证书、CDN、负载均衡和 Nginx 实际命中的配置、状态和上游目标。 |
| 检查应用 | 按请求 ID 查应用日志、版本、实例、异常和资源，区分错误响应与进程不可用。 |
| 检查数据和外部依赖 | 关联慢查询、锁、队列、缓存和上游响应，统一时区并识别超时是谁先触发。 |
| 用最小请求复测 | 在同一路径逐层旁路或替换，验证根因；任何生产变更先备份、校验和准备回滚。 |
线上服务报错排查：按本例条件得到的结论
故障层级与请求时间线
时间线显示浏览器到代理成功，代理连接应用超时，应用日志又显示等待上游 30 秒；根因在上游超时而非前端。临时降级后原 URL 恢复，requestId 跨层对齐。
边界变化后需要重新判断
若缺少某层日志，只能保留假设，不能用错误码直接宣布归因。
为什么“找到最慢一层，却没解释为什么”还不能交付
找到最慢一层，却没解释为什么
- 原因
- 时间线只有结果，没有最近变更和依赖状态
- 怎么改
- 补部署、配置和上游事件，复现后验证因果而非相关