开启 proxy_ssl_session_reuse on 可将 https 建连从 2–3 rtt 降至 1 rtt，延迟由 80–120ms 降至 20–40ms，但必须置于 upstream 块内，并配合 proxy_http_version 1.1、keepalive、proxy_ssl_server_name on 三项配置，且需规避 tls 版本不匹配、后端主动断连、证书验证失败等失效场景。
直接开启 proxy_ssl_session_reuse on 能显著提升 Nginx 代理大规模 HTTPS 后端时的连接效率，核心是复用 TLS 会话，把每次建连从 2–3 RTT 缩减到 1 RTT，单次建连延迟可从 80–120ms 降至 20–40ms。但它不是“一开就灵”的开关，必须放在正确位置、配合关键配置、避开常见失效陷阱。
必须写在 upstream 块里才生效
这个指令只对 upstream 块内的 HTTPS 后端起作用，放错位置等于没配：
- 写在
location或server块里 —— 语法不报错，但被完全忽略 - 后端地址写成
http://backend:443或https://拼错 —— Nginx 当作普通 HTTP 处理，不触发 SSL 相关逻辑 - upstream 名称和
proxy_pass指向不一致 —— 配置形同虚设
正确示例：
upstream api_cluster {
server api1.example.com:443;
server api2.example.com:443;
keepalive 32;
proxy_ssl_session_reuse on;
}
三项配套配置缺一不可
单独开 proxy_ssl_session_reuse 效果有限，它依赖以下三个基础支撑才能稳定复用：
-
HTTP/1.1 长连接：加
proxy_http_version 1.1;和proxy_set_header Connection "";，防止后端因 HTTP/1.0 行为主动断连 -
upstream 连接池：
keepalive 32;（数值按并发量调整），让空闲连接保留在池中，为复用提供载体 -
SNI 显式传递：若后端是多域名共 IP 的 HTTPS 服务，必须加
proxy_ssl_server_name on;，否则 Nginx 不发 SNI，后端无法匹配证书，复用失败
高频失效原因要提前排查
即使配置全对，复用率仍可能接近 0%，关键看底层是否真正“能复用”：
-
TLS 协议版本不一致：比如 Nginx 配了
proxy_ssl_protocols TLSv1.2，而后端只支持 TLS 1.3，握手必然退化为完整流程 -
后端主动关闭连接：Spring Boot 默认连接超时 20 秒，若 Nginx 的
keepalive_timeout设为 60 秒，连接早被后端关了，复用无从谈起 -
证书验证干扰：启用
proxy_ssl_verify on时，若后端证书链不完整（如自签名、缺中间 CA），TLS 握手失败，自然无法复用；调试阶段可临时关掉验证确认问题
验证不能只看日志，得看连接行为
日志里没报错 ≠ 复用成功。真实效果要从网络层和统计维度交叉验证：
-
抓包确认握手轮次：用 Wireshark 过滤后端端口，复用成功时只看到
Change Cipher Spec + Finished；完整握手则有ClientHello → ServerHello → Certificate → …等 4–5 轮交互 -
日志变量统计复用率：在
log_format中加入$upstream_ssl_session_reused，值为r表示复用、.表示未复用，聚合分析比例 -
连接数趋势观察：执行
ss -tnp | grep :443，复用率高时活跃连接数应稳定在keepalive × worker_processes附近，而非持续涨落
