直接影响https并发能力的是每秒新建tls会话（hps）与ssl_session_cache的匹配度；需按峰值hps×有效会话寿命×单槽开销×冗余系数精准计算shared缓存大小，统一配置在http块顶层，启用session tickets作无状态兜底，并依业务场景设定超时。
直接影响 HTTPS 并发能力的不是连接数本身，而是每秒新建 TLS 会话（HPS）与服务端缓存能否匹配。配错 ssl_session_cache 不会报错，但会导致大量连接退化为全握手，CPU 突增、延迟跳变、实际并发上限被隐性压低。
缓存大小必须按真实 HPS 而非并发数计算
十万级并发 ≠ 十万级每秒新建会话。若平均连接存活 60 秒，峰值仅需约 1600–2000 新会话/秒；若启用了 OCSP Stapling 或长证书链，单条会话内存开销可达 2–3 KB，10MB 缓存实际只能存 3000–4000 条。
- 精准公式：所需共享内存 ≈ 峰值 HPS × 实测有效会话寿命 × 1.5（冗余）× 单槽字节数 ÷ 1024 ÷ 1024
- OpenSSL 1.1.1+ 默认约 144 字节/槽，但含 OCSP 或多证书时需实测占用
- 例：1800 HPS × 120 秒 × 1.5 × 144 字节 ≈ 43 MB → 建议起步配
shared:SSL:48m
必须声明在 http 块顶层，且仅一次
写进某个 server 块里，它就变成该域名私有、无法跨 worker 共享——复用率趋近于零。多个站点共用同一块 shared:SSL 才能摊薄管理开销、提升整体命中率。
- ✅ 正确：
http { ssl_session_cache shared:SSL:48m; ... } - ❌ 错误：
server { ssl_session_cache shared:SSL:10m; }（每个 server 各建一块，互不通信） - ⚠️ 多个 server 若都引用
shared:SSL，必须确保名称一致、参数统一，否则行为未定义
必须禁用 builtin，启用 session tickets 做无状态兜底
builtin:1000 是每个 worker 私有缓存，在 SO_REUSEPORT 或 accept_mutex 调度下，客户端重连几乎不会落到同一 worker，实测复用率常低于 5%。
-
ssl_session_tickets on让客户端自持加密票据，服务端无需查表、不占缓存空间，天然支持跨 worker / 跨重启 / 跨机器 - 必须配合
ssl_session_ticket_key /path/to/ticket.key（二进制文件，≥32 字节，可用openssl rand 48 > ticket.key生成） - 建议每月轮换密钥，reload 后旧票据仍可解密，新连接自动使用新密钥
超时时间要贴合业务访问节奏，而非设得越长越好
设 ssl_session_timeout 4h 看似保险，实则易导致缓存长期被无效会话占据，周转率下降，反而降低并发承载力。
- 前端静态资源（JS/CSS/图片）：浏览器重连集中在 5–15 分钟内 → 推荐
10m - WSS 或移动端长连接：弱网重连窗口多在 60–180 秒 → 推荐
3m～5m - API 网关或用户停留型服务：可设
20m～30m，但缓存大小需同步加大
不复杂但容易忽略：缓存满不会报错，但 $ssl_session_reused 中 n（new）比例飙升、r（reused）跌破 75%，就是并发能力开始被隐性卡脖子的明确信号。
