直接在http块顶层配置ssl_session_cache shared:SSL:10m、ssl_session_timeout 4h和ssl_session_tickets on可显著提升HTTPS会话复用率，节省50–100ms延迟并降低CPU消耗；必须统一声明于http块开头、禁用builtin、按真实HPS×timeout×开销精准计算缓存大小，并通过$ssl_session_reused统计、openssl测试及nginx -T验证实效。
直接在 Nginx 的 http 块顶层配置 ssl_session_cache shared:SSL:10m，配合 ssl_session_timeout 4h 和 ssl_session_tickets on，就能显著提升 HTTPS 握手复用率，节省每次约 50–100ms 延迟，降低 CPU 消耗。关键不在“配不配”，而在“配对位置、选对类型、设对大小和时长”。
必须放在 http 块顶层，不能塞进 server 里
shared 缓存是多 worker 进程共用的内存区，只有定义在 http { } 最外层才真正生效：
- 写在某个
server块里 → 缓存仅对该域名局部有效，且无法跨进程共享 → 实际复用率趋近于零 - 只用
builtin:1000→ 每个 worker 自己维护小缓存，请求被随机分发后基本无法命中 - 正确写法示例：
http {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 4h;
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ssl/ticket.key;
}
缓存大小要匹配真实新建会话速率
不是看 QPS，而是统计每秒新建 TLS 会话数（即日志中 $ssl_session_reused 值为 n 的连接数）。静态资源或 WSS 场景下，这个值常是 QPS 的 2–5 倍：
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 普通静态站点（QPS ≤ 100）：从
shared:SSL:5m起步；1MB 约存 4000 条会话（证书链短、无 OCSP Stapling） - 前端资源服务或 CDN 源站（QPS ≥ 500）：建议
shared:SSL:20m或更高 - 启用 OCSP Stapling 或证书链较长时，单条开销达 2–3KB，10m 实际仅存约 2500–3300 条，需同比例上调
- 保守估算公式：
缓存大小(MB) ≈ 新会话数/秒 × 超时(秒) × 0.5KB ÷ 1024
必须启用 session tickets 作无状态兜底
仅靠 shared 缓存无法应对突发流量洪峰。缓存满后新连接 fallback 到全握手，CPU 和延迟同步恶化：
-
ssl_session_tickets on启用 RFC 5077 票据机制，客户端自行携带加密票据，服务端无需存储 -
ssl_session_ticket_key必须是二进制文件（至少 32 字节），可用openssl rand 48 > /etc/nginx/ssl/ticket.key生成 - 建议每月轮换密钥：生成新 key 后 reload Nginx，旧 ticket 仍可解密复用
验证是否真正生效，不止看配置加载
配置写对 ≠ 效果落地，必须通过真实行为确认：
- 运行
nginx -T | grep ssl_session_cache，输出应明确显示该行位于http块中 - 在
log_format中加入$ssl_session_reused，统计 24 小时内r（reused）占比；长期低于 60% 说明缓存偏小或 timeout 过短 - OpenSSL 测试：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Reused\|Session-ID"
若多次执行出现Reused, TLSv1.2或Reused, TLSv1.3，说明复用成功
