ssl_session_timeout设为10m–20m并配足共享缓存（如shared:ssl:20m）可显著提升静态资源tls复用率，覆盖用户刷新、切标签等高频行为；需同步启用并轮换session ticket密钥，避免timeout与cache大小失配导致抖动。
直接把 ssl_session_timeout 设高一点，再配好缓存，就能让静态资源加载更快——关键不是“多长”，而是和你的服务类型、客户端行为对得上。
静态服务适合设 10m–20m
面向浏览器的静态站点（HTML/CSS/JS/图片等），用户常在几秒内刷新、切标签、点链接，这些操作都可能触发新连接。5 分钟默认值容易在用户活跃期内过期，尤其遇到弱网重连或 SPA 频繁子请求时，复用失败率明显上升。
- 设为
10m（600 秒）可覆盖多数回访与交互间隙，实测复用率提升显著 - 设到
20m（1200 秒）对 CDN 回源或高并发静态分发更友好，但需同步加大缓存容量 - 不建议超过 30m：静态服务通常无长连接需求，过长反而增加内存占用，且对现代浏览器（如 Chrome v119+）效果有限——它们主要依赖 Session Ticket，而非 Session ID
必须搭配足够大的 ssl\_session\_cache
ssl_session_timeout 单独调大没用，它只管“条目保留多久”，不管“能存多少条”。如果缓存太小，还没超时就被新会话挤掉了，等于白设。
- 推荐用
shared:SSL:20m或更大（例如50m），支持多 worker 共享，适合生产环境 -
20m共享内存约容纳 8–10 万个会话（依 OpenSSL 版本略有差异），对中高流量静态站基本够用 - 避免 “timeout 长 + cache 小” 组合，否则缓存抖动严重，复用率不升反降
别忘了 Session Ticket 的协同作用
现代浏览器（Chrome/Firefox/Safari）默认优先使用 Session Ticket 复用，ssl_session_timeout 对它不起作用。要真正提升静态资源复用率，还得打开并管好 ticket：
- 启用
ssl_session_tickets on - 配置
ssl_session_ticket_key并定期轮换（至少每周一次） - 若只服务新浏览器，
ssl_session_timeout可适当缩短至4m–8m，专注应对标签页切换、F5 刷新等瞬时操作
验证是否真生效
改完别急着上线，先确认复用确实变多了：
- 用命令测试：
openssl s_client -connect your.site:443 -reconnect -servername your.site 2>/dev/null | grep "Reused"，反复执行看是否稳定出现Reused - Nginx 日志加
$ssl_session_reused变量，统计r（复用）与.（未复用）比例 - 对比调优前后首字节时间（TTFB）和 TLS 握手耗时（可用 eBPF 或 APM 工具观测）
