要让Nginx的keepalive真正提升集群健康度，必须配置HTTP/1.1、清空Connection头、设置upstream keepalive值，并通过连接数趋势、stub_status中Waiting指标及日志分析三类指标交叉验证复用效果。
要让 Nginx 的 keepalive 真正提升集群健康度，不能只写配置，得把连接复用率变成可观测、可评估的健康信号。核心思路是：用 upstream keepalive 建立稳定连接池，再通过三类指标交叉验证复用是否真实发生——连接数趋势、空闲状态占比、日志行为痕迹。
必须配齐的三项基础配置
缺任何一项，复用率都会趋近于零，所有后续监控都失去意义：
-
启用 HTTP/1.1 协议：在 proxy_pass 所在的 location 或 server 块中加
proxy_http_version 1.1;。HTTP/1.0 默认关闭连接，不设此项，后端收到请求后立即断连。 -
清空 Connection 请求头：加
proxy_set_header Connection '';（注意是空字符串，不是"Keep-Alive"或"close"）。否则客户端传来的Connection: close会被透传，导致后端主动关闭。 -
声明连接池容量：在 upstream 块内设置
keepalive 32;（建议值 16–64）。它表示每个 worker 进程最多缓存 32 个空闲连接到该后端，不是全局总数。
用连接数趋势判断复用是否生效
这是最直接、无需额外模块的验证方式，适合压测或日常巡检：
- 在 Nginx 机器上执行：
ss -tan | grep :8080 | grep ESTAB | wc -l（将:8080替换为实际后端端口）。 - 若复用正常，ESTABLISHED 连接数应稳定在
worker_processes × keepalive附近（例如 4 个 worker + keepalive 32 → 约 128 个连接），不会随 QPS 线性上涨。 - 若连接数持续攀升甚至突破 1000，说明连接池未生效，大概率是三要素缺失或后端返回了
Connection: close。
用 stub_status 中的 Waiting 指标看客户端复用质量
这反映的是 Nginx 与客户端之间的长连接健康度，间接影响后端压力：
- 开启
stub_status后，观察输出中的Waiting:数值，它等于Active connections − (Reading + Writing)。 - 若
Waiting长期占Active connections的 85% 以上，且keepalive_timeout设为 30–60 秒，说明浏览器/APP 正常复用连接，前端链路健康。 - 若
Waiting长期为 0–5，可能因客户端未发 Keep-Alive、中间 WAF/NAT 强制断连、或keepalive_timeout设置过短（如低于 10 秒）。
用日志与 error.log 定位复用失败根因
当连接数异常或 Waiting 偏低时，日志能快速定位是哪一环掉链子：
- 在
http块中启用 debug 日志：error_log /var/log/nginx/debug.log debug;，然后搜索关键词：keepalive connection reused（成功复用）、create new keepalive connection（新建连接）、upstream prematurely closed connection（后端提前关连）。 - 检查
error.log是否频繁出现：upstream connection is busy（连接池满）、no live upstreams（健康检查失败）、Connection reset by peer（上下游超时错位）。 - 在
log_format中加入$upstream_connect_time，若大量为-或突增，说明 Nginx 正在反复建连，复用已失效。
