配置ssl_session_cache需置于http块顶层，使用shared:SSL:10m等共享类型并匹配业务场景的timeout（如4h），可显著提升TLS会话复用率、降低延迟与CPU开销；禁用builtin，通过nginx -T和openssl s_client验证生效。
直接配置 ssl_session_cache 并配合适当参数，能显著提升 HTTPS 二次握手（session resumption）成功率，减少完整 TLS 握手次数，降低延迟与 CPU 开销。关键不在“加不加”，而在“加对位置、选对类型、设对大小和时长”。
必须放在 http 块顶层，不能写在 server 内
该指令只在 Nginx 的 http 上下文中生效，且必须是全局共享配置：
- 写在某个
server块里 → 缓存仅对该虚拟主机生效，且各 worker 进程无法共享 → 复用率极低 - 正确位置示例（nginx.conf 的 http { ... } 区域内）：
ssl_session_cache shared:SSL:10m;ssl_session_timeout 4h; - 验证是否加载成功：运行
nginx -T | grep ssl_session_cache，输出应明确显示该行位于 http 块中
务必使用 shared 类型，禁用 builtin
builtin 是每个 worker 独享的缓存，容量小（通常仅 1–2KB）、不共享、易失效；高并发下几乎无法复用：
- shared 缓存由所有 worker 共用同一块内存区，会话可跨进程复用
- 命名格式为
shared:name:size，如shared:SSL:10m表示创建名为 SSL、大小为 10MB 的共享内存区 - 10MB 可容纳约 4 万–8 万个会话（取决于证书长度和协议版本），中小业务够用；日均 UV 50 万以上建议调至 20m–50m
时长与大小需匹配业务场景
缓存不是越大越久越好——过期策略和容量要贴合用户行为：
- 文章/资讯类站点（单次访问短、复访率低）：设
ssl_session_timeout 10m–30m，缓存 1–5m 即可 - 后台系统、收银终端（操作频次高、单次会话短）：设
ssl_session_timeout 30m–2h，缓存 5–10m 更稳妥 - 在线游戏、实时协作类（长连接、高并发、低延迟敏感）：设
ssl_session_timeout 2h–4h，缓存至少 10m，避免握手卡顿掉线 - 注意：TLSv1.3 主要依赖 PSK 恢复，
ssl_session_cache对其影响减弱，但仍需保留以兼容 TLSv1.2 客户端
验证是否真正生效
启动不报错 ≠ 缓存被使用。实测确认更可靠：
- 用 OpenSSL 模拟复用：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Reused\|Session-ID"
若出现Reused, TLSv1.3或Reused, TLSv1.2，说明复用成功 - 观察握手耗时变化：对比开启前后平均
ssl_handshake_time（可通过 access_log 中$ssl_handshake_time变量记录） - Nginx 日志无直接 hit/miss 统计，但若频繁出现
SSL_do_handshake() failed或大量完整握手日志，则说明缓存未起效或配置错误
