Nginx upstream keepalive 真正起效需三者协同：upstream 中配置 keepalive 数值（按后端能力×0.6～0.8÷worker数设定）、proxy 层启用 proxy_http_version 1.1 并清除 Connection 头、后端服务匹配 connectionTimeout 与 keepAliveTimeout。
Java 应用通过 Nginx 反向代理部署时，连接池不是单靠 Nginx 或 Java 一方调优就能解决的，必须两端协同——Nginx 控制到后端的复用连接池，Java 端保障连接可长期复用且不被误关。重点不在“加多大”，而在“对得上”。
必须配齐三项 upstream 连接复用基础配置
缺一不可，否则 keepalive 数值形同虚设：
-
启用 HTTP/1.1 协议：在 proxy 所在 location 块中写
proxy_http_version 1.1;；HTTP/1.0 默认关闭持久连接，不设此项，Nginx 每次都发短连接 -
清空 Connection 请求头：加上
proxy_set_header Connection '';（注意是空字符串，不是"keep-alive"），否则可能把客户端传来的Connection: close转发给 Tomcat，导致连接被主动中断 -
upstream 中声明 keepalive 数值：例如
keepalive 64;，表示每个 worker 进程最多缓存 64 个空闲连接；若你有 4 个 worker，理论最大空闲连接数为 256，不是全局总数
按后端承载力反推 keepalive 合理值
不能拍脑袋设 1024，要结合 Tomcat 实际能力算：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 查 Tomcat 的
maxThreads（如设为 800）和maxConnections（如 10000），再考虑安全水位（建议 70%） - 若 Nginx 有 4 个 worker，后端单实例线程上限 800 → 800 × 0.7 ÷ 4 ≈ 140，那么
keepalive 128或160更稳妥 - 高并发 API 场景下，
keepalive_requests（单连接最大请求数）默认仅 100，容易触发频繁建连；建议调至1000–2000，覆盖前端一次完整页面加载的数十个请求
Java 端必须同步调优，避免“假连接”
Nginx 认为连接还活着，但 Tomcat 可能已静默关闭或卡在 GC 中：
立即学习“Java免费学习笔记（深入）”；
-
Tomcat 连接器参数需匹配：
connectionTimeout="60000"（60 秒）、keepAliveTimeout="60000"、maxKeepAliveRequests="1000"（不限制单连接请求数） -
Spring Boot 项目建议：在
application.yml中设server.tomcat.connection-timeout: -1（交由 Nginx 控制超时），禁用自身连接生命周期干扰 - 避免响应头带 Connection: close：检查后端返回（尤其是错误响应、健康检查接口、WAF 插入头），一旦出现该头，Nginx 会立即释放连接，复用失败
配合连接级内存池减少小对象分配开销
高频长连接场景下，每个 TCP 连接建立时的内存预分配也影响性能：
- 在
http或server块中设置connection_pool_size 2048;（非 location） - Java 应用若带 JWT、大量 Cookie 或自定义 Header，header 体积常超默认 256 字节，设为 2048～4096 可避免反复扩容内存池、降低碎片
- 该值不改变底层内存块大小（固定 4095 字节），只控制初始可用空间；调太大则空闲内存浪费，尤其在万级长连接时 RSS 明显升高
