10分钟是多数web场景兼顾内存开销与握手加速最稳妥的起点；它覆盖刷新、切标签、短暂离开等行为，复用率70%–85%，需同步配齐共享缓存、session ticket和ocsp stapling。
直接把 ssl_session_timeout 设为 10 分钟，是多数 Web 场景下兼顾内存开销与握手加速最稳妥的起点。它既避开移动端网络切换、SPA 子请求等常见复用失败场景，又不会让共享缓存长期堆积无效条目。
按业务类型选值，不盲目拉长
超时值不是越长越好，关键要匹配真实连接行为：
-
普通网站（含 PC/移动端）：设
ssl_session_timeout 10m;—— 覆盖用户刷新、切标签、短暂离开后返回，实测复用率通常达 70%–85%，内存增长可控 -
内网 API 网关或可信后端：可设
4h（即14400s），但必须配ssl_session_cache shared:SSL:50m;或更高，否则小缓存+长超时会频繁淘汰，复用率反降 -
金融、政务类登录页：保持
5m–7m，优先缩短会话泄露窗口；建议同步启用 OCSP Stapling 和 TLS 1.3 的 0-RTT ticket -
健康检查、爬虫探测等短连接密集型流量：设
1m–3m，防止缓存被大量瞬时会话占满，引发抖动
必须同步配齐三项配套机制
单独调 ssl_session_timeout 几乎没效果，以下三项缺一不可：
-
启用共享缓存：写
ssl_session_cache shared:SSL:20m;在http{}块顶层；builtin缓存不跨 worker，生产环境禁用 -
开启 Session Ticket：加
ssl_session_tickets on;并配置ssl_session_ticket_key；Chrome v119+ 后主要靠 ticket 复用，此时timeout对它无影响，重点转向密钥轮换（建议每 24 小时 reload 新 key） -
关闭老旧 TLS + 启用 OCSP Stapling：禁用 TLS 1.0/1.1；开启
ssl_stapling on;和ssl_stapling_verify on;，省掉一次证书状态查询，让复用真正快起来
验证是否真起作用，别只信配置
改完配置后，用真实连接行为判断效果：
- 命令行快速测：
openssl s_client -connect example.com:443 -reconnect，观察输出中Reused, SSL handshake succeeded是否高频出现 - Nginx 日志里加
$ssl_session_reused字段，统计日志中r（复用）与.（未复用）的比例，目标是r占比 ≥ 70% - A/B 对比指标：
TLS handshake time在 APM 工具中下降 15% 以上，说明优化落在实处
避开几个典型陷阱
这些组合看似“加强保障”，实际会拖垮复用效果：
-
timeout设 20m，但shared:SSL:5m—— 缓存容量不足，条目还没过期就被新会话挤掉，复用率不升反降 - 只依赖 Session ID 却关掉
ssl_session_tickets—— 现代浏览器早就不靠 ID 复用了，等于白调 timeout - 在多个
server{}块里重复声明ssl_session_cache—— Nginx 不报错但行为不可控，必须统一写在http{}顶层且仅一次
