proxy_read_timeout是防上游“假死”的核心参数，应略大于上游p95/p99响应耗时（如p99为800ms则设2s），配合proxy_next_upstream error timeout http_504实现超时自动转发，并需与upstream keepalive、健康检查协同生效。
send_timeout 主要控制 Nginx 向客户端发送响应时的超时等待时间，它本身不直接管理上游连接或“僵尸连接”。真正影响上游无响应连接释放的是 proxy_read_timeout、proxy_send_timeout 和连接复用相关的 proxy_next_upstream 策略。若目标是及时切断僵死的上游连接、避免网关积压，需从上游通信生命周期入手，而非 send_timeout。
明确各 timeout 的作用边界
混淆 timeout 用途是调优失效的主因：
- send_timeout：仅作用于 Nginx → 客户端的数据发送阶段；若客户端接收慢或中断（如弱网、浏览器关闭），Nginx 等待该时长后关闭本侧连接。它对上游无任何控制力。
- proxy_send_timeout：Nginx → 上游服务器发送请求体（如 POST body）的超时。适用于大文件上传卡在发包阶段。
- proxy_read_timeout：Nginx 等待上游返回响应头/响应体的总空闲时间。这是防上游“假死”的核心参数——上游迟迟不发数据（哪怕已建立连接），超时即断连并触发重试或报错。
- proxy_connect_timeout：建立 TCP 连接阶段的超时，防上游根本不可达。
针对性设置 proxy_read_timeout 防止上游僵死
该值应略大于上游服务正常响应的 P95 或 P99 耗时，但不能过大（否则连接长期占位）：
- 若上游平均响应 200ms，P99 ≈ 800ms，建议设为 1.5–2s（如
proxy_read_timeout 2;）。 - 对强依赖型服务（如数据库代理、同步调用），可结合 proxy_next_upstream error timeout http_504，让超时后自动转发至健康节点。
- 禁用长连接滥用：加
proxy_http_version 1.1;+proxy_set_header Connection '';，但必须配合 upstream keepalive 合理配置（如keepalive 32;），避免连接池膨胀。
主动探测 + 快速失败组合策略
单靠 timeout 是被动防御。增强主动性可进一步净化环境：
- 启用
proxy_next_upstream_tries 2;和proxy_next_upstream_timeout 3s;，限制重试总耗时与次数，避免反复卡死。 - 在 upstream 块中配置
max_fails=2 fail_timeout=10s;，配合健康检查（如health_check interval=3 fails=2 passes=2;），快速摘除失联节点。 - 记录 slow logs：开启
log_format upstream_time '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_response_time $upstream_connect_time $upstream_header_time';，定位持续高 upstream_response_time 的上游实例。
验证与观测要点
调优后需确认是否生效：
- 用
nginx -t && nginx -s reload生效配置，避免 reload 失败导致旧配置残留。 - 通过
ss -tnp | grep :80 | grep CLOSE_WAIT或netstat -ant | grep :80 | grep TIME_WAIT观察连接状态分布，异常堆积多出现在 upstream 连接未及时释放时。 - 抓包验证：对某次超时请求执行
tcpdump -i any port upstream_port -w timeout.pcap，查看 Nginx 是否在 proxy_read_timeout 到期后发送 RST。
