proxy_ssl_session_reuse默认on但未生效，根本原因是后端不支持Session ID或Ticket复用；需确认后端TLS会话缓存配置，并确保proxy_ssl_verify off、协议/密钥套件固定且指令置于location块内。
proxy_ssl_session_reuse 默认是 on，但实际没生效？
很多人以为只要不显式关掉 proxy_ssl_session_reuse 就能复用 SSL 会话，结果压测时发现后端 TLS 握手次数居高不下。根本原因在于：该指令只控制「Nginx 与后端 HTTPS 服务之间」的会话复用，而它是否真能复用，取决于后端是否支持并正确响应 Session ID 或 TLS Session Ticket。如果后端（比如某些 Java 应用网关、自建 Node.js 服务）禁用了 Session Ticket 或未配置 Session Cache，Nginx 即使设为 on 也无会话可复用。
实操建议：
- 先确认后端是否开启 TLS 会话缓存：对后端服务执行
openssl s_client -connect backend.example.com:443 -reconnect，观察输出中是否出现Reused, SSL handshake succeeded - 若无复用，优先排查后端配置（如 Tomcat 的
sslEnabledProtocols和sessionCacheSize），而非盲目调 Nginx -
proxy_ssl_session_reuse必须放在location块内，且与proxy_pass https://...同级；写在http或upstream块里无效
为什么 proxy_ssl_session_reuse off 反而让延迟更稳？
在证书频繁轮换或后端 TLS 配置不稳定（如证书 Subject 改变、OCSP stapling 失败率高）的场景下，强行复用旧会话可能触发 SSL_do_handshake() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca) 类错误，导致连接被重置、请求重试、P99 延迟毛刺明显。此时设为 off 虽增加单次握手开销，但消除了不确定性，整体 P95/P99 更可预测。
适用场景：
- 后端使用短期自签名证书（如 Kubernetes Ingress Controller 动态签发）
- 灰度发布期间后端 TLS 配置不一致（部分实例启用 TLSv1.3，部分仍为 TLSv1.2）
- 健康检查路径（如
location /_health）单独设为proxy_ssl_session_reuse off，避免探针干扰主流量会话缓存
配合 proxy_ssl_* 其他参数才能真正起效
proxy_ssl_session_reuse 不是独立开关，它依赖于整套 SSL 连接上下文的一致性。比如：proxy_ssl_protocols 和 proxy_ssl_ciphers 若每次请求都动态变化（如通过变量拼接），Nginx 会认为这是新会话，拒绝复用。
阿里百炼大模型平台多人共享账号用量统计代理服务。解决公司共用账号时无法区分个人用量的问题。适用场景：1)部署用量统计代理；2)统计多人Token用量和调用次数；3)管理大模型API调用配额。
关键组合配置示例：
location /api/ {
proxy_pass https://backend;
proxy_ssl_session_reuse on;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
proxy_ssl_verify off; # 若后端证书不可信，必须关 verify，否则复用失败
proxy_ssl_trusted_certificate /etc/nginx/trusted_ca.pem;
}注意点：
-
proxy_ssl_verify off是常见前提——一旦开启验证，每次证书链校验失败都会中断复用流程 - 避免在
proxy_ssl_ciphers中使用模糊通配符（如DEFAULT），不同 OpenSSL 版本解析结果不同，破坏会话一致性 - 若后端要求客户端证书认证，
proxy_ssl_certificate和proxy_ssl_certificate_key必须固定，不能基于请求头动态加载
如何验证复用率是否真实提升？
光看 Nginx 日志或 nginx -T 输出没用。得从连接层抓证据：
- 用
ss -i观察 ESTABLISHED 连接的retrans和rto：复用率高时，同一目的 IP:port 的多个连接应共享相近的rtt和低重传 - 开启 Nginx debug 日志（
error_log /var/log/nginx/debug.log debug;），搜索SSL reused session和SSL new session行，统计比例 - 在后端服务器上运行
openssl s_server -key key.pem -cert cert.pem -accept 443 -state -debug，观察客户端连接时是否打印Reusing session-id
真正难的是：复用率受后端连接池策略反向制约。比如后端用 HTTP/1.1 + keepalive=100，但 Nginx 每次只发 1 个请求就 close，那再好的会话复用也没意义——得同步调 proxy_http_version 1.1 和 proxy_set_header Connection ''。
