正确配置 ssl_session_cache shared:SSL:10m 在 http 块顶层，配合 ssl_session_timeout 4h 和 ssl_session_tickets on，可显著降低 HTTPS CPU 开销，提升会话复用率。
直接在 http 块中配置 ssl_session_cache shared:SSL:10m，配合 ssl_session_timeout 4h 和 ssl_session_tickets on，能显著降低高频 HTTPS 请求带来的 CPU 开销。核心是让客户端复用已有会话，跳过密钥交换和证书验证等耗时运算。
必须放在 http 块顶层，不能写在 server 里
每个 server 块独立加载配置，若把 ssl_session_cache 写在某个 server 中，只对该域名生效，且无法被多个 worker 进程共享。实际生产中几十个 HTTPS 站点共用一套缓存，才能发挥最大效益。
- 正确写法：
http { ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h; ... } - 错误写法：
server { ssl_session_cache builtin:1000; ... }—— 每个 worker 自己维护一份，不共享、易淘汰、复用率低 - 多域名站点无需为每个
server单独配证书路径或缓存，只要共用listen 443 ssl http2即可
shared 缓存大小要够用，别抠门
1MB 共享内存约存 4000 个会话（受证书大小、TLS 版本影响），10m 可支撑约 4 万个活跃会话。小站点起步建议 5m，中高流量建议 10–20m。
A powerful memory management system powered by ReMe that provides persistent cross-session memory, automatic user preference application, and intelligent context compression for OpenClaw.
下载
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
- 估算方法：按峰值活跃连接数 × 2KB 粗略计算所需内存
- 太小（如 1m）会导致缓存频繁淘汰，
Reused: No出现率飙升 - 不必盲目堆大，20m 已覆盖绝大多数场景；超大集群可按需扩展，但需同步监控内存使用
启用 session ticket 并轮换密钥
session ticket 是比 session ID 更高效的复用机制：客户端自己保存加密票据，服务端无需存储状态，天然支持跨 worker、跨重启复用。
- 必须开启：
ssl_session_tickets on; - 必须指定密钥文件：
ssl_session_ticket_key /etc/nginx/ssl/ticket.key; - 密钥建议每月轮换一次，用
openssl rand 48 > ticket.key生成新密钥后 reload Nginx - 禁用 ticket 却只靠 shared 缓存，对旧客户端（如 Android 4.x）可能兼容性下降
验证是否真正生效
光写配置没用，得看实际复用效果。最简单的方法是用 OpenSSL 模拟重连：
- 执行：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Session-ID\|Reused" - 如果多次输出中 Session-ID 相同，且出现
Reused, SSL handshake succeeded，说明命中缓存 - 加日志变量：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$ssl_protocol" "$ssl_cipher" "$ssl_session_reused"';，其中. = 未复用，r = 复用
