答案是复用率低于85%即表明SSL会话缓存不足，需按“每秒新建会话数×超时时间×单条开销”精准计算shared缓存大小，且必须统一声明于http块顶层、禁用builtin、启用session_tickets，并通过$ssl_session_reused实时验证。
直接看 $ssl_session_reused 变量统计复用率，低于 85% 就该怀疑 SSL 会话缓存不足；再结合每秒新建会话数、超时时间与单条开销算出真实所需大小，而不是凭经验填 “10m”。
盯住复用率指标，别只看错误日志
SSL 会话缓存过小不会报错，只会默默挤掉旧会话，导致客户端被迫全握手。关键指标是 $ssl_session_reused —— 它在 access_log 中可直接记录：
- 加到 log_format 里：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_session_reused'; - 观察线上日志中
$ssl_session_reused值：为.表示未复用（全新握手），为y或r才表示复用成功 - 计算复用率 =
y+r出现次数 ÷ 总 HTTPS 请求次数；持续低于 85%，基本确认缓存瓶颈
精准算容量，不是拍脑袋填数字
真正需要的 shared 缓存大小（单位 MB）≈ 每秒新建 TLS 会话数 × ssl_session_timeout（秒）× 单条开销（KB）÷ 1024：
-
每秒新建会话数：不能等同于 QPS。从 access_log 统计
$ssl_session_reused=.的出现频次（每秒多少次），或用 stub_status 的accepts - active差值粗估 - ssl_session_timeout：建议设 600–1200 秒（10–20 分钟）。设太短（如默认 300 秒）复用窗口小；设太长（如 4 小时）易碎片化且不合规
-
单条开销：普通证书链约 256–512 字节；若启用 OCSP Stapling 或含多个中间 CA，可能达 2–3 KB。实测可用
openssl s_client -connect your.com:443 -servername your.com -reconnect -no_ssl3 | wc -c估算
检查配置位置与模式是否生效
缓存必须写对地方、禁用干扰项，否则再大也白搭：
- 必须声明在
http块顶层，且全局只出现一次：ssl_session_cache shared:SSL:256m; - 禁用
builtin：它单进程独占、无法跨 worker 共享，高并发下完全无效 - 启用 session tickets（默认开启）：它不依赖服务端缓存，可作为补充，但不能替代 shared 缓存
- 确认没被子块覆盖：server 或 location 里不能再重复定义
ssl_session_cache，否则会覆盖 http 层设置
验证是否真起效，而非“看起来配了”
光改配置不验证，等于没调。上线后快速确认三点：
- 查 Nginx 启动日志：应有
using shared memory zone "SSL"提示，无则配置未加载 - 用
nginx -T | grep ssl_session_cache确认最终生效的值，排除 include 覆盖或语法错误 - 压测对比：相同流量下，开启合理缓存后，
$ssl_session_reused=.频次应明显下降，CPU 的 crypto 相关耗时（如%sys）同步降低
