必须同时配置proxy_http_version 1.1、proxy_set_header connection ""和upstream keepalive n;三项,缺一不可;否则长连接无法复用,性能不升反降。

直接加 proxy_http_version 1.1 不会提升性能,它只是必要条件之一。真正起效需要三件事同时配齐:协议版本声明、Connection 头清理、upstream 连接池启用。漏掉任意一项,长连接就无法复用,性能反而可能更差。
必须配齐的三项基础配置
这三项构成闭环,缺一不可:
-
显式启用 HTTP/1.1 协议:在
location块中写proxy_http_version 1.1;,否则 Nginx 默认仍用 HTTP/1.0 转发请求,后端不认为连接可复用 -
清空 Connection 请求头:加
proxy_set_header Connection "";,否则 Nginx 可能把客户端传来的Connection: close直接转发,导致后端立刻断连 -
开启 upstream 连接池:在
upstream块中配置keepalive N;(如keepalive 32;),表示每个 worker 进程最多缓存 N 个空闲长连接;没它,Nginx 每次都新建 TCP 连接
配套超时与后端适配
光打通连接复用还不够,得匹配业务节奏和后端能力:
安全更新和维护 CLI Proxy API(CPA)部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
调优代理超时参数:
proxy_connect_timeout控制建连时间;proxy_send_timeout和proxy_read_timeout应略大于后端典型响应耗时,避免误断活跃连接 -
WebSocket 等长连接场景:把
proxy_read_timeout设为0或较大值(如86400),防止空闲时被 Nginx 主动关闭 -
确认后端支持 Keep-Alive:比如 Tomcat 需设置
connectionTimeout,Gunicorn 需启用--keep-alive;若后端是旧版 CGI 或短连接服务,Nginx 端再优化也无效
验证是否真正生效
不能只看配置写了没,要观察实际连接行为:
- 用
ss -tnp | grep :<em>upstream_port</em>查看 ESTABLISHED 连接数是否稳定、复用同一 IP:PORT 对 - 抓包检查 Nginx 发往后端的请求中,是否没有
Connection: close,且多个请求共享同一个 TCP 流 - 对比开启前后 QPS 和平均响应时间变化,尤其在高并发短请求场景下提升通常最明显
不复杂但容易忽略的是 header 清理和协议版本匹配——漏掉 proxy_set_header Connection '',再好的 keepalive 配置也会被覆盖失效。










