优化 Nginx SSL 会话缓存的核心是按“每秒新建 TLS 会话数×ssl_session_timeout×单条开销”精准计算 shared:SSL 大小，统一声明于 http 块顶层、禁用 builtin、启用 session tickets，并通过 $ssl_session_reused 比例、共享内存使用率和 CPU 握手耗时三项指标验证效果。
优化 Nginx 在高可用架构中的 SSL 会话缓存，核心是让缓存既足够支撑真实流量复用，又不挤占内存、不引发锁竞争或启动失败。这不是调个数字的事，而是围绕共享机制、流量特征和协同策略的一整套配置逻辑。
按真实握手频率重算缓存容量
别用“10m”“50m”这类经验值拍脑袋填——它可能远小于实际需求，也可能浪费数倍内存：
- 统计每秒新建 TLS 会话数：不是 QPS，而是日志中 $ssl_handshake_time 非空出现的频次（或用 stub_status 中 accepts − active 估算）
- 取 ssl_session_timeout 值（推荐 600–1200 秒，即 10–20 分钟；设为 4 小时虽理论容量大，但易导致碎片升高且不满足 PCI DSS）
- 单条会话开销按场景定：普通证书链约 0.5KB；启用 OCSP Stapling 或长证书链时可达 2–3KB
- 公式：所需 MB ≈ 新建会话数/秒 × timeout（秒） × 单条开销（KB）；结果向上取整到 32m / 64m / 128m 步进（如算得 241MB，配 shared:SSL:256m）
统一声明 + 禁用 builtin + 启用 session tickets
高可用部署下多 worker 进程并行处理连接，私有缓存（builtin）基本无效，必须转向共享+票据组合：
- 只在 http { 块顶层声明一次：ssl_session_cache shared:SSL:256m;（所有 server 块中该指令全部删除）
- 禁用 builtin：像 builtin:500 shared:SSL:10m 这种混写，builtin 部分闲置，纯属干扰
- 开启无状态票据：ssl_session_tickets on; 并配密钥 ssl_session_ticket_key /etc/nginx/ticket.key;
- 现代客户端（Chrome、Firefox、Safari、iOS/Android 主流浏览器）均支持 TLS 1.3 下的票据复用，关闭它反而增加 CPU 开销
验证是否真正生效的三项指标
配置 reload 成功不等于优化落地，要靠运行时行为判断效果：
- 在 log_format 中加入 $ssl_session_reused，观察日志中 r（复用）与 .（未复用）比例；长期低于 60%，说明缓存仍偏小
- 用 free -m 或 nginx_stub_status 查看共享内存实际使用率；长期低于 20%，说明分配过量，可下调
- 对比调优前后 CPU 使用率，尤其关注 TLS 握手密集时段（如早高峰、发布后），看握手相关计算是否明显下降
配合高可用架构的协同要点
SSL 缓存只是 HTTPS 性能一环，需与整体架构对齐：
- 多个虚拟主机共用同一 shared:SSL 区域，避免各自声明造成内存膨胀
- 反向代理层统一终结 HTTPS，后端服务走 HTTP 或内网 TLS，减轻上游压力
- 搭配 keepalive_timeout（建议 30–60s）与 upstream keepalive，延长连接生命周期，减少新建会话触发频率
- 启用 OCSP Stapling 可降低证书链验证延迟，但会增大单条会话体积，计算缓存时必须纳入考量
