Nginx代理超时调优需分场景协同设定：内网直连设proxy_connect_timeout为3–5秒，跨可用区按location分级配置proxy_read_timeout，高并发短连接采用keepalive_timeout 15s与keepalive_requests 10000反向配合。
Linux 下 Nginx 代理超时参数调优不是“改几个数字就完事”，而是要结合网络环境、后端响应特性与故障恢复节奏来协同设定。调得过紧，健康服务被误踢；调得过松，故障节点拖累整条链路。下面从三个真实可复现的典型场景切入，讲清楚怎么设、为什么这么设、效果差多少。
内网直连场景：proxy_connect_timeout 设为 3～5 秒最稳妥
同机房、同 VPC、甚至同一台宿主机跑 Docker 的前后端，RTT 通常低于 1ms，三次握手耗时稳定在 2～3ms。此时若保留默认 60 秒，一个后端进程卡死（比如 JVM full GC 暂停），Nginx 会傻等一分钟才放弃连接，期间新请求持续堆积，连接池迅速打满。
实测对比（压测工具 wrk，并发 2000，后端人为 kill -STOP 模拟卡顿）：
- proxy_connect_timeout 60s → 平均首字节时间（TTFB）飙升至 58.2s，错误率 37%
- proxy_connect_timeout 5s → TTFB 稳定在 4.8s，错误率降至 2.1%，且流量自动切到其他健康节点
建议搭配 upstream 主动健康检查：interval=10s，fail=2，这样 10 秒内连续两次 connect 失败即摘除，15 秒内完成故障识别与隔离。
跨可用区或混合云：proxy_read_timeout 需分层设置
当 Nginx 在北京集群、后端在杭州集群，网络抖动和长尾延迟明显上升。这时不能一刀切地把 proxy_read_timeout 全设成 30s——API 接口可能只要 200ms，但文件导出接口天然需要 20s。统一设高，小接口白白等待；统一设低，大任务直接被中断。
推荐按 location 分级控制：
- /api/v1/user/ → proxy_read_timeout 2s；proxy_send_timeout 1s
- /api/v1/report/export → proxy_read_timeout 45s；proxy_send_timeout 30s
- /static/ → 不走 proxy_pass，直接本地 serve，无超时压力
某金融后台实测：分级后，95% 小接口 P99 从 3.1s 降至 0.24s；导出类任务失败率从 18% 降至 0.7%，且未引发上游重试风暴。
高并发短连接场景：keepalive_timeout 与 keepalive_requests 要反向配合
移动端 App 或小程序大量短连接请求（每个用户每秒发起 3～5 次 API），若 keepalive_timeout 过长（如 75s），Nginx 会维持大量空闲连接，占用 worker_connections 和内存；但若设太短（如 5s），客户端又频繁重连，加重三次握手开销。
关键技巧是“短保活 + 高请求数”组合：
- keepalive_timeout 15s；keepalive_requests 10000
- 同时 upstream 块中启用 keepalive 32（连接池大小）
这样既避免连接长期空占，又让单个 TCP 连接尽可能多承载请求。某资讯类 App 上线后对比：并发连接数下降 42%，QPS 提升 28%，error_log 中 “upstream prematurely closed connection” 类报错归零。
