启用 proxy_ssl_session_reuse on 可将 HTTPS 建连延迟从 80–120ms 降至 20–40ms，端到端延迟降超 30%，复用率超 90%；需配套 keepalive、HTTP/1.1、Connection 头清空及显式开启该指令，并确保 SNI 一致、TLS 协议兼容、后端 idle timeout 不早于 Nginx keepalive_timeout；内部 CA 验证时须关闭该复用以防绕过证书校验；可通过抓包、$upstream_ssl_session_reused 日志变量及 ss 连接数三重验证。
开启 proxy_ssl_session_reuse on 是提升 Nginx 代理微服务 HTTPS 流量效率最直接、零侵入的手段——它让 Nginx 复用与后端服务已建立的 TLS 会话，跳过证书交换、密钥协商等耗时步骤，单次建连延迟从 80–120ms 降至 20–40ms，实测端到端延迟下降超 30%，连接复用率可稳定在 90% 以上。
必须配套的 upstream 基础配置
该指令仅在 upstream 块中生效，且依赖长连接池才能复用。缺一不可：
-
keepalive 32;：为每个 worker 进程维护最多 32 个空闲 HTTPS 连接，提供复用载体 -
proxy_http_version 1.1;和proxy_set_header Connection "";：禁用 Connection: close，防止上游主动断连导致连接池失效 -
proxy_ssl_session_reuse on;：显式启用（默认虽为 on，但多级配置易被覆盖，务必显式声明）
影响复用成功率的关键细节
即使配置正确，以下任一条件不满足，Nginx 仍会退化为完整 TLS 握手：
A powerful memory management system powered by ReMe that provides persistent cross-session memory, automatic user preference application, and intelligent context compression for OpenClaw.
下载
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
-
SNI 不一致：后端是多域名共 IP 的 HTTPS 微服务（如 Istio Ingress Gateway 或多租户网关），必须加
proxy_ssl_server_name on;，否则 Nginx 不发 SNI，后端无法匹配证书，拒绝复用 -
TLS 协议或加密套件不兼容：Nginx 客户端与后端支持的 TLS 版本（如只开 TLSv1.3）或 cipher suite 差异过大。建议统一设为
proxy_ssl_protocols TLSv1.2 TLSv1.3;并搭配主流 cipher -
后端主动关闭连接：若微服务设置了较短的 idle timeout（如 Spring Boot 的
server.tomcat.connection-timeout=5s），早于 Nginx 的keepalive_timeout，连接会被提前回收，复用失败
生产环境需谨慎处理的证书验证
微服务间常使用内部 CA 签发证书，验证逻辑需兼顾安全与复用稳定性：
- 启用校验时：
proxy_ssl_verify on;+proxy_ssl_trusted_certificate /path/to/internal-ca.pem;（仅根证书 PEM，不可含中间链） -
proxy_ssl_verify_depth必须匹配证书链深度（如二级中间 CA 签发，则设为2） -
务必关闭
proxy_ssl_session_reuse以避免绕过校验：若开启复用，旧 session 可能缓存异常证书状态，导致后续请求跳过验证——这是安全风险，不是性能优化
快速验证是否真正生效
不能只看日志，要从连接行为和 TLS 层双重确认：
- 抓包观察：在 Nginx 机器上对后端端口执行
tcpdump -i any port <backend_port> -w ssl.pcap</backend_port>，用 Wireshark 打开后过滤tls.handshake.type == 1，复用成功时 ClientHello 应含pre_shared_key或非空session_id字段 - 日志统计：在
log_format中加入$upstream_ssl_session_reused变量（.表示未复用，r表示复用），聚合分析比例，健康集群应 ≥90% - 连接数监控：执行
ss -tnp | grep :<backend_port></backend_port>，复用率高时活跃连接数应平稳接近keepalive × worker_processes，而非持续新建/销毁
