关键不是选参数，而是按真实流量算容量、分层用缓存、留兜底机制；需依公式cache_size(mb)≈新建tls会话数/秒×超时秒数×0.5kb÷1024精准估算，并启用session ticket作无状态兜底，双保险保障ssl复用率≥70%。
关键不是选参数，而是按真实流量算容量、分层用缓存、留兜底机制。只配 shared:SSL:10m 很可能既压不住握手压力，又白占内存。
按每秒新会话数精准算共享内存大小
缓存太小，刚存进去就被淘汰；太大，空占内存还拖慢查找。必须用这个公式估算：
- cache_size (MB) ≈ 新建 TLS 会话数/秒 × 超时秒数 × 0.5KB ÷ 1024
- 新建会话数 ≠ QPS，要从 Nginx 日志里统计
$ssl_session_reused字段：值为0才算一次全新握手 - 超时建议设
ssl_session_timeout 4h（14400 秒），默认 5 分钟会导致复用率断崖下跌 - 举例：实测峰值 800 次新握手/秒 → 800 × 14400 × 0.5 / 1024 ≈ 5.6 MB → 起步配
shared:SSL:10m，高负载（如 ≥2000 新会话/秒）直接上20m
Linux 和 Windows 必须区别对待
系统能力决定你能不能真正共享缓存：
Session Handoff
下载
创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。 时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。 关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接
-
Linux 生产环境：必须用
shared:SSL:10m（或按上式计算值），配合ssl_session_timeout 4h和ssl_session_tickets on -
Windows 官方二进制版不支持
shared，写进去会启动失败：[emerg] invalid value "shared:SSL:10m"；只能用builtin:1024，且必须设worker_processes 1，否则多进程间无法复用
启用 session ticket 做无状态兜底
仅靠 shared 缓存不够——它依赖客户端发 Session ID，而现代浏览器（Chrome、Firefox、iOS）更倾向用 session ticket：
- 开启
ssl_session_tickets on，必须配套ssl_session_ticket_key /etc/nginx/ssl/ticket.key -
ticket.key是二进制密钥文件（至少 32 字节），建议每月轮换一次，防长期泄露导致会话被重放 - session ticket 是无状态的：客户端自己加密携带会话信息，服务器不存数据，大幅降低存储压力
- 即使 shared 缓存因容量溢出失效，ticket 仍能维持大部分复用，形成双保险
验证是否真生效，别只看配置有没有加载
配置写了不等于起作用：
- 用
openssl s_client -connect example.com:443 -reconnect多次连接，观察输出中是否出现Reused, SSL handshake succeeded - 在日志中加
$ssl_session_reused字段，统计值为r（复用）的比例，稳定在 70% 以上才算有效 - 检查
free -m或 Nginx stub_status，若 shared 内存使用率长期低于 20%，说明配多了；若复用率长期低于 60%，大概率是缓存太小被频繁淘汰
