直接调大 ssl_session_timeout 不能自动提升会话复用率，需匹配业务场景、客户端行为及配套配置：Web站点设10m–20m，App后端设30m，内网网关推荐4h；必须启用足够大的共享缓存、确保客户端支持复用（如开启session ticket）、启用OCSP stapling，并通过日志和工具验证复用率与握手时延改善。
直接调大 ssl_session_timeout 并不能自动提升会话复用率——它只是服务端缓存“认出老用户”的时间窗口，真正起效必须匹配业务连接特征、客户端行为和配套配置。
按业务场景选 timeout 值
普通 Web 站点（含移动端浏览器）：设为 10m–20m。覆盖用户刷新页面、切换标签页、短暂离开后返回等行为，避开 Wi-Fi 切蜂窝时 session ID 失效的高频点。实测在 shared:SSL:20m 缓存下，复用率可达 60%–85%，首屏加载平均快 80–150ms。
App 后端或长连接 API：可延至 30m。App 客户端保活积极，网络波动大，30 分钟更适配推送唤醒后的 HTTPS 请求。但需确认客户端支持 Session ID 复用（部分旧版 Android WebView 仍依赖此机制），并监控 $ssl_session_reused 日志变量，确保复用率稳定在 75% 以上。
内网 API 网关或微服务间调用：推荐 4h（14400 秒）。内网延迟低、可信度高，且调用方多为固定 SDK 或代理程序。设为 4h 后，单个客户端整日基本只需一次完整握手，TLS 相关 CPU 开销可下降 30% 以上。
必须同步检查的三项配套
缓存容量要够大：ssl_session_timeout 单独调优无效。必须启用共享缓存，例如：
ssl_session_cache shared:SSL:20m;
中小规模站点建议 10–50m；内网网关设 4h 时，至少配 shared:SSL:50m，否则缓存淘汰抖动反而拉低复用效果。
客户端得愿意复用：Chrome v119+ 默认禁用 Session ID，转而依赖 Session Ticket。此时 ssl_session_timeout 对 ticket 复用无直接影响——重点应放在：
• 开启 ssl_session_tickets on;
• 配置 ssl_session_ticket_key 并定期轮换（如每 24 小时 reload 新密钥）
别忽略 OCSP Stapling：若后端证书可能被吊销，需同步启用：
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 valid=300s;
并适当缩短 stapling 缓存时间，避免因 OCSP 查询失败导致握手阻塞。
验证是否真的生效
不能只看配置加载成功，要观测真实连接行为：
• 用 openssl s_client -connect example.com:443 -reconnect 观察输出中 Reused, SSL handshake succeeded 出现频次
• 在 Nginx log_format 中加入 $ssl_session_reused（值为 r 表示复用，. 表示新建），统计比例
• 对比调优前后 APM 或 eBPF 工具中的 TLS handshake time，下降 15% 以上才说明优化落地
