启用 shared 缓存可大幅减少 TLS 握手耗时，节省约 50–100ms（1 个 RTT），尤其利于高频短连接的 CSS/JS/图片等静态资源；因其支持跨 Worker 进程复用，避免 builtin 模式下因请求分发随机导致的重复全握手。
直接用 ssl_session_cache shared 替代默认不启用或仅用 builtin 的配置，能大幅减少 TLS 握手耗时——实测可节省 1 个完整 RTT（约 50–100ms），对 CSS、JS、图片等高频短连接资源效果尤其明显。
为什么静态资源特别受益
静态资源请求通常并发高、连接短、复连频繁（如页面加载多个 JS/CSS），每次完整 TLS 握手都会带来额外延迟。而启用会话复用后，客户端重连时只需简短握手（Session ID 或 ticket 验证），跳过密钥交换与证书传输环节。
- 浏览器加载一个含 20 个 HTTPS 资源的页面，若无复用，可能触发 20 次完整握手；启用后多数复用，仅首次或超时后需完整握手
- 海外用户受高 RTT 影响更大，省下的每个 RTT 对 TTFB（Time to First Byte）改善显著
- CDN 回源到 Nginx 时也走 HTTPS，同样适用——尤其当 CDN 节点密集复连源站
shared 缓存大小怎么设才合适
不靠经验拍脑袋，按「每秒新建 HTTPS 连接数 × 会话平均存活时间 × 单条内存开销」估算：
Remix V2 Meta Sessions Review
下载
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
- 普通静态站点（QPS ≤ 100）：从
shared:SSL:5m起步，1MB 约存 4000 条会话（证书链短、无 OCSP Stapling 时） - 前端资源服务或 CDN 源站（QPS ≥ 500）：建议
shared:SSL:20m，避免因淘汰过快导致复用率下跌 - 若证书链长或启用了 OCSP Stapling，单条会话可达 3–4KB，此时 10m 实际仅存约 2500–3300 条，需同比例上调
必须配合的关键参数
只配 ssl_session_cache 不够，还需三项协同生效：
-
ssl_session_timeout 4h：设为较长值（别用默认 5m），给客户端足够窗口复用；注意这不是强制保质期，而是“最后活跃起 4 小时内可复用” -
ssl_session_tickets on：启用 RFC 5077 会话票据，比 Session ID 更轻量、不依赖服务端存储，适合横向扩展场景 -
ssl_session_ticket_key /path/to/ticket.key：指定 32 字节以上二进制密钥，建议每月轮换，防长期密钥泄露引发会话重放
验证是否真正生效
别只看配置有没有加载，要观察真实复用行为：
- 用
nginx -T | grep ssl_session_cache确认配置已生效 - 在日志中添加
$ssl_session_reused变量，统计 24 小时内r（reused）占比；长期低于 60% 说明缓存太小或 timeout 过短 - 用 OpenSSL 测试：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Session-ID\|Reused"，多次执行看是否出现Reused: YES
