WSS高并发下必须用shared:SSL:20m全局缓存、ssl_session_timeout 3m–5m、ssl_session_tickets on并轮换ticket.key，才能有效提升会话复用率至70%以上，降低P95握手延迟30%–50%。
WSS（WebSocket over TLS）在高并发场景下，每次连接建立都需完整 TLS 握手，若未启用有效会话复用，CPU 和延迟会急剧上升。优化核心不是“开开关”，而是让 ssl_session_cache 与 WSS 的连接特征精准匹配——短生命周期、高频重连、客户端分散。
必须用 shared 缓存，且统一声明在 http 块顶层
WSS 客户端（尤其是浏览器、小程序、IoT 设备）重连随机分发到不同 worker 进程。builtin 缓存每个 worker 独立，复用率常低于 15%；shared 缓存才能跨进程共享状态：
- 在
nginx.conf的http { }块内全局配置，不要写在某个server或location里 - 推荐起步值：
ssl_session_cache shared:SSL:20m（20MB 可支持约 10 万–14 万个槽位，适配中高并发 WSS 网关） - 禁用
builtin单独使用：它对 WSS 几乎无效，混用如builtin:500 shared:SSL:20m中的 builtin 部分基本闲置
超时时间要贴合 WSS 行为，别套用 HTTPS 页面逻辑
WSS 连接不像网页请求有长 idle 期，而是频繁断连重连（心跳失败、网络切换、App 切后台），真实复用窗口集中在 60–180 秒内：
Remix V2 Meta Sessions Review
下载
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
- 设
ssl_session_timeout 3m或5m比默认 5 分钟更合理，也比 4 小时更高效 - 过长（如 30m+）会导致大量已断连的会话长期占槽，降低新鲜度和命中率
- 若业务含长保活场景（如实时协作白板），可设
10m，但需同步加大缓存至shared:SSL:40m
强制启用 session tickets，应对突发重连洪峰
WSS 在弱网或移动场景下易出现瞬时重连高峰，shared 缓存满后新连接直接 fallback 全握手。session tickets 是无状态兜底：
- 必须开启：
ssl_session_tickets on - 必须配密钥：
ssl_session_ticket_key /etc/nginx/ssl/wss-ticket.key（用openssl rand 48 > wss-ticket.key生成） - 密钥建议每两周轮换一次：reload Nginx 后旧 ticket 仍可解密，新连接用新密钥，平滑过渡
- tickets 与 shared 缓存并行生效——tickets 服务新重连，shared 缓存服务稳定复用，双通道稳住 P95 握手延迟
验证是否真起作用，不靠配置靠数据
配置正确 ≠ 复用发生。WSS 流量结构特殊，需针对性验证：
- 日志中加
$ssl_session_reused字段，统计r（reused）占比：稳定高于 70% 才算有效 - 用 OpenSSL 模拟 WSS 握手行为：
openssl s_client -connect ws.example.com:443 -servername ws.example.com -reconnect 2>/dev/null | grep "Reused"，连续执行 10 次，至少 7 次出现Reused, TLSv1.3或Reused, TLSv1.2 - 监控
ssl_handshake_time：开启后 P95 应下降 30%–50%，若延迟跳变或 CPU 持续冲高，大概率是缓存溢出或票据未生效
