配置ssl_session_cache的关键是平衡复用率与内存开销：生产环境必须用shared:SSL:10m（起步），配ssl_session_timeout 4h、ssl_session_tickets on及定期轮换的ticket.key。
配置 ssl_session_cache 的关键，是在高并发下让 TLS 握手复用率足够高，同时避免缓存本身吃掉过多内存或成为瓶颈。它不是越大越好，也不是越小越省——而是要匹配实际连接特征。
选对缓存类型：shared 是生产环境唯一合理选择
builtin 缓存每个 worker 进程独有一份，无法跨进程共享会话。在多 worker（如 4–8 个）的高并发 Nginx 中，客户端可能被调度到不同 worker，导致 session ID 复用失败，缓存命中率骤降。shared 缓存则由所有 worker 共享，是必选项。
- 推荐写法：
ssl_session_cache shared:SSL:10m - 10MB 是较稳妥起点：按每会话约 2KB 估算，可容纳约 5000 个活跃会话；若峰值 active connections 在 2 万左右，建议设为
shared:SSL:40m - 不要用
1m或2m：高并发下很快淘汰，复用率低于 20%，等于没开
调准超时时间：避免过早失效，也防止长期滞留
ssl_session_timeout 决定服务器端缓存条目保留多久，但它不强制客户端复用——是否复用最终由客户端行为决定。设得太短（如默认 5 分钟），对 API、前端资源等高频短连接场景几乎无效；设得太长（如 24 小时），则内存中积压大量已失效但未过期的会话。
- 推荐值：
ssl_session_timeout 4h - 4 小时覆盖大多数用户会话周期（如网页停留、App 后台保活），又不至于让冷会话长期占位
- 注意：该值需与客户端行为对齐。例如移动端 App 若后台休眠后唤醒重连，通常仍会在 timeout 窗口内尝试复用
启用并管理 session ticket：卸载服务端状态压力
session ID 方式要求服务器缓存全部会话密钥，而 session ticket 把加密后的会话状态交给客户端携带，服务端只需保管 ticket.key 即可解密复用——这对高并发尤其友好。
- 必须开启：
ssl_session_tickets on - 指定密钥：
ssl_session_ticket_key /etc/nginx/ssl/ticket.key - 密钥应为 48 字节以上二进制文件，建议每月轮换一次；可生成：
openssl rand 48 > /etc/nginx/ssl/ticket.key - 若需兼容极老客户端（如 Android 4.x），可保留 shared 缓存作为 fallback，但 ticket 仍是主力
验证与持续观察：别只看配置是否生效
配置写完不等于优化落地。真实复用率取决于流量结构和客户端分布。
- 用 OpenSSL 快速验证：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Session-ID\|Reused"，多次执行看是否出现Reused: Yes - 检查 Nginx 日志或监控：部分部署会暴露
$ssl_session_reused变量，可计入 access log 统计复用比例 - 关注内存增长：通过
nginx -T | grep ssl_session_cache确认加载，再结合ps aux --sort=-%mem | head -5观察 worker 进程 RSS 是否异常上涨
