关键是要按“峰值每秒新建会话数×有效会话寿命×1.5冗余系数÷单槽字节数”精准计算shared:ssl缓存大小，如1800 hps×120秒×1.5÷144字节≈43mb，起步配48m；必须唯一声明于http块顶层，禁用builtin，启用session_tickets，并通过$ssl_session_reused等指标验证复用率≥75%。
要让单机 Nginx 平滑承载十万级并发用户的 HTTPS 状态缓存，关键不是堆内存，而是让 ssl_session_cache 的 shared 缓存大小精准匹配真实握手流量特征——它必须足够容纳「峰值每秒新建会话数 × 有效会话寿命」所对应的槽位总量，同时避免锁竞争与内存碎片。
先算清楚你需要多少槽位，再配多大共享内存
Nginx 的 shared:SSL:10m 不是“能存 10MB 数据”，而是分配一块 10MB 共享内存，由 OpenSSL 按固定槽大小切分（OpenSSL 1.1.1+ 约 144 字节/槽）。
10MB ≈ 72,000 个槽位。每个槽对应一个完整 TLS 握手生成的会话（session ID + 密钥材料），复用不占新槽。
十万级并发 ≠ 十万级每秒新建会话。实际 HPS（Handshakes Per Second）往往远低于并发连接数：
- 若平均连接保持 60 秒，10 万并发 ≈ 峰值 1600–2000 新会话/秒（按 5 秒滑动窗口取最大值）
- 若启用了 OCSP Stapling 或长证书链，单槽开销升至 2–3 KB，实际槽位数锐减（10m 可能只剩 3000–4000 条）
推荐按公式反推：
所需槽位数 ≈ HPSpeak × Teffective × 1.5
其中：
- HPSpeak：压测或日志中统计的
$ssl_handshake_time非空出现频次（单位：次/秒）- Teffective：实测有效会话寿命，通常为 60–180 秒（远短于
ssl_session_timeout）- 1.5 是防抖冗余系数，应对瞬时脉冲
例如：实测峰值 1800 HPS，有效寿命 120 秒 → 需约 1800 × 120 × 1.5 = 324,000 槽位
按 144 字节/槽 → 至少需 324000 × 144 ÷ 1024 ÷ 1024 ≈ 43 MB
起步建议配 shared:SSL:48m，留出安全余量。
必须统一写在 http 块顶层，且只声明一次
- 写在
server { }里 → 缓存仅对该域名局部生效，无法跨 worker 共享 → 复用率趋近于零 - 多处重复声明
shared:SSL:XXm→ Nginx 静默忽略后续条目，不报错但行为不可控 - 正确位置：
http { ssl_session_cache shared:SSL:48m; ssl_session_timeout 10m; … }
验证命令：nginx -T | grep "ssl_session_cache.*shared"，输出应唯一且位于http {后、server {前
禁用 builtin，启用 session tickets 做无状态兜底
-
builtin:1000是每个 worker 私有缓存，在 SO_REUSEPORT 或 accept_mutex 调度下，客户端重连几乎不会落到同一 worker → 实际复用率 - 必须搭配
ssl_session_tickets on;和ssl_session_ticket_key /path/to/ticket.key; - ticket 机制（RFC 5077）让客户端自持加密票据，服务端无需存储；shared 缓存仅作 fallback，兼容老客户端（如 Android 4.x）和降级场景
- ticket.key 须为二进制文件（
openssl rand 48 > ticket.key），建议每月轮换
监控三项硬指标，确认没白配
- 日志加
$ssl_session_reused：长期统计值为r（reused）的比例应稳定 ≥ 75%，若持续 - OpenSSL 验证：
openssl s_client -connect example.com:443 -reconnect 2>/dev/null | grep "Reused"，多次执行应高频出现Reused, TLSv1.3 - 观察 CPU 与延迟：全握手激增时，
openssl s_time -connect example.com:443 -new -n 100测得的平均握手时间会明显上升（>150ms），而复用应 ≤ 60ms
不复杂但容易忽略
