Waiting是Nginx中处于空闲但可复用的keepalive连接数，反映HTTP/1.1长连接在两次请求间的休眠状态；其数量受keepalive_timeout、keepalive_requests及客户端行为共同影响，需结合QPS与资源水位合理调优。
“Waiting” 是 Nginx 状态监控中一个关键但容易被误解的指标，它直接反映当前处于空闲状态、但尚未关闭的 keepalive 连接数量。它不是卡住的请求，而是健康复用的“待命连接”——本质上就是 HTTP/1.1 长连接在两次请求之间的休眠态。
Waiting 连接从哪来？
当客户端发起请求并收到响应后，若满足以下全部条件，Nginx 就会把该 TCP 连接标记为 keepalive，并计入 Waiting 状态：
- 客户端请求头中
Connection: keep-alive（或 HTTP/1.1 默认行为） - Nginx 配置了非零的
keepalive_timeout（如keepalive_timeout 30s） - 响应已完整发送，且响应头中明确标明了 body 长度（
Content-Length）或使用了Transfer-Encoding: chunked - 连接未达到
keepalive_requests限制（例如设为 100，则第 101 次请求后强制断开）
Waiting 和 keepalive_timeout 的联动机制
keepalive_timeout 不是“连接总存活时间”，而是“最后一次数据收发后，最多等多久新请求”。Waiting 连接正是在这段倒计时中静默存在的实体：
- 每个 Waiting 连接都绑定一个独立的倒计时器，超时即关闭，从 Waiting 归零
- 只要客户端在超时前发来新请求，该连接就立刻退出 Waiting，进入 Reading → Writing 流程，计时器重置
- 若大量 Waiting 连接长期滞留（比如持续高于活跃请求数的 2–3 倍），往往说明
keepalive_timeout设得过长，或客户端实际不复用连接（如某些 App 请求后即休眠）
怎么看 Waiting 是否合理？
不能只看绝对值，要结合业务节奏和资源水位判断：
- 健康信号：Waiting 数量稳定波动、与 QPS 趋势正相关（例如 QPS 上升 → Waiting 先升后稳），说明连接复用顺畅
-
风险信号：Waiting 持续高位不降（如 > 5000 且无明显回落），同时
Active connections中 Waiting 占比超 70%，可能造成文件描述符耗尽或内存堆积 -
验证方法：用
ss -s | grep "TCP:"查看 ESTABLISHED 总数，再对比nginx_status中的 Waiting；若前者远大于后者，说明还有大量非 keepalive 连接（如短连接、WebSocket、长轮询）混在其中
优化 Waiting 的实操建议
目标不是消灭 Waiting，而是让它“该来时来，该走时走”：
- 对纯 API 服务（尤其移动端），将
keepalive_timeout从默认 65s 降至 10–15s，匹配 App 批量请求后休眠的行为 - 静态资源站可设为 20–30s，兼顾浏览器预加载和弱网重试
- 配合
keepalive_requests 100;（默认值），防止单连接无限承载，避免潜在内存泄漏累积 - 启用
reset_timedout_connection on;，让超时 Waiting 连接快速进入 TIME_WAIT 并释放，而非僵持在 ESTABLISHED
