waiting值持续偏高表明keepalive_timeout过长致连接积压，过低或频繁归零则说明超时过短引发重复建连；需结合业务场景设为15–75秒，并通过stub_status连续采样验证。
通过 stub_status 模块观察 Waiting 连接数，是调优 keepalive_timeout 的关键依据。Waiting 数值持续偏高，说明大量连接卡在 keepalive 状态未释放，可能拖慢新请求响应；过低或频繁归零，则可能意味着 timeout 设置过短，导致客户端反复重建连接，增加握手开销。
确认 stub_status 已启用并可访问
Nginx 需编译时包含 --with-http_stub_status_module（主流发行版默认开启），并在 server 或 location 块中配置：
- 添加
location /nginx-status { stub_status; allow 127.0.0.1; deny all; } - 确保该 location 不被其他 rewrite 或 proxy 规则拦截
- 用
curl http://127.0.0.1/nginx-status验证返回类似：
Active connections: 142
server accepts handled requests
12345 12345 67890
Reading: 2 Writing: 5 Waiting: 135
理解 Waiting 的真实含义
Waiting 是指：当前处于 keepalive 状态、已关闭请求 body、等待新请求复用的空闲连接数。它不等于“卡住的请求”，而是“可复用但尚未复用的连接”。重点关注：
- 持续 > 总并发连接数 30%（如 Active=200，Waiting=70+）→ keepalive_timeout 可能偏长，连接积压
- 频繁在 0–5 波动，且 Active 中 Reading/Writing 占比高 → timeout 可能过短，连接未等复用就断开
- Waiting 突增后缓慢下降 → 客户端突发复用请求，但服务端保持时间太长，资源未及时回收
结合业务特征设定 keepalive_timeout
不能只看单次 stub_status 输出，需在流量高峰时段连续采样（如每10秒抓一次，持续5分钟），再分析 Waiting 分布趋势：
- 纯 API 服务（客户端为 App/SDK，自带连接池）：建议 15–30 秒。这类客户端通常主动管理复用，过长 timeout 反而占内存
- 浏览器访问站点（含大量小图标、JS/CSS）：可设 60–75 秒。浏览器默认复用窗口约 60 秒，略留余量更匹配
- 反向代理后端（如 upstream 是 Node.js/Python）：timeout 应 ≤ 后端 keepalive 设置，否则 Nginx 连接还活着，后端已关闭，引发 RST
- 若日志中频繁出现
"client closed connection while waiting for request"，说明 timeout 太长，客户端已断开但 Nginx 还在等
验证调优效果的实操步骤
修改后不要立即全量上线，按以下顺序验证：
- 先在单台机器调整
keepalive_timeout 25s;（比原值降 5–10 秒） - 用
watch -n 5 'curl -s http://localhost/nginx-status | grep Waiting'观察 5 分钟 - 检查 error.log 是否新增
recv() failed (104: Connection reset by peer)—— 若明显增多，说明客户端来不及复用，需回调高 - 对比调优前后 QPS、平均延迟、TIME_WAIT 数量（
ss -s | grep "TCP:"）是否改善
