proxy_ssl_session_timeout 控制 nginx 与上游 https 服务器的 tls 会话缓存时长，影响代理层到 backend 的复用效率；它不作用于客户端连接，需配合 proxy_ssl_session_cache、上游真实复用支持及 proxy_ssl_keepalive 才能生效。
proxy_ssl_session_timeout 控制的是 Nginx 作为反向代理时，与上游 HTTPS 服务器（即后端）建立的 TLS 会话缓存保留时长，它不作用于客户端到 Nginx 的连接，而是影响 Nginx 到 backend 的复用效率。调大它能减少与后端的全握手次数、降低代理层 CPU 开销；但设得过长，会在 proxy 缓存中堆积大量未被重用的会话条目，白白占用物理内存，尤其在后端节点多、连接模式分散时更明显。
明确它管什么、不管什么
这个参数只决定 Nginx 内存中「上游会话 ID 或 ticket 元数据」的最长驻留时间：
- 它管：Nginx 主动维护的 upstream SSL session 缓存条目的过期逻辑
-
它不管：
- 客户端到 Nginx 的 TLS 复用（那是 ssl_session_timeout 的事）
- 上游服务器自身是否支持或启用 session 复用
- Session Ticket 的有效期（由 upstream 的 ssl_session_ticket_key 轮换周期控制）
- TCP 连接复用（由 proxy_ssl_keepalive 和 upstream keepalive 控制）
按上游行为匹配 timeout 值
上游服务类型直接决定合理超时区间，不能套用客户端侧的经验值：
- 标准 Web 后端（如 Node.js/Python Flask）：设为 5m–10m。这类服务通常无状态、连接生命周期短，过长的缓存易滞留失效会话
- 内网可信 API 网关或 Java 微服务集群：可设为 30m–2h，前提是 upstream 显式启用了 session 复用且连接稳定；同时必须配足 proxy_ssl_session_cache shared:PROXY_SSL:30m+
- 健康检查探针或短周期轮询服务：建议 1m–2m。避免高频探测新建的会话挤占缓存空间
- 上游不支持 session 复用（如某些老旧 LB 或自建服务）：设为 1s 或直接关掉（proxy_ssl_session_timeout 0），否则纯属内存浪费
必须同步配齐的三项支撑配置
单独调 proxy_ssl_session_timeout 几乎无效，以下三者缺一不可：
-
启用共享上游会话缓存：
proxy_ssl_session_cache shared:PROXY_SSL:20m;—— builtin 模式不跨 worker，生产环境必须用 shared；20m 约支持 6–8 万个上游会话条目 -
确认上游真实支持复用：用
openssl s_client -connect upstream-host:443 -reconnect直连测试，观察是否出现Reused, SSL handshake succeeded；若上游本身不复用，Nginx 缓存再大也没用 -
开启 upstream TCP keepalive：
upstream my_backend { keepalive 32; }+proxy_ssl_keepalive on;—— TLS 复用依赖底层 TCP 连接复用，否则每次都是新 TCP+新 TLS，缓存形同虚设
验证是否真正起效
别只看配置是否加载，要观测真实复用行为：
- 在 Nginx 日志中加入
$upstream_ssl_session_reused变量（需编译时含 --with-http_upstream_module），统计 r（复用）占比，目标 ≥ 65% - 监控 Nginx 进程 RSS 内存：若 proxy_ssl_session_cache 分配了 50m，但实际 RSS 增长远超该值，说明缓存条目未被有效淘汰或存在泄漏
- 用
ss -tan | grep :443 | wc -l观察 Nginx 到 upstream 的 ESTABLISHED 连接数变化趋势——优化后应更平稳，抖动减小
