浏览 AI使用教程
线上报错先看浏览器、应用、代理还是上游
线上 502 可能来自浏览器到上游之间的任何一层。固定同一个请求，沿代理、应用和依赖保存时间线，才能避免多人同时改动把证据抹掉。
先比较关键条件，再作选择
把自己的条件代入判断项；没有证据的维度保留未知，不用印象替代结论。
所有人一起改以后错误消失了，根因反而更难找到
同一请求在代理等待响应时达到 30 秒，浏览器收到 504；应用日志随后才出现上游超时。要区分连接建立失败和连接已建立后迟迟未返回响应。
时间、请求 ID 和日志均为构造示例，未执行生产故障恢复。
- 同一 requestId 贯穿各层
- 每层状态和耗时可见
- 修复后从公开入口复测
已建立连接，随后等待响应头超时
教学日志
统一为 UTC 时间与 req-demo-39
14:05:00.000Z app request_start id=req-demo-39 path=/reports/7 14:05:00.010Z app vendor_request_start id=req-demo-39 timeout_ms=35000 14:05:30.001Z proxy id=req-demo-39 status=504 upstream_connect_time=0.002 request_time=30.001 14:05:30.001Z proxy upstream timed out while reading response header from upstream 14:05:35.015Z app vendor_timeout id=req-demo-39 elapsed_ms=35005
真实 Nginx error log 不一定包含业务请求 ID，需结合连接标识、时间、请求和 access log 关联；不能伪称每种默认日志格式天然携带 ID。
证据能支持到哪一步
| 证据 | 支持的判断 | 仍不能确认 |
|---|---|---|
| connect_time=0.002 且 app request_start | 该次代理到应用连接已建立 | 其它请求是否也成功 |
| while reading response header | 等待上游响应头阶段超时 | 为何应用迟迟没有首部 |
| 同一 ID 的 vendor_timeout | 应用也遇到依赖等待超时 | 网络、限流、服务处理还是应用超时设置所致 |
Nginx proxy_read_timeout 指相邻读取操作之间的超时，不是整个响应的总时长上限。参见 https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout 。
先把本例的条件、限制和目标摆出来
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | req-demo-39，GET /reports/7，代理上游连接耗时 0.002 秒，总耗时 30.001 秒；下方时间线为教学构造。 |
| 不能越过的边界 | 沿同一请求时间线检查浏览器、DNS/TLS、代理、应用和上游；一次只验证一个层；不以重启代替诊断。 |
| 要交付的结果 | 故障层级与请求时间线 |
线上服务报错排查，哪些条件会改变最后选择
| 判断条件 | 本例怎么核对 |
|---|---|
| 从用户现场开始 | 记录 URL、账号范围、步骤、时间、地区、浏览器、实际和预期，保留网络请求与响应。 |
| 确认边缘与代理 | 检查 DNS、证书、CDN、负载均衡和 Nginx 实际命中的配置、状态和上游目标。 |
| 检查应用 | 按请求 ID 查应用日志、版本、实例、异常和资源，区分错误响应与进程不可用。 |
| 检查数据和外部依赖 | 关联慢查询、锁、队列、缓存和上游响应，统一时区并识别超时是谁先触发。 |
| 用最小请求复测 | 在同一路径逐层旁路或替换，验证根因；任何生产变更先备份、校验和准备回滚。 |
线上服务报错排查：按本例条件得到的结论
故障层级与请求时间线
本例证据支持：代理已连上应用，在等待响应头时先达到读取超时；应用 35 秒后记录外部依赖超时。尚不能由这些日志断言外部依赖为何变慢，也不能把它写成连接应用超时。
边界变化后需要重新判断
若缺少某层日志，只能保留假设，不能用错误码直接宣布归因。
为什么“将 upstream timed out 一律理解成无法连接”还不能交付
将 upstream timed out 一律理解成无法连接
- 原因
- 忽略 while connecting 与 while reading response header 的阶段差异
- 怎么改
- 连同连接耗时、响应头耗时、应用接收记录一起判断