启用 proxy_ssl_session_reuse on 可使 Nginx 代理 HTTPS 后端时复用 TLS 会话，将建连从 2–3 RTT 缩至 1 RTT，延迟从 80–120ms 降至 20–40ms；需配合 proxy_http_version 1.1、proxy_set_header Connection "" 和 upstream keepalive，并确保 SNI 一致、证书验证通过及 TLS 协议兼容。
为什么 session reuse 能加快建连
完整 TLS 握手需 2–3 次往返（RTT），而会话复用只需 1 次 RTT（即“简短握手”）。Nginx 复用的是与后端服务器之间已协商好的会话参数（如主密钥、加密套件、协议版本等），跳过证书交换、密钥生成等耗时步骤。实测中，单次建连可从平均 80–120ms 降至 20–40ms，端到端延迟下降常达 30% 以上。
基础配置必须项
- 显式开启复用：`proxy_ssl_session_reuse on;`（默认值即为 on，但建议显式声明，避免被继承配置覆盖）
- 确保 HTTP/1.1 长连接：添加 `proxy_http_version 1.1;` 和 `proxy_set_header Connection "";`，防止上游关闭连接导致无法复用
- 配合 keepalive 连接池：在 upstream 块中设置 `keepalive 32;`，让 Nginx 维护空闲连接，为复用提供基础载体
影响复用成功率的关键细节
即使启用了 `proxy_ssl_session_reuse`，若以下任一条件不满足，仍会退化为完整握手：
Session Handoff
下载
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
- SNI 不一致：后端是多域名共 IP 的 HTTPS 服务时，必须开启 `proxy_ssl_server_name on;`，否则 Nginx 不发送 SNI，后端无法匹配正确证书，拒绝复用
- 证书验证干扰：若配置了 `proxy_ssl_verify on` 且后端证书链不稳定（如自签名、中间 CA 缺失），TLS 握手可能失败，自然无法复用；调试阶段可临时设为 off 验证是否为此原因
- SSL 协议或密钥算法不兼容：前后端支持的 TLS 版本（如只开 TLSv1.3）或 cipher suite 差异过大，也会导致会话不可复用；建议统一使用 `proxy_ssl_protocols TLSv1.2 TLSv1.3;` 并搭配主流 cipher
验证是否生效的方法
不依赖日志（Nginx 默认不记录会话复用状态），推荐两种轻量方式：
- 抓包确认：在 Nginx 机器上对 upstream 目标端口 tcpdump，过滤 TLS 流量，观察 ClientHello 中是否含 `session_id` 或 `pre_shared_key` 扩展，有则表示复用成功
- 对比延迟波动：用 wrk 或 ab 对同一 upstream 接口压测（保持并发数稳定），开启 reuse 前后分别看 p95 建连时间（如 `time_namelookup + time_connect`），下降明显即说明生效
