前端显示“繁忙”，不等于后端容量不足。Codex 可以帮你整理链路，但先要给它能关联的材料。以下是虚构的教学日志，演示分析方法，不是本站或供应商故障记录。
先把时间与请求标识对齐
准备一个 logs/ 目录，把以下三段分别保存。时间均为 UTC 的 Z 格式；浏览器本地显示 18:00 时，在 UTC+8 对应 10:00。真实排查还要确认各机器时钟是否同步。
logs/client.log：
2026-10-11T10:00:00.000Z request_id=req-42 POST /api/report start
2026-10-11T10:00:30.011Z request_id=req-42 status=504 message="report unavailable"
2026-10-11T10:01:00.000Z request_id=req-43 POST /api/report start
2026-10-11T10:01:00.120Z request_id=req-43 status=200
logs/proxy.log：
2026-10-11T10:00:30.009Z request_id=req-42 status=504 upstream_connect_time=0.002 upstream_header_time=- request_time=30.009 error="upstream timed out while reading response header"
2026-10-11T10:01:00.118Z request_id=req-43 status=200 upstream_connect_time=0.002 upstream_header_time=0.115 request_time=0.118
logs/app.log：
2026-10-11T10:00:00.005Z request_id=req-42 report.start cache=miss
2026-10-11T10:00:00.006Z request_id=req-42 dependency.start service=analytics
2026-10-11T10:00:35.008Z request_id=req-42 dependency.end duration_ms=35002 result=ok
2026-10-11T10:00:35.010Z request_id=req-42 report.end status=200
2026-10-11T10:01:00.004Z request_id=req-43 report.start cache=hit
2026-10-11T10:01:00.114Z request_id=req-43 report.end status=200
日志在可读副本里分析。令牌、Cookie、完整请求正文和客户标识按需去除；保留请求 ID、时间、状态、耗时与处理阶段，才能关联证据。
让 Codex 先抽取，再解释
安装了 ripgrep 时，在练习目录运行：
rg -n --fixed-strings "request_id=req-42" logs
rg -n --fixed-strings "request_id=req-43" logs
这里固定字符串匹配，避免请求 ID 里的符号被当正则。真实日志很大时先按日期分片和故障前后时间窗缩小文件范围；本例只有九行应用/代理相关事件，不需要复杂查询系统。
把任务写成：
只读 logs 下的三个文件。分析 req-42，并以 req-43 为成功对照。
先列时间线，每项注明文件与行号；再列已证实事实、假设和下一项最小检查。
不能把没找到日志解释成请求必定没到达；不能直接改超时或重启服务。
对应样本应得出：
| 观察 | 可以确认 | 还不能确认 |
|---|---|---|
| 代理连接耗时 0.002 秒 | 该次上游连接建立很快 | 所有网络链路都正常 |
| 代理等待响应头约 30 秒后 504 | 客户端此时收到超时 | 30 秒由哪份配置生效，仍需读配置 |
| 应用同一 ID 的依赖花 35 秒 | 应用确实处理了 req-42，依赖很慢 | analytics 为什么慢，是查询、排队还是网络 |
| 应用最终记录 200 | 应用后来完成了处理 | 客户端收到 200；客户端实际上已收到 504 |
| req-43 缓存命中 | 对照请求走了不同分支且较快 | 缓存本身就是故障根因 |
这份证据支持继续检查缓存未命中的 analytics 调用及实际代理读取超时。它不支持把连接超时加大当成已确认修复，也不能从“两个请求挨得近”推出它们配置完全相同。
如果应用日志里没有 req-42
先查是否透传或重写请求 ID、日志是否采样、是否轮转到别的文件、实例是否找错、采集是否延迟，以及该路径是否实际记录日志。缺失也可能来自日志系统本身。
只有结合代理转发状态、上游地址、应用实例与采集完整性，才有条件缩小失败层。报告可写“当前应用日志未检出 req-42，需要核对关联字段与实例”，不能写“已经证明请求没到后端”。
下一步检查要对应一个假设
对本例，下一步是找 req-42 对应的依赖调用参数、查询耗时分布和同时间缓存未命中的其他请求；不要先让 Codex 改所有超时。若以后决定调整代理参数，需区分建立连接、读取响应与整个业务任务的时限。
保存本次提取命令、原文件位置、时间窗和结论表。修复后用相同业务输入复测，确认客户端收到的状态与应用最终状态一致。日志分析完成不等于生产问题已经修好。
资料来源
- Nginx proxy_read_timeout
核对超时参数含义；示例日志为脱敏教学数据。
下一步
继续阅读与你当前问题相关的教程：
