直接看 error.log 中“upstream timed out while …”即可锁定对应超时参数：while connecting to upstream 对应 proxy_connect_timeout，while sending request to upstream 对应 proxy_send_timeout，while reading response header/from upstream 均触发 proxy_read_timeout；再结合 access.log 中 $request_time 与配置值比对，并依据 errno（如110为真超时、104为后端主动断连、111为连接被拒）精准定界。
直接看 error.log 里那句 “upstream timed out while …” 就能锁定具体是哪个超时参数在起作用。
看日志里的关键动词短语
每种超时对应固定的英文描述，Nginx 日志不会含糊：
-
while connecting to upstream → 触发的是
proxy_connect_timeout（建连阶段失败） -
while sending request to upstream → 触发的是
proxy_send_timeout（请求发不完） -
while reading response header from upstream → 触发的是
proxy_read_timeout（等不到响应头，最常见 504 场景） -
while reading response from upstream → 也是
proxy_read_timeout，但发生在收到响应头之后、读响应体过程中空闲超时（比如流式输出断太久）
结合 access.log 的 $request_time 验证是否真超限
error.log 告诉你“哪个环节超了”，access.log 告诉你“到底花了多久”：
- 找到 error.log 中报错行末尾的连接 ID（如
*12345） - 用这个 ID 在 access.log 里搜索，找对应行末尾的
$request_time值 - 如果该值 ≈ 你配置的
proxy_read_timeout（比如都是 60.002），基本可确认就是它卡住的 - 若
$request_time远小于配置值（如日志报超时但实际只耗时 2 秒），说明不是 Nginx 主动断的，可能是后端提前 close 或网络中断
注意 upstream 地址和 client IP 的指向意义
日志里 upstream: "http://10.20.30.40:8001/api" 不只是告诉你连谁，还能帮你判断问题范围：
- 如果所有报错都指向同一个 upstream 地址 → 单点后端异常或配置不一致
- 如果报错分散在多个 upstream 实例 → 更可能是共性配置过短，或上游服务整体负载高
- 配合
client: 192.168.10.55和request: "GET /export/data"，能快速聚焦到特定业务接口，避免泛泛排查
别漏掉 errno 编号
括号里的数字是系统级错误码，有明确含义：
-
(110: Connection timed out)→ 真正的超时，Nginx 等够了时间主动放弃 -
(104: Connection reset by peer)→ 后端先断的连接，常因后端自身 timeout 比 Nginx 还短 -
(111: Connection refused)→ 根本没服务在监听，proxy_connect_timeout都没机会生效
