直接在upstream块中启用proxy_ssl_session_reuse on,并同步配齐keepalive、HTTP/1.1长连接、TLS版本对齐及SNI支持,才能将HTTPS建连压缩至1 RTT,实测延迟降30%+、CPU降约1/3;该指令仅在upstream上下文生效,写在其他层级无效。

直接在 upstream 块中启用 proxy_ssl_session_reuse on,并同步配齐长连接、协议对齐和 SNI 支持,才能真正把后端 HTTPS 代理建连从 2–3 RTT 压缩到 1 RTT,实测延迟下降 30%+、CPU 消耗降低约三分之一。
必须写在 upstream 块里才生效
这个指令只在 upstream 上下文中起作用,写在 http、server 或 location 里会被忽略——哪怕语法正确,也完全不触发。
- ✅ 正确示例:
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>} - ❌ 常见错误:
在location /api中写proxy_ssl_session_reuse on;
后端地址误写为http://backend:443(协议写错,Nginx 当作 HTTP 处理);
upstream 名称拼错或proxy_pass指向了不存在的块
三项配套配置缺一不可
单独开 proxy_ssl_session_reuse 几乎没效果。它依赖底层 TCP 连接复用和 TLS 上下文一致性。
-
维持空闲连接池:在
upstream中设keepalive 32;(建议值 16–64,按单 worker 并发量的 1.5–2 倍估算) -
强制 HTTP/1.1 长连接:在
location或upstream对应的 proxy 指令块中加proxy_http_version 1.1;proxy_set_header Connection '';
(清空 Connection 头,防止后端返回Connection: close主动断连) -
确保 SNI 正确传递:若后端是多域名共 IP 的云服务(如 ALB、API 网关),必须加
proxy_ssl_server_name on;
否则 Nginx 不发 SNI,证书匹配失败,复用立即中断
关键细节决定复用成败
很多配置看似全了,但复用率仍接近零——问题往往藏在这些隐性条件里:
-
TLS 版本必须有交集:比如后端只支持 TLSv1.3,而 Nginx 配了
proxy_ssl_protocols TLSv1.2 TLSv1.3是 OK 的;但如果只配了TLSv1.2,就必然握手失败 -
后端得真支持会话恢复:Spring Boot 默认开启 session cache,但 Tomcat 需显式设
sessionCacheSize;Nginx 后端则要配ssl_session_cache shared:SSL:10m和足够长的ssl_session_timeout(建议 ≥300s) -
证书链要稳定且可验证:若启用了
proxy_ssl_verify on,而后端用自签名证书、中间 CA 缺失或 OCSP stapling 失败率高,TLS 握手会直接报错,复用无从谈起;调试阶段可用proxy_ssl_verify off+proxy_ssl_trusted_certificate快速定位
怎么确认它真正在起作用
不能只看配置有没有写上,要从行为和日志交叉验证:
- 在
log_format中加入$upstream_ssl_session_reused变量,统计 1 小时内r(复用)与.(未复用)的比例;健康状态应稳定在 85% 以上 - 用
ss -tnp | grep :443观察 Nginx 到后端的 ESTAB 连接数;若长期稳定在keepalive × worker_processes附近(如 64×4=256),说明复用良好;若频繁升降,大概率是后端主动断连或超时设置冲突 - Wireshark 抓包过滤后端 IP:443,对比启用前后 TLS 握手流程:复用成功时,多数请求只出现
Change Cipher Spec+Finished;完整握手则必见ClientHello → ServerHello → Certificate → ...











