如何配置 proxy_ssl_session_reuse 显著提升高并发回源请求的 HTTPS 连接复用率-Nginx-PHP中文网

proxy_ssl_session_reuse默认on但未生效，根本原因是后端不支持Session ID或Ticket复用；需确认后端TLS会话缓存配置，并确保proxy_ssl_verify off、协议/密钥套件固定且指令置于location块内。

如何配置 proxy_ssl_session_reuse 显著提升高并发回源请求的 https 连接复用率

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 会认为这是新会话，拒绝复用。

Browser Session Manager

使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能

下载

关键组合配置示例：

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 ''。