调大 ssl_session_timeout 可提升 TLS 会话复用率、降低握手延迟，但需根据业务场景动态设定：普通 Web 站点推荐 10–20 分钟，移动端或 App 后端可延至 30 分钟，内网服务可达 4 小时；同时须匹配足够缓存大小、客户端支持及正确配置 session tickets 与 OCSP Stapling。
调大 ssl_session_timeout 能提升 TLS 会话复用率，减少握手延迟；但设太长会增加内存压力、延长潜在会话泄露窗口。真正的“黄金点”不是固定值，而是根据业务连接特征与客户端行为动态匹配的区间。
普通 Web 站点：10–20 分钟最稳妥
覆盖用户刷新页面、切换标签页、短暂离开后返回等典型行为。这个范围既避开移动端网络切换（如 Wi-Fi 切蜂窝）导致 session ID 失效的高频场景，又不会让 shared 缓存长期堆积无效条目。若使用 shared:SSL:20m，10–20 分钟能维持约 60%–85% 的复用率，实测首屏加载时间平均降低 80–150ms。
- 设为
10m：适合内容更新频繁、用户停留时间短的资讯类站点 - 设为
20m：适合登录态较长、含表单交互的 SaaS 或后台系统 - 避免设为
1h+：除非你确认缓存容量充足（如shared:SSL:50m），否则易因淘汰抖动反降低复用效果
移动端或 App 后端：可延至 30 分钟
App 客户端通常复用 TCP 连接更积极，且网络环境波动大。30 分钟能更好适配后台保活、推送唤醒后的 HTTPS 请求。但前提是：
-
ssl_session_cache至少配到shared:SSL:30m（约支持 12 万会话） - 客户端明确支持 Session ID 复用（部分旧版 Android WebView 仍依赖此机制）
- 监控
$ssl_session_reused日志变量，确保复用率稳定在 75% 以上
内网服务或 API 网关：4 小时有实际价值
内网延迟低、可信度高，且调用方多为固定 SDK 或代理程序。设为 4h（14400 秒）后，单个客户端在整日工作周期内基本只需一次完整握手。这对高并发内部调用（如微服务间通信）意义明显——CPU 花在 TLS 上的时间可下降 30% 以上。
- 必须配合足够大的缓存，例如
shared:SSL:100m - 建议关闭
ssl_session_tickets，专注服务端缓存管理，避免 ticket 密钥轮换复杂度 - 注意：若后端证书可能被吊销，需同步启用 OCSP Stapling 并缩短 stapling 缓存时间
别只盯 timeout，三个协同点决定成败
ssl_session_timeout 单独调优效果有限。它真正起作用的前提是：
-
缓存必须开启且够大：
ssl_session_cache shared:SSL:20m是生产底线，builtin缓存不跨 worker，基本不用 -
客户端得愿意复用：Chrome v119+ 默认禁用 Session ID，转而依赖 ticket；此时
ssl_session_timeout对 Chrome 几乎无影响，重点该放在ssl_session_ticket_key轮换和ssl_session_tickets on -
别被 handshake timeout 干扰判断：
ssl_handshake_timeout控制的是“握手进行中”的等待时长，和 session 复用无关；设太短（如 2 秒）反而会掩盖真实复用问题，造成误判
