ssl_session_cache shared:ssl:10m表示预分配10mb posix共享内存供所有worker进程共用，用于缓存tls会话条目；单条大小256b–4kb不等，保守按0.5kb估算，10mb约可存4万条，实际容量取决于证书链、tls版本、ocsp stapling等因素。
这条配置 ssl_session_cache shared:SSL:10m 表示 Nginx 在主进程中预分配一块 10MB 的 POSIX 共享内存，命名为 SSL，供所有 worker 进程共同读写 TLS 会话缓存条目。它不直接控制“能承载多少并发连接”，而是决定“最多能缓存多少个已协商完成的会话”，从而影响后续连接能否跳过完整握手。
单条会话实际占多少内存？
每条缓存会话的大小不是固定的，主要取决于：
- 证书链长度（含根 CA、中间 CA、OCSP stapling 响应等）——越长占用越大，常见范围在 256 字节到 4KB 之间
- TLS 协议版本（TLSv1.2 条目略大，TLSv1.3 PSK 条目更紧凑）
- 是否启用 OCSP Stapling（开启后会额外缓存响应数据）
- 密钥交换算法（ECDHE 参数体积相对稳定，RSA 证书本身影响更大）
保守估算按 0.5KB/条 是生产环境常用基准；实测中，1MB 共享内存通常可存 约 4000 个会话（即平均 256 字节/条），所以 10MB 理论上限约为 4 万条。
10MB 能支撑多少 QPS 的会话复用？
关键不是“总连接数”，而是“每秒新建会话数”与“会话存活时间”的乘积。公式为：
所需缓存容量 ≈ 每秒新建会话数 × ssl_session_timeout（秒） × 单条平均开销
举例说明：
- 若站点峰值每秒新建 500 个 HTTPS 会话，
ssl_session_timeout 4h（14400 秒），按 0.5KB/条算：500 × 14400 × 0.5 / 1024 ≈ 3515 KB ≈ 3.4MB —— 10MB 完全够用 - 若每秒新建 2000 个会话，同样超时：2000 × 14400 × 0.5 / 1024 ≈ 14MB —— 此时 10MB 就会频繁淘汰，导致复用率下降
- 若超时设为 10 分钟（600 秒），2000 QPS 只需约 0.6MB，10MB 显得冗余
可见，10MB 是否合适，取决于你的实际新建会话速率和 timeout 设置，而非总并发连接数或 QPS 本身。
为什么不能只看“连接数”来配大小？
因为：
- 一个 TCP 连接可复用多次请求（HTTP/1.1 keepalive、HTTP/2 多路复用），但只产生一次 TLS 握手，对应一条缓存条目
- 大量短连接客户端（如移动端 App、爬虫）可能每秒建数百新会话，但活跃连接数并不高
- 缓存条目在超时前不会自动释放，即使对应连接早已关闭，“最后活跃时间”才是清理依据
也就是说，缓存压力来自“会话创建频次”，不是“当前连接数量”。这也是为什么很多 QPS 仅几百的 API 网关，仍需配 20m 甚至 50m —— 因其连接极短、重连极快。
如何验证 10MB 是否合理？
不要靠猜，用真实指标判断：
- 开启日志变量
$ssl_session_reused，统计一段时间内.r（复用）与.（新建）比例；长期低于 60%，大概率缓存太小 - 通过
nginx -T | grep ssl_session_cache确认配置生效位置（必须在 http 块顶层且唯一） - 结合
free -m或监控工具观察共享内存使用率：持续高于 90% 有溢出风险，长期低于 20% 则存在浪费 - 配合
ssl_session_tickets on作为无状态补充，降低对 shared 缓存的绝对依赖
