Nginx反向代理实现严格SSL会话重用需三要素协同：1. http块顶层配置shared缓存（如shared:PROXY_SSL:20m）；2. proxy_ssl_session_timeout须匹配上游实际有效期；3. upstream keepalive与proxy_ssl_keepalive必须同时启用且匹配。
要在 Nginx 反向代理中实现严格的 SSL 会话重用（即稳定复用与上游 HTTPS 服务的 TLS 连接），关键不是简单开启复用，而是确保三项配置协同生效、位置正确、参数匹配。缺一不可，否则看似配了，实则复用率趋近于零。
必须使用 shared 缓存并声明在 http 块顶层
proxy_ssl_session_cache 默认是 builtin 模式，每个 worker 进程各自维护缓存，互不共享。当请求被不同 worker 处理时，即使目标 upstream 相同，也无法命中已建立的 TLS 会话。
- 生产环境必须设为
shared:PROXY_SSL:20m（名称可自定义，大小建议 20MB 起步） - 该指令只能写在 http { } 块最外层，不能放在 upstream、server 或 location 内
- Windows 环境不支持 shared，只能退回到 builtin 或 off，复用能力天然受限
超时时间必须与上游真实行为对齐
proxy_ssl_session_timeout 不是越长越好，它控制缓存条目的生命周期。若设得远长于 upstream 实际允许的会话有效期，条目长期滞留却无法复用，浪费内存；若设得太短，刚缓存就过期。
- 标准 Web 后端（如 Flask、Express）：推荐
5m–10m - 内网 Java 微服务或 API 网关（明确启用 session 复用）：可设
30m–2h - 高频健康检查或轮询服务：建议
1m–2m，避免探测连接挤占缓存空间 - 上游不支持复用（如老旧 LB）：直接设为
0或省略该指令，避免无效缓存
必须配合 proxy_ssl_keepalive 和 upstream keepalive
仅靠缓存无法自动复用——连接本身得保持空闲状态，才有机会被后续请求复用。
- upstream 块中需启用
keepalive 32;（数字按实际并发调整） - 对应 location 或 server 中需启用
proxy_ssl_keepalive on; - 二者必须同时存在，且数量级匹配（例如 keepalive 32 对应 proxy_ssl_keepalive on）
验证是否真正生效，不看配置看行为
配置 reload 成功 ≠ 复用落地。要确认是否真起作用，需观察实际连接行为：
- 直连 upstream 测试：用
openssl s_client -connect upstream-host:443 -reconnect，输出含Reused, SSL handshake succeeded才说明上游本身支持复用 - Nginx 日志加变量：
$ssl_session_reused（客户端侧）和$upstream_http_x_ssl_session_reused（若 upstream 返回该头）可辅助判断 - 开启 debug 日志（
error_log /path/to/debug.log debug;），搜索SSL reused或SSL new session关键字
