如何根据Nginx SSL握手频率优化ssl_session_cache内存分配？

本文共计982个文字，预计阅读时间需要4分钟。

直接查看结论：

估算公式（推荐用）：所需内存(MB) ≈ 活跃并发连接数 × 2KB ÷ 1024。比如你峰值有 3 万活跃 HTTPS 连接，建议从 shared:SSL:60m 起步，再根据监控微调。

• 别把 shared 拆到每个 server 块里：Nginx 不支持 per-server shared cache，重复声明会导致只有最后一个生效，且 worker 间无法共享
• 避免混用 builtin 和 shared：builtin:1000 是每个 worker 私有缓存，高并发下各 worker 缓存不互通，复用率极低，基本等于没开
• 注意 TLS 1.3 的影响：它默认禁用 session ID 复用，主要靠 ticket；此时 shared 缓存压力反而下降，但 ssl_session_ticket_key 轮换和密钥安全性变得更关键

为什么 openssl s_client -reconnect 显示 Reused=No，但实际流量里复用率很高

因为 openssl s_client 默认不发 SNI（-servername 才发），而现代 Nginx 多数配置了 SNI 分流，导致每次连接被路由到不同虚拟主机或 SSL 上下文，session ID/ticket 无法匹配。这不是缓存失效，是测试方法错了。

真正验证复用率，得看生产日志或实时指标：

• 在 log_format 中加入 $ssl_session_reused 变量，统计 r（复用）与 .（未复用）比例
• 用 nginx -T | grep ssl_session_cache 确认配置已加载且无语法覆盖（比如 http 块和 server 块都写了，后者会覆盖前者）
• 观察 Active connections 与 accepts handled requests 的比值：如果连接数远低于请求数，说明 keepalive + session 复用已在起效

ssl_session_timeout 设太长，shared 内存却不够，会发生什么

不是“超时后自动清理”，而是“缓存满就强制淘汰最老条目”——哪怕它还没超时。结果就是：你设了 ssl_session_timeout 4h，但因 shared:SSL:2m 太小，实际平均存活不到 30 秒，复用率断崖下跌。

典型症状包括：

• 同一客户端短时间内反复建立新 TLS 连接（Wireshark 抓包可见多次 ClientHello → ServerHello → Certificate）
• Nginx error log 出现 SSL_do_handshake() failed (SSL:) while SSL handshaking（少见，但缓存争用激烈时可能触发）
• ssl_session_reused 日志中 r 比例持续低于 30%

解决路径很直接：先放大 shared 到 10m 或更高，再逐步调大 ssl_session_timeout，而不是反过来。

多域名共用一个 shared cache，会不会互相污染或泄露会话

不会。Nginx 的 shared:SSL 缓存是按 session ID 或 ticket 加密内容索引的，不同域名下发的 session ID/ticket 互不重叠，也不会跨域复用。只要每个 server 块正确配置了各自的 ssl_certificate 和 ssl_certificate_key，就完全隔离。

但要注意两个边界情况：

• 如果你用泛域名证书（*.example.com）同时服务 a.example.com 和 b.example.com，它们可以共享缓存条目，这是预期行为，不是漏洞
• 若某域名误配了其他域名的私钥（比如 copy-paste 错了），会导致该域名握手失败，但不会污染其他域名的缓存数据

真正该警惕的是 ssl_session_ticket_key 文件权限：必须为 root:root 600，且不能被多个 Nginx 实例共用——否则 ticket 解密混乱，部分客户端会 fallback 到完整握手。