必须在 upstream 块中配置 proxy_ssl_session_reuse on，并配套 keepalive、http/1.1 长连接和 sni 传递，才能实现 tls 会话复用，实测可降低后端 cpu 消耗约 1/3、建连延迟下降 30%+。
直接在 upstream 块里配对 SSL 卸载与连接复用，才能把硬件级算力红利真正榨干——不是堆参数，而是让 TLS 终止、连接池、协议协商和会话恢复严丝合缝地咬合运转。
SSL 卸载必须落在 Nginx 边缘，后端只走 HTTP
卸载不是“省事”，是释放后端 CPU 的关键动作。Java/Python/Node.js 服务本身不擅长密钥运算，硬扛 TLS 握手会吃掉大量线程和周期。
- 前端
server块监听443 ssl，完成证书验证、OCSP Stapling、Session 复用等全部 TLS 工作 - 后端
upstream地址必须写成http://ip:port（如http://192.168.10.101:8000），严禁写https://或http://...:443 - 透传原始协议头：
proxy_set_header X-Forwarded-Proto $scheme;，否则后端生成重定向或判断安全上下文会出错 - 健康检查请求也走 HTTP：
health_check uri=/health interval=5 fails=3 passes=2，避免因 TLS 配置不一致误判下线
upstream 内启用 proxy_ssl_session_reuse（仅此处生效）
这个指令只在 upstream 块中起作用，写在 location 或 server 里完全无效——这是最容易踩的坑。
- ✅ 正确写法：
upstream api_cluster {<br> server svc-a.example.com:443;<br> server svc-b.example.com:443;<br> keepalive 64;<br> proxy_ssl_session_reuse on;<br>} - 必须配套三项：
–keepalive 32–64（维持空闲连接池）
–proxy_http_version 1.1; proxy_set_header Connection '';（保活长连接）
–proxy_ssl_server_name on;（正确传递 SNI，尤其对接云网关或多域名后端） - 若后端是 Spring Boot/Tomcat/Nginx 自身，还需确保它支持会话恢复：Tomcat 要设
sessionCacheSize，Nginx 后端要配ssl_session_cache shared:SSL:10m; ssl_session_timeout 300s;
协议与密钥套件对齐，避免握手失败断连
复用率低？大概率不是配置漏了，而是 TLS 层“谈不拢”。
- Nginx 和后端必须有共同支持的 TLS 版本交集：推荐统一配
proxy_ssl_protocols TLSv1.2 TLSv1.3;，禁用 TLSv1.0/1.1 - 密钥套件要收敛且现代：
proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;，避免使用含SHA1或RC4的老旧套件 - 若启用
proxy_ssl_verify on，必须配全可信 CA 链：proxy_ssl_trusted_certificate /etc/nginx/ca-bundle.crt;；调试阶段可先关验证快速定位问题 - 证书链要完整可验证，中间 CA 缺失或 OCSP stapling 失败率高，会导致握手直接中断，复用无从谈起
日志与监控：盯住真实复用效果
别只看配置写了没，要看 $ssl_session_reused 这个变量是否真为 r（reused）或 s（started）。
- 在
log_format中加入：$ssl_session_reused $upstream_http_x_ssl_session_id - 配合
$scheme和$http_x_forwarded_proto，排查“后端收到 http 却以为自己该跳 https”这类典型问题 - 用
stub_status或 Prometheus +nginx-vts-exporter监控 upstream 连接数、活跃连接、SSL 复用率，实测复用率应稳定在 70% 以上才属正常 - 延迟下降 30%+、后端 CPU 降约 1/3 是常见收益，前提是所有环节都对齐——从边缘 TLS 终止，到 upstream 连接复用，再到后端会话恢复能力
