shared:ssl:10m是合理起点，实际容量按“活跃并发连接数×2kb÷1024”估算，如3万连接建议60m；过小会导致未超时条目被强制淘汰，复用率骤降。
ssl_session_cache shared 容量怎么算才不浪费也不爆内存
直接看结论：shared:SSL:10m 是大多数 HTTPS 服务的合理起点，但不能拍脑袋定——它得和你实际的并发连接数、TLS 握手频率、证书大小、协议版本（TLS 1.2 vs 1.3）对齐。1MB 约存 4000 个会话条目，但这是理想值；真实占用常在 1.5–2.5KB/条，尤其启用了 OCSP Stapling 或带完整证书链时。
估算公式（推荐用）：所需内存(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 秒，复用率断崖下跌。
抓取并分析 OpenClaw JSONL 会话日志，重建并回填代理记忆文件。适用于：(1) 模型切换后记忆不完整，(2) 验证记忆覆盖度，(3) 重建丢失记忆，(4) 通过 cron/heartbeat 自动同步每日记忆。支持简单提取及基于 LLM 的叙事摘要，并自动清理敏感信息。
典型症状包括：
- 同一客户端短时间内反复建立新 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 到完整握手。
