关键是让缓存容量、超时时间与会话票据协同匹配真实流量：按每秒新建TLS会话数×超时秒数×0.5KB精准计算shared缓存大小，设ssl_session_timeout为5–10分钟（静态资源）或3–30分钟（API/WSS），启用ssl_session_tickets并每月轮换密钥，且shared缓存必须唯一声明于http块顶层。
要让 ssl_session_cache 在高并发下既扛住 HTTPS 握手压力，又不拖慢响应、不浪费内存，关键不是调大数值，而是让缓存容量、超时时间、会话票据三者按真实流量节奏协同工作。
按实测新建会话速率算准缓存大小
别用 QPS 估算，得看每秒真正新建 TLS 会话数（即日志中 $ssl_session_reused 值为 n 的连接）：
- 通过 Nginx 日志或 Prometheus 抓取
nginx_ssl_handshakes_total{type="full"}的峰值速率 - 单条会话内存占用约 300–600 字节，保守按 0.5 KB 计算
- 公式：缓存大小（MB）≈ 新建会话数/秒 × 超时秒数 × 0.5 ÷ 1024
- 例：CDN 回源峰值 3500 new/sec，超时设 10 分钟（600 秒），理论需约 820 MB → 实际可配
shared:SSL:512m+ssl_session_tickets on兜底
超时时间要贴合客户端行为，不是越长越好
静态资源、前端 JS/CSS/图片等请求，浏览器重连窗口通常集中在 5–15 分钟内：
- 设
ssl_session_timeout 5m–10m比默认 5 分钟更稳，比 4 小时更高效 - 过长会导致大量失效条目滞留，挤占有效空间，降低缓存新鲜度
- API 网关或后台系统可设 15m–30m；WSS 或长连接场景建议 3m–10m 并同步加大缓存
必须启用 session tickets 并定期轮换密钥
仅靠 shared 缓存无法应对突发洪峰，tickets 是无状态兜底核心：
- 开启
ssl_session_tickets on，并指定密钥：ssl_session_ticket_key /etc/nginx/ssl/ticket.key -
ticket.key必须是二进制文件，至少 32 字节（可用openssl rand 48 > ticket.key生成） - 每月轮换一次密钥：生成新 key 后 reload Nginx，旧票据仍可解密复用，新连接自动使用新密钥
- TLSv1.3 下 PSK 与 tickets 并存，禁用 tickets 会直接失去大部分现代客户端的复用能力
shared 缓存声明位置决定是否真正生效
放错位置，再大的配置也等于没配：
-
ssl_session_cache shared:SSL:512m必须写在http{}块顶层，与server{}并列，不能嵌套在某个 server 内 - 重复声明同名缓存（如多个 server 都写
shared:SSL:10m）会导致行为不可控，只最后一个生效 - 禁用
builtin单独使用：它不跨 worker 进程，worker 数 > 1 时各缓存互不可见，复用率趋近于零 - Windows 环境不支持
shared，只能设worker_processes 1+ssl_session_cache builtin:1024，且必须关闭 tickets
不复杂但容易忽略。
