proxy_ssl_session_reuse on 仅启用复用能力，实际复用率取决于前后端tls版本、证书链、session ticket密钥、keepalive及sni等协同配置是否一致，必须置于upstream块内且配套三项基础设置才能生效。
开启 proxy_ssl_session_reuse on 本身不能“确保”完美复用，它只是启用复用能力的开关；真正决定复用是否稳定、高效、接近 100% 的，是前后端协同配置的一致性与细节把控。只要任一环节不匹配，复用就会退化为完整握手——延迟回到 80–120ms，CPU 消耗翻倍。
必须放在 upstream 块内才生效
这个指令只在 upstream 上下文中起作用，且仅对 https:// 协议的后端生效：
- 写在
location或server块里 → 语法合法但完全被忽略 - 后端地址写成
http://backend:443或拼错域名 → 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;
}
三项配套配置缺一不可
SSL 会话复用依赖底层 TCP 连接长期存活，没有连接池，复用无从谈起：
-
keepalive 32：每个 worker 进程缓存最多 32 个空闲 HTTPS 连接（按并发量调至 16–64） -
proxy_http_version 1.1：强制使用 HTTP/1.1，避免后端因协议降级关闭连接 -
proxy_set_header Connection ""：清除请求头中的Connection: close，防止后端主动断连清空池
若后端是多域名共 IP（如 Istio、Kong、多租户网关），还必须加：proxy_ssl_server_name on，确保 SNI 正确传递，否则证书不匹配，复用直接失败。
规避高频失效场景
即使配置全对，复用率仍可能为零，关键看底层是否“真能复用”：
-
TLS 版本不一致：Nginx 设
proxy_ssl_protocols TLSv1.2，而后端只支持 TLSv1.3 → 握手失败 → 复用归零 -
后端主动断连：Spring Boot 默认
connection-timeout=20s，若 Nginxkeepalive_timeout设为 60s，连接早被后端关闭 -
证书验证干扰：启用
proxy_ssl_verify on但后端证书链不完整（如缺中间 CA、自签名未信任），TLS 握手中断，无法复用 -
会话票据密钥不共享：多实例后端启用 session ticket 时，所有节点必须共用同一
ssl_session_ticket_key，否则票据无法解密
验证是否真实复用，不能只看配置
日志没报错 ≠ 复用成功。需从行为层确认：
- 在
log_format中加入$upstream_ssl_session_reused变量，值为r表示复用成功，.表示新建会话，聚合统计比例 - 用
ss -tnp | grep :443观察 ESTABLISHED 连接数是否稳定在keepalive × worker_processes附近，而非频繁涨落 - Wireshark 抓包过滤后端端口：复用成功时应出现简短握手（Change Cipher Spec + Finished），而非完整的 4–5 轮 TLS 握手
