排查代理超时需聚焦Nginx三阶段主动断连：proxy_connect_timeout管TCP建连（内网3–5s），proxy_send_timeout管发请求空闲间隔（上传设60s），proxy_read_timeout管响应体两次数据包间隔（非总耗时，流式响应须匹配flush频率），并结合$upstream_response_time等日志字段精准定位断点。
排查代理超时导致的微服务调用链路中断，核心不是看“连没连上”，而是确认 Nginx 在哪一环主动切断了请求——是还没发出去？发出去但等不到响应头？还是收到一半就断了？关键得把 proxy 超时三阶段和上下游行为对齐。
盯住三个 proxy_timeout 阶段，别混用
每个参数管一段，错配就会在错误环节断链：
- proxy_connect_timeout：只管 TCP 连接建立（三次握手）。设太短（如 1s），内网偶尔抖动就报“connection refused”；设太长（如 30s），后端挂了你还傻等。内网建议 3–5s，跨可用区可到 8s。
- proxy_send_timeout：Nginx 把整个请求（含大 body）发给后端的总耗时上限，重点是“两次写之间的空闲”。上传文件或带大 JSON 的 POST，设 60s 更稳。
- proxy_read_timeout：最容易误判的项——它不是总响应时间，而是“收到响应体过程中，两次数据包之间的最大等待间隔”。后端用 chunked 流式输出，每 45 秒 flush 一次，你却只配了 30s，第二轮就 504。
验证后端是否真在流式响应
很多微服务（Spring Cloud Gateway、Go echo、Node.js Express 流式中间件）默认启用 Transfer-Encoding: chunked，但没控制好 flush 频率。直接 curl 后端接口，加 -v 观察：
- 响应头含 Transfer-Encoding: chunked 或缺失 Content-Length → 属于流式响应，必须确保后端有规律输出或显式 flush；
- 响应头有 Content-Length 且值合理 → 是整包返回，proxy_read_timeout 可按总耗时设（比如导出接口预计 200s，就设 210s）；
- curl 卡在 “* Connection #0 to host xxx left intact” 后无数据 → 很可能后端卡在逻辑里，没开始写响应。
检查 upstream 复用是否被中间设备干扰
启用了 keepalive，但链路中防火墙、云厂商 LB 或老版本后端不支持 HTTP/1.1 持久连接，会导致复用旧连接时出现 “Connection reset by peer” 或静默超时：
- upstream 块中明确配置：
keepalive 32; - 对应 location 中补全两行：
proxy_http_version 1.1;<br>proxy_set_header Connection '';
- 查后端 access 日志或 error 日志，高频出现 “broken pipe”、“client closed connection before response completed” 就是复用失败的典型信号。
用日志字段快速定位断点位置
确保 Nginx access log 包含这几个关键字段，出问题时一眼看出在哪断的：
- $upstream_response_time：后端实际耗时。如果接近或等于 proxy_read_timeout，说明后端慢是主因；如果为 “-” 或极小（0.001s），说明请求压根没发出去，可能卡在 rewrite、limit_req 或 SSL 握手；
- $request_time 与 $upstream_response_time 差值大 → Nginx 自身处理重（如 Lua 脚本、大量正则匹配）；
- $upstream_addr 为空或显示 “none” → 请求没进 upstream 模块，检查 deny、auth_basic、SSL 配置是否拦截了该路径。
