正确配置SSL会话缓存需在http块顶层设置shared缓存、合理超时及启用tickets：ssl_session_cache shared:SSL:20m; ssl_session_timeout 10m; ssl_session_tickets on; 并配ticket密钥，确保跨进程复用与无状态兜底。
直接在 http 块顶层配置 ssl_session_cache、ssl_session_timeout 和 ssl_session_tickets，就能让重复 HTTPS 连接跳过完整握手，节省 50–100ms 延迟，显著降低 CPU 开销。关键不是“加不加”，而是位置对、类型对、大小和时长也对。
必须放在 http 块最外层，不能写进 server
shared 缓存依赖进程间共享内存，只有定义在 http { } 开头才真正生效：
- 写在某个
server块里 → 缓存仅对该域名局部有效，且无法跨 worker 进程共享 → 实际复用率趋近于零 - 只用
builtin:1024→ 每个 worker 自己维护小缓存，请求被随机分发后基本无法命中 - 正确写法示例：
http {
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 10m;
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ssl/ticket.key;
}
缓存大小要按真实新建会话速率算
不是看 QPS，而是统计每秒真正触发全新 TLS 握手的连接数（Nginx 日志中 $ssl_session_reused 值为 n 的条目）：
- 静态资源、CDN 回源、爬虫探测等场景，新建会话速率常是 QPS 的 2–5 倍
- 保守估算公式：
缓存大小(MB) ≈ 新建会话数/秒 × 超时(秒) × 0.5KB ÷ 1024 - 举例：回源峰值 3500 new/sec，超时设 600 秒 → 理论需约 820MB；实际建议配
shared:SSL:512m+ tickets 兜底 - 中小站点起步可设
10m，中高流量推荐20m–30m，超大集群可上50m，但需监控共享内存使用率
必须启用 session tickets 作无状态兜底
仅靠 shared 缓存扛不住突发洪峰或客户端不支持 Session ID 的情况（如微信内置浏览器、部分爬虫）：
-
ssl_session_tickets on启用 RFC 5077 票据机制，客户端自行携带加密票据，服务端无需查表 -
ssl_session_ticket_key必须是二进制文件（至少 32 字节），可用openssl rand 48 > /etc/nginx/ssl/ticket.key生成 - 密钥建议每月轮换：生成新 key 后 reload Nginx，旧票据仍可解密复用，新连接自动使用新密钥
超时时间要贴合业务访问特征
ssl_session_timeout 控制服务端缓存条目的保留上限，它不控制客户端行为，也不影响 ticket 机制：
- 普通 Web 站点（含移动端）：推荐
10m或20m，覆盖刷新、切标签、SPA 子请求等常见间隙 - 内网可信 API 网关：可设为
4h，实测可降握手延迟 40% 以上 - 金融/政务类系统：建议
5m–10m，兼顾安全窗口与可用性 - 短连接密集型场景（如健康检查、爬虫）：可设为
1m–3m，避免缓存膨胀
配置写对 ≠ 效果落地。务必通过 nginx -T | grep ssl_session_cache 确认该行位于 http 块中；再用 openssl s_client -connect example.com:443 -reconnect 观察是否稳定出现 Reused；最后在日志中加入 $ssl_session_reused 统计 r/. 比例，才算真正闭环。
