超时类故障典型现象为访问变慢、连接重置（502/504）、后端无请求日志或nginx报“upstream timed out”等；定位需自客户端→nginx→上游逐层检查超时参数梯度，重点验证proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout及proxy_next_upstream_timeout是否合理协同，避免短超时卡长请求或长超时拖垮连接池。
超时类故障的典型现象与定位思路
用户访问突然变慢、连接被重置（502 Bad Gateway、504 Gateway Timeout）、后端服务日志无请求记录，或 Nginx error log 中频繁出现 "upstream timed out"、"no live upstreams" 等错误，基本可判定为超时配置失配或链路阻塞。排查要从 客户端→Nginx→上游服务 三层超时参数是否形成合理梯度入手，避免“短超时卡长请求”或“长超时拖垮连接池”。
关键超时参数含义与推荐配比
Nginx 反向代理涉及 4 个核心超时指令，必须按执行顺序和作用域理解：
- proxy_connect_timeout：Nginx 与上游建立 TCP 连接的上限时间（不含 TLS 握手）。默认 60s，生产建议设为 3–5s。过长会导致连接池被慢建连占满。
- proxy_send_timeout：Nginx 向上游发送完整请求（含 body）的总耗时上限。适用于大文件上传或流式请求，一般设为 30–60s，需略大于后端最长单次写操作预期。
- proxy_read_timeout：Nginx 等待上游返回响应头（及后续数据）的间隔超时。注意：它是两次读操作之间的空闲等待时间，不是整个响应耗时。对长轮询/流式接口，常设为 180–300s；普通 API 建议 60s。
- proxy_next_upstream_timeout（配合 proxy_next_upstream_tries）：当某台上游失败后，尝试切换其他节点的总时间窗口。必须 ≤ proxy_read_timeout，否则重试逻辑失效。例如设为 10s / 3 tries，表示 10 秒内最多换 3 次节点。
上下游超时协同与常见陷阱
超时不是孤立参数，必须与上游服务（如 Spring Boot、Node.js、Go HTTP Server）及客户端（浏览器、App SDK）对齐：
- 后端应用的 read/write timeout 必须 > Nginx 的 proxy_read_timeout 和 proxy_send_timeout，否则 Nginx 还没等到响应，后端已主动断连。
- 若上游是 Kubernetes Service + Pod，还需检查 service 的 connection timeout（如 kube-proxy iptables 模式默认 15min，IPVS 模式可配置）及 Pod 就绪探针（readinessProbe）超时 是否小于 Nginx connect timeout，否则健康检查失败导致流量打到未就绪实例。
- 客户端侧：浏览器默认连接空闲超时约 5–6 分钟，若 Nginx proxy_read_timeout 设为 300s（5min），而客户端在 4:50 断开，Nginx 无法感知，可能继续等待至超时才报 504——此时应结合 keepalive_timeout 和 client_header_timeout 控制客户端连接生命周期。
快速验证与动态调试方法
不重启即可验证超时行为：
- 用 curl -v 模拟请求，关注 time_namelookup / time_connect / time_starttransfer 各阶段耗时，判断卡点在 DNS、建连还是响应等待。
- 临时在 location 块中添加 proxy_set_header X-Request-Start "t=${msec}";，再在后端打印接收时间，反推 Nginx 转发延迟。
- 开启 error_log /var/log/nginx/error.log debug;（仅限排查时），可看到 “*1000 upstream timeout (110: Connection timed out) while connecting to upstream” 等精确错误上下文，包括 worker 进程 ID、upstream 名称、socket 状态。
- 使用 nginx -t && nginx -s reload 热更新配置后，通过 ss -tan | grep :80 | wc -l 观察 ESTABLISHED 连接数变化，确认连接复用或堆积是否符合预期。
