核心目标是复用TCP连接以降低延迟、减少握手开销并缓解上游压力；需结合后端承载能力、并发量与worker数合理设keepalive值（如单实例maxConnections=200时，4 worker配keepalive 32～64），并必须配合proxy_http_version 1.1和proxy_set_header Connection ''生效。
调优 upstream keepalive_conns 的核心目标，是让 Nginx 与上游服务器（如后端应用服务）之间复用已建立的 TCP 连接，避免每次请求都重新发起三次握手和 TLS 握手（如启用 HTTPS），从而降低延迟、减少系统开销，并缓解上游服务的连接压力。
理解 keepalive_conns 的作用机制
该指令定义每个 worker 进程为该 upstream 保留的空闲长连接最大数量。它不控制总连接数，而是限制“可复用”的连接池容量。当活跃连接超出此值，Nginx 会关闭最久未使用的空闲连接；若新请求到来时池中无可用连接，才会新建连接。
注意：仅配合 keepalive 指令（设置空闲连接超时时间）和 proxy_http_version 1.1 + proxy_set_header Connection '' 才能真正启用 HTTP/1.1 长连接复用。
合理设置 keepalive_conns 的关键依据
数值并非越大越好，需结合以下因素综合评估：
- 上游服务的连接承载能力：例如某 Java 应用使用 Tomcat，默认 maxConnections=200，若 Nginx 有 4 个 worker，keepalive_conns 设为 64，则理论最大保活连接数为 4×64=256，可能压垮后端。建议初始值设为上游单实例连接池大小的 1/4～1/2。
-
实际并发请求数与连接复用率：通过
nginx_stub_status或 Prometheus + nginx-vts-exporter 观察Active connections和Reading/Writing/Waiting分布，再结合 upstream 模块的keepalive监控（如upstream_keepalive指标），判断连接池是否长期饱和或大量闲置。 - worker 进程数与负载均衡策略：轮询模式下，连接池按 worker 独立维护；IP hash 或一致性哈希可能导致部分 worker 连接池过载，此时需适当提高其 keepalive_conns 值，或改用更均衡的策略。
典型调优操作步骤
以常见 Web 服务场景为例：
- 先开启监控：启用
ngx_http_upstream_module的状态接口，或在日志中记录$upstream_addr和$upstream_connect_time，定位高建连延迟请求。 - 保守起步：将
keepalive_conns设为 32（适用于中小流量），keepalive设为 60s，观察 24 小时内连接复用率（复用次数 / 总请求次数）是否 ≥85%。 - 逐步扩容：若复用率低且上游负载余量充足，每次增加 16～32，同步观察上游 TIME_WAIT 数量、文件描述符占用及 GC 压力（尤其 JVM 应用）。
- 反向验证：用
ss -tan | grep :<upstream_port> | wc -l</upstream_port>在 Nginx 机器上采样空闲连接数，确认接近配置值但不过载；同时检查上游 netstat 中 ESTABLISHED 连接是否稳定、无突增。
配套必须做的配置项
仅调 keepalive_conns 不生效，以下配置缺一不可：
upstream backend { server 10.0.1.10:8080; keepalive 60; keepalive_requests 1000; }location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ''; }- 如使用 HTTPS 回源，还需
proxy_ssl_session_reuse on;开启 SSL 会话复用，否则每次仍需完整 TLS 握手。
