开启会话复用需协同配置ssl_session_cache、超时策略与session tickets：cache须置于http块顶层共享，大小按真实新建会话速率×超时×0.5kb计算，tickets须启用并定期轮换密钥，超时应匹配业务重连特征。
开启会话复用不是加一行配置就能解决的事，关键在于让 ssl_session_cache、超时策略和 session tickets 三者匹配真实流量节奏。否则缓存形同虚设，CPU 该飙还是飙。
缓存必须声明在 http 块顶层，且只声明一次
shared 缓存要跨 worker 进程共享，只能写在 http { } 最外层，与所有 server 块并列。写进某个 server 里，就变成局部缓存，各 worker 互不可见，复用率基本为零。
- ✅ 正确写法：
http { ssl_session_cache shared:SSL:20m; ssl_session_timeout 10m; } - ❌ 错误写法：
server { ssl_session_cache shared:SSL:20m; }（仅对该域名生效，且不跨进程） - ❌ 更错写法：
server { ssl_session_cache builtin:1024; }（每个 worker 自己维护，高并发下几乎无复用）
按真实新建会话速率算大小，别套默认值
不是看 QPS，而是统计每秒真正触发全新握手的连接数（Nginx 日志中 $ssl_session_reused 值为 n 的条目）。静态资源、CDN 回源、爬虫探测这类场景，新建会话速率常是 QPS 的 2–5 倍。
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 公式：缓存大小（MB）≈ 新建会话数/秒 × 超时秒数 × 0.5KB ÷ 1024
- 举例：CDN 回源峰值 3500 new/sec，超时设 600 秒（10 分钟），理论需约 820MB → 实际配
shared:SSL:512m+ tickets 兜底更稳妥 - 小站点起步建议 10m，中高流量建议 20–30m；超大集群可上 50m，但要同步监控共享内存使用率
必须启用 ssl\_session\_tickets 并定期轮换密钥
仅靠 shared 缓存无法应对突发洪峰或客户端不支持 session ID 的情况（如微信内置浏览器、部分爬虫）。tickets 是无状态兜底：加密票据由客户端携带，服务端不存状态，天然支持跨 worker、跨重启、甚至跨机器（密钥同步后）。
- 开启：
ssl_session_tickets on; - 指定密钥：
ssl_session_ticket_key /etc/nginx/ssl/ticket.key;（必须是二进制文件，至少 32 字节，可用openssl rand 48 > ticket.key生成） - 轮换建议：每月 reload 一次新密钥，旧票据仍可解密复用，新连接自动使用新密钥，全程无感
- ⚠️ Windows 环境不支持 shared，只能设
worker_processes 1+ssl_session_cache builtin:1024，并关闭 tickets（兼容性差）
超时时间要贴合业务访问特征
设太短（如默认 5 分钟），用户还没关页面就过期；设太长（如 4 小时），大量失效条目长期占位，挤占有效空间。应根据客户端典型重连窗口调整：
- Web 页面类（含浏览器刷新、标签切换）：推荐
ssl_session_timeout 10m - 移动端 App 或长连接 API：可设
30m - 高频短连接（健康检查、爬虫探测）：设
2m更合适 - 启用 OCSP Stapling 或带长证书链时，单条开销可达 2–3KB，需按实测占用上调缓存大小
