SSL会话缓存不能在server块中“严格”配置，必须统一声明于http块顶层，使用shared:SSL:Nm配合ssl_session_timeout、ssl_session_tickets on及安全协议，通过$ssl_session_reused和openssl测试验证复用率≥70%。
在 Nginx 的 server 块中配置“严格的 SSL 会话重用缓存”这个说法本身存在概念偏差——SSL 会话缓存无法真正“严格”限定在单个 server 块内生效，也不推荐这么做。因为真正的会话复用依赖跨 worker 进程共享状态，而 shared 类型缓存必须声明在 http 块顶层才能被所有 worker 共享；若强行写在 server 块里，实际效果等同于局部、低效甚至无效的复用。
为什么不能只在 server 块里配“严格缓存”
• ssl_session_cache shared:SSL:10m 若放在 server 块中，Nginx 会为每个 server 创建独立缓存区，不同 server 之间不互通，多个 worker 进程也无法共享，导致复用率趋近于零
• 写成 builtin:1024 更不可取：它仅限单个 worker 使用，高并发下极易失效，且不支持跨进程复用
• “严格”不等于“隔离”，HTTPS 会话复用的目标是提升复用率、降低握手开销，隔离反而违背设计初衷
真正有效的做法：全局统一 + 精准控制
在 http 块开头统一声明缓存，并通过其他参数实现行为上的“严格性”：
-
统一声明缓存：
http {<br> ssl_session_cache shared:SSL:20m;<br> ssl_session_timeout 10m;<br> }
名称SSL必须一致，大小按真实新建会话速率 × 超时 × 0.5KB 计算（例如 1000 new/sec × 600s × 0.5KB ≈ 300MB → 配shared:SSL:512m） -
关闭非必要模式：删掉所有
server块里的ssl_session_cache，禁用builtin和off，避免干扰 -
启用票据兜底并强化安全：
ssl_session_tickets on;<br> ssl_session_ticket_key /etc/nginx/ticket.key;
密钥需为 48 字节二进制文件（openssl rand 48 > ticket.key），权限设为600，属主为 nginx 用户 -
收紧协议与加密套件：
ssl_protocols TLSv1.2 TLSv1.3;<br> ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256;<br> ssl_prefer_server_ciphers off;
禁用 TLS 1.0/1.1，使用现代、前向安全的加密组合
如何验证是否“严格生效”
不看配置是否加载成功，而看实际连接行为：
- 日志中加入
$ssl_session_reused变量，长期观察r（复用）占比应稳定在 70% 以上；若低于 60%，说明缓存偏小或票据未起作用 - 用 OpenSSL 测试：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Reused, TLS"
连续多次执行，应高频出现Reused, TLS handshake succeeded - 检查
nginx -V输出是否含with-http_ssl_module，确认 SSL 模块已编译启用
特殊情况处理
• 反向代理后端也走 HTTPS：必须额外开启 proxy_ssl_session_reuse on;，否则客户端到 Nginx 复用了，Nginx 到后端仍频繁握手
• 多节点集群部署：所有机器共用同一份 ticket.key，确保票据可跨节点解密
• 容器或内存受限环境：先用 free -h 和 nginx -T | grep ssl_session_cache 核对共享内存声明值是否超出可用 RAM 的 1.2 倍
