单纯延长ssl_session_timeout不能提升效率，必须协同共享缓存、客户端行为及session tickets等机制：需用shared:SSL:20m及以上缓存配合10–20分钟超时，启用ssl_session_tickets on并定期轮换密钥，禁用老旧TLS，监控$ssl_session_reused确保复用率超70%。
直接延长 ssl_session_timeout 本身不能提升效率，必须和共享缓存、客户端行为、配套机制协同配置才有效。单纯调大这个值，若缓存容量不足或客户端不配合，反而浪费内存、增加安全暴露窗口。
核心前提：必须启用共享会话缓存
该指令仅在启用 ssl_session_cache 时生效，且不能只用 builtin 缓存——它不跨 worker 进程，生产环境几乎无效。务必使用 shared 模式：
-
ssl_session_cache shared:SSL:20m;—— 20MB 共享内存约支持 8–10 万个会话 - 若设
ssl_session_timeout 20m，但 cache 只有5m，缓存会频繁淘汰，实际复用率不升反降 - 高流量站点建议起步
shared:SSL:30m～50m，尤其搭配长 timeout 时
按业务类型选合理 timeout 值
不是越长越好，需匹配典型连接模式与客户端行为：
- 普通 Web 站点（含 PC/移动端浏览器）：10m–20m（600–1200 秒）。覆盖标签页切换、短时离开后返回、SPA 子资源请求等场景，实测复用率可达 60%–85%
- 移动端 App 或长周期 API：15m–30m。注意现代 Chrome（v119+）主要依赖 Session Ticket，此时可适当降低 timeout 至 4m–8m，重点转向密钥轮换
-
内网网关或可信服务：可设 4h（14400 秒），但必须配
shared:SSL:50m或更高，否则缓存抖动抵消收益 - 金融/政务登录页等高敏系统：保持 5m–10m，优先缩短会话泄露影响窗口
必须同步开启的三项配套机制
缺一不可，否则 timeout 调整基本白费：
-
启用 Session Ticket：
ssl_session_tickets on;。Chrome、Safari 等主流客户端已转向此机制，服务端 session ID 复用率持续下降 -
定期轮换 ticket 密钥：
ssl_session_ticket_key至少每 24 小时更新一次，避免长期密钥被破解导致重放攻击 -
关闭老旧 TLS + 启用 OCSP Stapling：禁用 TLS 1.0/1.1；开启
ssl_stapling on;和ssl_stapling_verify on;，省掉一次证书状态查询，让复用真正快起来
验证是否真正生效
别只看配置，要观测真实效果：
- 日志中加入
$ssl_session_reused变量，统计r（复用）与.（未复用）比例，目标是稳定在 70% 以上 - 用
openssl s_client -connect example.com:443 -reconnect手动测试，观察 “Reused, SSL handshake succeeded” 出现频次 - 监控 TLS 握手耗时（如通过 eBPF 或 APM 工具），对比调优前后首字节时间是否下降 80–150ms
