直接在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验证实效。
直接在 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块里 → 缓存仅对该域名局部有效，且无法跨进程共享 → 实际复用率趋近于零 - 重复声明多次（比如多个 server 都写）→ Nginx 静默忽略后续条目，不报错但行为不可控
- 正确位置示例：
http {<br> ssl_session_cache shared:SSL:10m;<br> ssl_session_timeout 4h;<br> ssl_session_tickets on;<br> ssl_session_ticket_key /etc/nginx/ssl/ticket.key;<br> # 后续再写 server {...}<br>}
缓存大小要匹配单站真实握手流量
不是看 QPS，而是统计每秒新建 TLS 会话数（即日志中 $ssl_session_reused 值为 0 的连接数）。静态资源密集型站点（如一个页面加载 20+ HTTPS 资源）往往 HPS 是 QPS 的 2–5 倍：
- 普通小站（QPS ≤ 100）：起步配
shared:SSL:5m；1MB 约存 4000 条短证书链会话 - 前端资源服务或 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.*shared"，输出应仅一行，且位置在http {之后、任何server {之前 - 在
log_format中加入$ssl_session_reused，统计 24 小时内r（reused）占比；长期低于 60% 说明缓存偏小或 timeout 过短 - 用
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Reused"，观察是否出现Reused, SSL handshake succeeded
