实际需要的 ssl_session_cache 大小应按公式 cache_size ≈ new_sessions_per_sec × timeout_sec × 0.5KB 计算，例如 1200 新会话/秒、4h 超时需约 8.5MB，建议起步配 shared:SSL:10m；必须统一配置在 http 块顶层且仅一次，同时启用 ssl_session_tickets 作无状态补充，shared 缓存作 fallback。
在高并发负载均衡场景下，ssl_session_cache 不是“开或不开”的选择题，而是“怎么配才不拖垮性能又不浪费内存”的实操问题。核心矛盾在于：缓存太小，握手复用率暴跌，大量全握手压垮 CPU；缓存太大，占用过多共享内存，挤占其他关键模块资源，还可能因锁竞争反而降低吞吐。
按真实流量算大小，别靠经验猜
缓存容量必须基于每秒新建会话数（不是 QPS）来计算，公式为：
cache_size ≈ new_sessions_per_sec × timeout_sec × 0.5KB
- new_sessions_per_sec 需实测：用
openssl s_client -connect example.com:443 -reconnect -servername example.com持续压测，再结合 Nginx 日志中$ssl_session_reused字段统计未复用（值为0）的连接比例反推 - timeout_sec 推荐设为
4h（14400 秒），远高于默认的 5 分钟；过短会导致用户尚未离开就过期，复用率断崖下跌 - 0.5KB 是保守均值，实际单条占用在 256–512 字节之间，受证书链长度、TLS 版本（如 TLSv1.3 PSK 更轻）、是否启用 OCSP stapling 影响
- 举例：若压测得峰值 1200 新会话/秒，配
4h超时，则理论需约 8.5MB；起步建议直接配shared:SSL:10m，高并发（＞2000 新会话/秒）应上20m或更高
shared + tickets 双机制并行，缺一不可
仅用 shared 缓存或仅用 session tickets 都有明显短板：
-
shared:SSL:10m提供进程间共享的 session ID 存储，兼容老客户端（如 Android 4.x），但依赖服务器端状态，容量不足时淘汰频繁 -
ssl_session_tickets on启用无状态票据（RFC 5077），客户端自持加密票据，服务器无需存储，大幅提升扩展性；但必须配合ssl_session_ticket_key使用 - 密钥文件（如
/etc/nginx/ssl/ticket.key）需为二进制、至少 32 字节，且建议每月轮换一次，避免长期泄露导致票据被解密重放 - 二者组合才是生产环境标配：tickets 作主力，shared 作 fallback，兼顾新老客户端与容错能力
配置位置与生效边界要严格守规矩
看似简单的一行配置，放错位置就会失效甚至引发未定义行为：
- 必须统一写在
http块顶层，且在整个配置中只出现一次；若在多个server块里重复声明，Nginx 不报错但行为不可控 - 不能放在
location或upstream块内——这些层级不支持 ssl_session_cache 指令 - 确保
ssl_session_timeout和ssl_session_tickets与 cache 配置同级、同块，否则参数不联动 - 验证是否加载成功：运行
nginx -T | grep ssl_session，确认输出包含你写的全部参数
监控复用效果比调参更重要
配置完不验证，等于没配。真正判断是否起效，看的是真实复用数据：
- 用 OpenSSL 多次连接检查：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Session-ID"，若多次输出 Session-ID 相同且含Reused: Yes，说明命中缓存 - 开启 Nginx 日志变量
$ssl_session_reused，统计日志中0（未复用）与.（复用）的比例；健康状态下复用率应稳定在 85% 以上 - 关注 handshake 时间：通过 APM 工具或自建埋点，对比配置前后 TLS 握手耗时的 P95/P99 值；若下降不明显，大概率是缓存大小或超时设置不合理
- 注意溢出无声：shared 缓存满后不会报错，只是新会话无法写入，导致全握手激增——需结合
stub_status中活跃连接数与日志复用率交叉判断
