必须在http块顶层协同配置ssl_session_cache与ssl_session_timeout：超时时间按客户端行为设为5m–4h，缓存大小按“每秒新建会话数×超时秒数×0.5KB÷1024”精准计算，并启用ssl_session_tickets on及密钥轮换。
直接在 http 块顶层配置 ssl_session_timeout 和 ssl_session_cache，二者必须协同设置才有效——超时时间决定会话保留多久，缓存大小决定能存多少条，缺一不可。
超时时间要贴合真实访问节奏
不是越大越好，需匹配典型客户端行为：
-
普通网站（含手机浏览器）：设为
10m（600 秒），覆盖页面刷新、标签切换、短暂离开后返回，复用率通常达 70%–85% -
移动端 App 或长周期 API：可设
15m–30m，适配唤醒重连与网络切换场景 -
内网网关或微服务调用：推荐
4h（14400 秒），环境稳定且调用方固定，一天基本只需一次完整握手 -
金融/政务类高敏登录页：保持
5m–10m，安全优先，缩短会话泄露影响窗口
缓存大小得按流量精准算出来
不能拍脑袋填 10m，公式是：
缓存大小（MB）≈ 每秒新建 TLS 会话数 × 超时秒数 × 0.5 KB ÷ 1024
- 每秒新建会话数 ≠ QPS，要从日志中统计
$ssl_session_reused为n的连接频次，或用stub_status辅助估算 - 单条会话占用约 256–600 字节；若启用 OCSP Stapling 或证书链较长，可能达 2–3 KB，需按比例上调
- 例如：峰值 800 新会话/秒 × 10 分钟（600 秒）× 0.5 KB ≈ 234 MB → 建议配
shared:SSL:256m
必须放在 http 块顶层且只声明一次
错放位置等于没配：
-
ssl_session_cache shared:SSL:256m必须写在http{}块开头，与server{}并列，不能嵌套在某个server内 - 禁用
builtin缓存——它不跨 worker 进程，生产环境无效 - 重复声明同名缓存（如多个
server都写shared:SSL:10m）会导致行为不可控，仅最后一个生效
还得配上会话票据和验证手段
光靠共享缓存不够，现代客户端（尤其 Chrome、iOS）更依赖 Session Ticket：
- 开启
ssl_session_tickets on，并指定密钥：ssl_session_ticket_key /etc/nginx/ssl/ticket.key -
ticket.key必须是二进制文件，至少 32 字节（可用openssl rand 48 > ticket.key生成） - 每月轮换一次密钥：生成新 key 后 reload Nginx，旧票据仍可解密复用
- 通过日志变量
$ssl_session_reused监控复用率，目标 ≥ 70%；低于此值说明配置未生效或容量不足
