ssl_session_timeout应按业务场景差异化设置：普通网站推荐10m，内网网关可达4h（需配50m共享缓存），高敏系统设5m–7m；必须同步启用shared缓存、session ticket及客户端复用验证。
ssl_session_timeout 控制的是 Nginx 服务端缓存 TLS 会话（Session ID 或 Session Ticket 元数据）的最长时间，它直接牵扯两个核心目标：
✅ 复用越多 → 握手延迟越低、CPU 负担越小、首屏更快；
⚠️ 缓存越久 → 内存占用越高、潜在重放风险略升、过期会话堆积越多。
关键不是“设多长”，而是让 timeout 和你的真实场景对齐——既不浪费内存，也不频繁退化握手。
ssl_session_timeout 值怎么选才合理
普通 Web 站点（含移动端）：推荐设为
10m（600 秒）
覆盖用户切换标签页、短暂离开后返回、Wi-Fi 切蜂窝等常见行为；内存开销可控（约 2–3 MB/万并发），复用率提升明显。内网 API 网关或可信微服务集群：可设为
4h（14400 秒）
前提是上游连接稳定、启用了 session 复用，且ssl_session_cache容量足够（如shared:SSL:50m），否则 cache 淘汰抖动反而降低复用效果。金融、政务类高安全要求系统：建议
5m–7m
缩短会话泄露影响窗口，同时配合 TLS 1.3 的 0-RTT ticket 和 OCSP Stapling，兼顾安全与可用性。-
避免踩坑：
- 不要设
4h却只配shared:SSL:5m→ 缓存太小，timeout 再长也留不住会话； - 不要设
1m→ 移动端网络波动下几乎无法复用，每次重连都多耗 1–2 RTT； - 不要忽略
ssl_session_tickets on→ Chrome v119+ 默认禁用 Session ID 复用，只认 ticket，此时ssl_session_timeout对它基本无效。
- 不要设
必须同步配齐的三项支撑配置
启用共享缓存（不能用 builtin）：
ssl_session_cache shared:SSL:20m;
写在http { }块顶层，只声明一次；builtin缓存在多 worker 下基本失效。-
开启并管理 Session Ticket：
ssl_session_tickets on; ssl_session_ticket_key /etc/nginx/ssl/ticket.key;
ticket.key是二进制密钥（至少 32 字节），建议每月 reload 轮换一次，保障前向安全性。 确认客户端真在复用：
用openssl s_client -connect example.com:443 -reconnect -debug 2>&1 | grep "Reused"观察是否出现Reused, SSL handshake succeeded；
同时在日志中记录$ssl_session_reused，统计r（复用）占比，目标应 ≥ 85%。
不复杂但容易忽略：timeout 只是拼图一角。真正卡住复用率的，往往是缓存容量不足、ticket 未启用、或客户端压根没发 session ID。调参前先验证这三点是否就位。
