开启 proxy_ssl_session_reuse on 可减少30%–60%建连延迟，因会话复用仅需1个RTT且跳过证书验证；但需后端支持、证书稳定、SNI一致且配置作用域正确，否则退化为完整握手。
开启 proxy_ssl_session_reuse on 能显著降低后端 HTTPS 连接的 TLS 握手开销，实测可减少 30%–60% 的平均建连延迟，吞吐提升取决于并发连接复用率——但前提是后端支持会话复用且证书稳定。
为什么 proxy_ssl_session_reuse 会影响建连效率
TLS 握手本身包含密钥交换、证书验证、加密参数协商等步骤，完整握手耗时远高于复用已有会话（session resumption）。Nginx 默认开启 proxy_ssl_session_reuse on，但若被显式设为 off 或配置在错误作用域（如写在 location 里却依赖全局缓存），就会退化为每次请求都走完整握手。
- 完整握手：需 2–3 个 RTT，CPU 和熵池消耗高
- 会话复用（session ticket 或 session ID）：通常仅需 1 个 RTT，且跳过证书签名验证环节
- Nginx 会话缓存默认基于 worker 进程隔离，不跨进程共享；高并发下若 worker 数多但单 worker 请求量低，复用率也会下降
proxy_ssl_session_reuse 的生效前提与常见失效场景
它不是“一开就灵”的开关，必须满足几个隐性条件才能真正复用：
- 后端服务器必须支持并启用 TLS 会话复用（如 Nginx 后端需配
ssl_session_cache shared:SSL:10m，OpenSSL 后端需启用SSL_CTX_set_session_cache_mode） - 后端证书不能频繁轮换——证书变更会导致会话票据（ticket）或 session ID 失效，Nginx 无法复用
- 不能和
proxy_ssl_session_reuse off冲突：检查是否在http、server、location多级中被覆盖；优先级是 location > server > http - 若用了
proxy_ssl_server_name on，SNI 主机名必须一致；不同proxy_pass目标即使端口相同，也视为不同会话池
如何验证 proxy_ssl_session_reuse 是否实际生效
光看配置没用，得从 Nginx 日志和后端反馈交叉确认：
- 在
http块启用error_log /var/log/nginx/ssl.log debug;，搜索日志中是否出现"SSL reused session"或"SSL new session"—— 前者越多说明复用越成功 - 用
openssl s_client -connect backend-host:443 -reconnect -servername example.com手动测试后端是否返回Reused, SSL-Session: - 对比压测前后
nginx_stub_status中Active connections与Reading/Writing/Waiting比例变化：复用率高时，Waiting 状态占比会上升，Writing 下降 - 注意：Nginx 不提供直接统计复用率的指标，需靠日志采样估算
生产环境调优建议与边界限制
默认值 on 已足够，但高负载或特殊架构下需微调：
- 缓存大小不用改：Nginx 内置会话缓存默认 1MB/worker，够支撑数千并发连接；盲目增大反而增加锁竞争
- 避免在
location级别覆盖该指令——除非某条路径明确要求禁用复用（如调试证书链问题），否则统一放在http或server块 - 如果后端是自签名或私有 CA 证书，
proxy_ssl_verify off可绕过证书校验，但它和proxy_ssl_session_reuse无直接关系；两者常共存，但逻辑独立 - 真正影响吞吐上限的往往是
proxy_buffers、proxy_busy_buffers_size和后端 TCP keepalive 设置，别只盯着这一个参数
最易被忽略的是：Nginx 的 TLS 会话复用只对「同一 worker 进程发起的、目标地址+端口+SNI 完全一致」的连接有效。跨 worker、跨域名、甚至同一域名但用了不同 proxy_pass 变量拼接，都会导致缓存失效——这点在动态路由或灰度发布场景中特别关键。
