要真正压榨回源长连接的带宽红利，核心是让nginx与后端每个连接“跑得勤、干得多、退得快”，需严丝合缝协同upstream keepalive连接池、http/1.1协议、后端响应行为；必须配齐proxy_http_version 1.1、proxy_set_header connection ''、upstream keepalive三项基础配置，缺一不可。
要真正压榨回源长连接的带宽红利，核心不是堆高连接数，而是让 Nginx 与后端之间的每个连接“跑得勤、干得多、退得快”——即提升复用率、延长单连接有效生命周期、避免空转滞留。这需要 upstream keepalive 连接池、协议行为、后端响应三者严丝合缝。
必须配齐的三项基础配置
缺一不可，否则连接池形同虚设：
-
启用 HTTP/1.1 协议：在 location 块中写
proxy_http_version 1.1;。HTTP/1.0 不支持持久连接，不设此项，后端收到请求后默认断连，复用无从谈起。 -
清除 Connection 请求头：加
proxy_set_header Connection '';。否则 Nginx 可能将客户端传来的Connection: close转发给后端，直接触发断连。 -
声明连接池大小：在 upstream 块内设置
keepalive 32;（建议值 16–64）。它表示每个 worker 进程最多缓存多少个空闲连接到该后端，不是全局总数；8 个 worker 就是 256 条连接上限。
按后端能力反推 keepalive 数值
不能拍脑袋定，要算清楚安全水位：
- 若后端单实例最大连接数为 2000，Nginx 有 4 个 worker，按 70% 安全水位反推：
2000 × 0.7 ÷ 4 ≈ 35，keepalive 设 32 或 48 更稳妥。 - 后端是 Tomcat？查
maxConnections和connectionTimeout；是 Node.js？看server.maxConnections；是 Go Gin？确认是否启用KeepAlive并设了合理超时。 - 避免连接堆积：数值过大，空闲连接占满后端连接槽位，新请求被迫排队或失败；过小则频繁建连，带宽红利被握手开销吃掉大半。
协同控制单连接生命周期
只设连接池数量不够，还要管好每条连接“活多久、干几单”：
-
keepalive_timeout：建议设为 20–45 秒，且必须小于后端服务的空闲超时（如 Tomcat 的
connectionTimeout）。若 Nginx 想复用，后端已关，复用就失败，反而增加错误率。 - keepalive_requests：默认 100 易成瓶颈；React 类前端可设至 2000（覆盖一次完整页面交互链路）；纯 JSON API 场景建议 1000–3000；老旧后端存在内存泄漏风险，可降至 200–500 强制轮转。
- 真实连接寿命 =
keepalive_timeout与keepalive_requests中先触发的那个。高频短周期请求（如每 2 秒心跳），推荐timeout 15–30s + requests 1000+组合。
验证是否真正在压榨带宽红利
不靠猜，看数据：
- 压测中执行
ss -tan | grep :8080 | grep ESTAB | wc -l，连接数应稳定在worker_processes × keepalive附近，而不是随 QPS 持续上涨。 - 对比调整前后：相同 QPS 下，后端
TIME_WAIT数量是否明显下降；Nginx worker 进程 CPU 是否从协议栈开销转向业务处理。 - 抓包观察连续请求是否复用同一源端口 → 目标端口组合；若每次请求源端口都变，说明复用未生效。
