复用比优化核心是让nginx与后端稳定维持空闲连接并反复复用，需配齐proxy_http_version 1.1、proxy_set_header connection ''和upstream keepalive三项，缺一不可；验证须看time_wait下降、debug日志reuse频次及ss/tcpdump连接复用现象。
监控并优化 Nginx 后端代理请求的连接复用比，核心是让 Nginx 与后端服务之间稳定维持一批空闲连接，并反复复用它们，而不是每次请求都新建 TCP 连接。复用比高，意味着后端连接数显著低于客户端并发量，TIME_WAIT 少、建连开销低、吞吐更稳。
确认复用是否真正生效
别只看配置有没有写，要从现象验证：
- 在后端服务器执行 ss -s | grep -i time_wait，持续观察 —— 复用率提升后，TIME_WAIT 数量应明显下降（理想情况下降 50% 以上）
- 在 Nginx 开启 debug 日志（error_log /path/to/error.log debug;），搜索关键词 keepalive.*reuse 或 create connection：看到大量 reuse 行为、极少 create，说明复用已起效
- 用 tcpdump 抓包或运行 ss -t -o src :8080（假设后端端口 8080），检查同一源端口是否被多个请求复用（而非每次换端口）
必须配齐的三项 upstream 基础项
缺一不可，否则 keepalive 形同虚设：
- proxy_http_version 1.1; —— 放在 location 或 server 块内。HTTP/1.0 不支持长连接，不设此项后端会直接断连
- proxy_set_header Connection ''; —— 清空 Connection 请求头。否则 Nginx 可能把客户端发来的 Connection: close 转发给后端，导致连接被主动关闭
- keepalive 32; —— 写在 upstream 块中。表示每个 worker 进程最多缓存 32 个空闲到该后端的连接（不是全局总数），建议值 16–64，根据后端单机处理能力的 1/2～1/3 设定
增强复用稳定性与可控性
加了这几项，复用更稳、资源更可控：
- keepalive_timeout 60s; —— 在 upstream 块中设置空闲连接保活时长，避免僵死连接长期占资源
- keepalive_requests 100; —— 限制单个空闲连接最多承载多少次请求，防止单连接过载引发后端异常（如 Tomcat OOM）
- 确认后端支持 keepalive：例如 Tomcat 需开启 keepAlive="true"，且 connectionTimeout ≥ 75s（应大于 Nginx 的 keepalive_timeout）
- 健康检查别干扰池子：若启用 health_check，确保探测使用 HTTP/1.1 并配置 match，避免频繁探测耗尽空闲连接
关键监控指标与工具
靠数据驱动调优，重点关注以下指标：
- Nginx 自带状态页（需编译 stub_status）：查看 Active connections 和 Accepted/Handled ratio，结合业务请求节奏判断连接复用节奏
- Prometheus + nginx-vts-exporter：重点盯 nginx_vts_upstream_connections_active 和 nginx_vts_upstream_connections_idle，idle 数长期 > 0 且波动平稳，说明池子健康
- 后端侧对比：用 ss -s | grep "TCP:" 查 established 连接数，应远低于客户端并发请求数（比如客户端并发 5000，后端 established 维持在 200–400）
- 错误日志筛查：关注 connect() failed (111: Connection refused) 或 upstream timed out，前者提示连接池不足或后端宕机，后者指向后端响应慢或超时设置不合理
