直接在http块顶层配置ssl_session_cache shared:SSL:10m、ssl_session_timeout 10m和ssl_session_tickets on，可显著提升HTTPS会话复用率，节省50–100ms延迟并降低CPU消耗；必须统一置于http块开头，禁用builtin，按新建会话速率×超时×0.5KB精准计算缓存大小，并定期轮换ticket.key。
直接在 http 块顶层配置 ssl_session_cache shared:SSL:10m，配合 ssl_session_timeout 10m 和 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 10m;
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ssl/ticket.key;
}
缓存大小要按真实新建会话速率计算
不是看 QPS，而是统计每秒新建 TLS 会话数（即日志中 $ssl_session_reused 值为 n 的连接数）：
- 静态资源或前端资源服务：QPS ≤ 100 时，从
shared:SSL:5m起步；QPS ≥ 500 时，建议20m或更高 - 启用 OCSP Stapling 或证书链较长时，单条开销达 2–3KB，10m 实际仅存约 2500–3300 条，需同比例上调
- 保守估算公式：缓存大小(MB) ≈ 新建会话数/秒 × 超时(秒) × 0.5KB ÷ 1024
超时时间要贴合业务访问节奏
不是越长越好，过长会导致失效条目挤占空间，降低缓存新鲜度：
- 普通 Web 站点（含移动端）：推荐
ssl_session_timeout 10m；兼顾复用率与内存效率 - 内网 API 网关等可信环境：可设为
4h，实测可降握手延迟 40% 以上 - 金融/政务类系统：建议
5m–10m，平衡安全窗口与可用性 - WSS 或长连接场景：建议
3m–10m，并同步加大缓存容量
必须启用 session tickets 并定期轮换密钥
仅靠 shared 缓存无法应对突发洪峰，tickets 是无状态兜底核心：
- 开启
ssl_session_tickets on，启用 RFC 5077 票据机制，客户端自行携带加密票据 -
ssl_session_ticket_key必须是二进制文件（至少 32 字节），可用openssl rand 48 > /etc/nginx/ssl/ticket.key生成 - 建议每月轮换一次密钥：生成新 key 后 reload Nginx，旧票据仍可解密复用，新连接自动使用新密钥
- TLSv1.3 下 PSK 与 tickets 并存，禁用 tickets 会直接失去大部分现代客户端的复用能力
