延长 ssl_session_timeout 需协同共享缓存、session ticket、ocsp stapling 等机制才有效：普通网站设600秒，app设900–1800秒，内网设14400秒，金融类设300–600秒；必须配shared:ssl:30m以上缓存，开启ssl_session_tickets并轮换密钥，启用ssl_stapling，禁用tls 1.0/1.1，通过$ssl_session_reused验证复用率≥70%。

延长 ssl_session_timeout 能提升 TLS 会话复用率，但不是简单调大就有效——它必须和共享缓存、客户端机制、证书校验协同生效。单独改这个值，大概率白忙。

按业务场景设合理超时值

超时时间要贴合用户真实连接节奏，不是越长越好：

• 普通网站（含手机浏览器）：设为 10m（600 秒）。覆盖页面刷新、标签切换、短暂离开后返回，实测复用率可达 70%–85%，首字节快 80–150ms
• 移动端 App 或长周期 API：可设 15m–30m。App 唤醒后常快速发起请求，稍长窗口更适配网络切换后的重连
• 内网网关或微服务调用：推荐 4h（14400 秒）。环境稳定、调用方固定，一天基本只需一次完整握手
• 金融/政务类高敏登录页：保持 5m–10m。安全优先，缩短会话泄露影响窗口

必须配足共享缓存容量

ssl_session_timeout 只管“保留多久”，不管“能存多少”。缓存太小，条目还没过期就被挤掉，复用率反而下降：

SSL Certificate Monitor

检查一个或多个域名的 SSL/TLS 证书到期时间、颁发者、协议及 SAN 信息，用于应要求检查证书、监控到期或验证 HTTPS 等场景。

下载

• 禁用 builtin 缓存——它不跨 worker 进程，生产环境无效
• 必须用 shared:SSL:20m 或更高（如 shared:SSL:50m）
• 20MB 共享内存约支持 8–10 万个会话；高流量站点建议起步 30m～50m
• 避免“timeout 长 + cache 小”组合，例如设了 20m 却只配 5m 缓存，会导致频繁淘汰抖动

同步启用并管理 Session Ticket

Chrome v119+、Safari、Firefox 等主流浏览器已默认禁用 Session ID，转向 TLS Session Ticket 复用。此时 ssl_session_timeout 对 ticket 解密无直接影响：

• 务必开启 ssl_session_tickets on;
• 配置 ssl_session_ticket_key，并至少每 24 小时轮换一次密钥，保障前向安全
• 若主要服务新浏览器，ssl_session_timeout 可适当调低至 4m–8m，重点转向 ticket 密钥管理

别漏掉 OCSP Stapling 和协议清理

即使会话成功复用，若证书吊销状态要等客户端自己查 OCSP，握手仍会阻塞：

• 启用 ssl_stapling on; 和 ssl_stapling_verify on;
• 配置可靠 DNS 解析器：resolver 8.8.8.8 valid=300s;
• 禁用 TLS 1.0/1.1，强制使用 TLS 1.2+，减少协商开销

验证是否真起作用：日志中加入 $ssl_session_reused 变量，统计 r（复用）与 .（新建）比例，目标 ≥ 70%。