shared:SSL:10m 实现多 Worker 间 SSL 会话共享，需置于 http 块顶层、按流量预估大小（如20m起步），Windows 不支持须改用 WSL2/Linux；配合 TLSv1.3 session ticket 更稳妥。

直接用 shared:SSL:10m 就能实现多 Worker 间 SSL 会话状态共享，关键不在“怎么用”，而在于“怎么配对、怎么避坑”。它不是靠进程通信同步数据，而是所有 Worker 映射同一块操作系统级共享内存，共址读写——本质上是“一份数据，多个入口”。

必须放在 http 块顶层，不能藏在 server 里

shared 缓存必须定义在 http 块最外层，例如：

• http { ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h; ... }
• 如果只写在某个 server 块内，Nginx 会为该 server 单独建一个同名但隔离的 zone，Worker 之间依然无法共享
• 多个 server 可安全共用同一个 shared:SSL:10m，只要 name 一致，就指向同一块内存

大小要按真实流量预估，别硬套默认值

10MB 是常见起点，但不等于够用。每个会话实际占约 256–512 字节（证书链越长、TLS 版本越新，开销越大）：

Remix V2 Meta Sessions Review

审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他

下载

• 每秒新建 500 个会话 × 超时 4 小时（14400 秒）× 平均 400 字节 ≈ 288MB
• 中小规模建议从 20m 起步；高并发或长超时场景建议 50m 或更高
• 过小会导致频繁淘汰，复用率断崖下跌；过大不伤性能，但浪费内存

Windows 下这条路走不通，得换思路

官方 Windows 二进制版不支持 POSIX 共享内存，shared:SSL:10m 会直接报错启动失败：

• 只能退回到 builtin:1024，且每个 Worker 各自维护一份，互不感知
• 若必须多 Worker，复用率随进程数线性下降；唯一稳妥解法是设 worker_processes 1
• 生产环境强烈建议迁移到 WSL2 或 Linux 容器，否则 shared 模式形同虚设

配合 TLSv1.3 和 session ticket 更稳

shared 缓存对 TLSv1.2 的 Session ID 复用效果显著，但对 TLSv1.3 主要依赖 PSK：

• 仍建议保留 shared:SSL:10m，以兼容大量 TLSv1.2 客户端
• 启用 ssl_session_tickets on（默认开启），服务端下发加密票据，客户端自行携带，无需服务端查缓存
• 搭配密钥轮转（ssl_session_ticket_key 定期更新），可降低单点泄露风险