要真正启用Nginx HTTPS回源长连接，必须同时配置proxy_http_version 1.1、proxy_set_header Connection ''和upstream keepalive N；三者缺一不可，否则TLS复用失效。
要真正压榨加密回源（HTTPS）长连接的带宽红利，核心不是堆高并发或加大缓冲区，而是让每一次 TCP+TLS 连接都“跑满、跑久、跑稳”——这依赖 keepalive 连接池与加密链路特性的深度协同。默认配置下，Nginx 回源走短连接，每次都要重做 TLS 握手（2 RTT）、重走 TCP 慢启动，白白浪费 100ms+ 延迟和首字节吞吐能力。调优目标很明确：复用、复用、再复用，同时不让连接“卡住”或“断在半路”。
必须配齐的三项基础动作
缺一不可，否则连接池形同虚设：
-
强制 HTTP/1.1 协议：在 location 或 server 块中写
proxy_http_version 1.1;。HTTP/1.0 不支持持久连接，不设此项，后端收到请求后默认断连，TLS 复用直接失效。 -
清空 Connection 请求头：加
proxy_set_header Connection '';。否则 Nginx 可能将客户端传来的Connection: close转发给源站，触发主动关闭，刚建好的 TLS 连接立刻作废。 -
声明连接池大小：在 upstream 块内设
keepalive 64;（建议值 32–128）。它表示每个 worker 进程最多缓存多少个空闲 HTTPS 连接到该源站 IP+端口，不是全局总数。若 DNS 解析出 3 个源站 IP，实际最大空闲连接数是worker_processes × 64 × 3。
针对 HTTPS 的关键参数调优逻辑
加密回源对连接生命周期更敏感：TLS 握手耗时高、证书校验开销大、中间设备（WAF、LB、防火墙）更易静默中断空闲连接。
-
keepalive_timeout 设为 30–45 秒：必须比源站 TLS 层的 keepalive timeout 小 5–15 秒。例如源站 Nginx 设了
keepalive_timeout 60s，Nginx 回源端就设keepalive_timeout 45s。过长会导致连接被源站或中间设备提前关掉，复用失败；过短则频繁重建，失去 TLS 复用价值。 - keepalive_requests 设为 1000–5000：默认 100 在 HTTPS 场景下极不合理。一次完整 TLS 握手成本高，应尽可能让单连接承载更多请求。高频 API 或资源回源可设到 3000；若源站启用了 TLS Session Resumption（如 Session Ticket），甚至可设 5000，进一步摊薄握手开销。
-
启用 socket 级保活：加
proxy_socket_keepalive on;。它让操作系统在空闲时发送 TCP keepalive 探针（非应用层），防止 NAT、防火墙等中间设备因超时静默切断连接，尤其在低频但要求稳定的回源场景（如配置同步、日志上报）中效果显著。
绕过常见“假复用”陷阱
配置写了≠生效。很多问题藏在链路中间：
-
检查源站响应头：确保源站返回
Connection: keep-alive。若返回Connection: close（常见于 5xx 错误页、调试开关开启、WAF 注入），Nginx 会立即释放该连接，无法复用。可用curl -v https://源站域名/path直接验证。 -
确认 WAF/LB 不改写头部：部分云 WAF 或四层 LB 会默认删除或覆盖
Connection头。需在 WAF 控制台关闭“连接头优化”类功能，或启用透传模式。 -
避免健康检查反向耗尽连接池：若 upstream 配了
health_check且未指定match规则，Nginx 可能用 HTTP/1.0 发起探测，导致健康检查独占并快速耗尽空闲连接。建议显式配match http_2xx并确保探测路径返回标准 HTTP/1.1 响应。
验证是否真正在“压榨红利”
看指标，而非配置：
- 用
ss -tnp | grep :443 | grep ESTAB | wc -l查看 Nginx 到源站 443 端口的稳定连接数。压测中应稳定在worker_processes × keepalive附近，而不是随 QPS 线性上涨。 - 在源站 Nginx 日志中加入
$connection_requests变量，观察同一连接处理请求数是否普遍 ≥500。若大量连接只处理 1–2 次就断开，说明复用率极低。 - 抓包对比：连续两次回源请求是否复用同一源端口→目标端口组合？若每次都是新 SYN，说明完全没复用，得回头查协议版本或头部清除是否漏配。
