ssl_session_timeout控制Nginx服务端SSL会话缓存条目有效期，需配合ssl_session_cache使用，影响TLS会话复用成功率；推荐Web服务设5m–10m，移动端15m–30m，短连接1m–3m。

SSL/TLS 握手是 HTTPS 请求中开销较大的环节，频繁新建连接会加重 CPU 负担并延长首字节时间。Nginx 的 ssl_session_timeout 指令正是用来控制服务器端 SSL 会话缓存的有效期，从而提升 TLS 会话复用（Session Resumption）成功率，减少完整握手次数。

理解 ssl_session_timeout 的作用范围

该指令位于 http、server 或 location 块中，定义的是 Nginx 主动维护的「会话缓存条目」在内存或共享内存中保留的时间上限。它不控制客户端本地缓存行为，也不影响 RFC 5077（TLS Session Tickets）机制——后者由 ssl_session_tickets 和 ssl_session_ticket_key 控制。

• 仅对使用 ssl_session_cache（如 shared:SSL:10m）启用服务端缓存时生效
• 超时后，对应会话 ID 对应的缓存条目被清除，下次相同 ID 连接将无法复用，触发新握手
• 实际复用是否成功，还取决于客户端是否携带有效会话 ID 且未过期（受其自身策略影响）

合理设置 timeout 值的关键考量

设得太短，缓存命中率低，复用失效；设得太长，内存占用增加，且可能保留已失效或被吊销的会话状态。推荐结合典型业务连接模式调整：

Browser Session Manager

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

下载

• 面向浏览器的 Web 服务：建议 5m–10m（300–600 秒），覆盖用户短时刷新、标签页切换等场景
• 移动端 App 或长连接 API：可适当延长至 15m–30m，但需配合足够大的 ssl_session_cache 容量
• 高并发短连接场景（如爬虫、健康检查）：可设为 1m–3m，避免缓存膨胀
• 禁用会话缓存时（ssl_session_cache off），此指令无效

搭配 ssl_session_cache 才真正生效

ssl_session_timeout 必须与 ssl_session_cache 配合使用。常见可靠配置示例如下：

http {
    ssl_session_cache shared:SSL:20m;  # 分配 20MB 共享内存存储会话
    ssl_session_timeout 10m;           # 条目最长保留 10 分钟
    ssl_session_tickets off;          # 可选：关闭 ticket，专注服务端缓存复用
}

注意：shared 缓存支持多 worker 进程共享，比 builtin 更适合生产环境；20m 约可缓存 8–10 万个会话（依 OpenSSL 版本略有差异）。

验证复用效果的方法

不能只看配置是否加载，要观测真实连接行为：

• 开启 Nginx 日志变量：$ssl_protocol、$ssl_session_reused（值为 .t. 表示复用，.f. 表示新建）
• 用 openssl s_client -connect example.com:443 -reconnect 观察输出中 Reused session-id 是否出现
• 监控 Nginx 指标：nginx_http_ssl_handshakes_total{handshake="full"} 与 nginx_http_ssl_handshakes_total{handshake="reused"} 的比例