当 Nginx ssl_session_cache 共享内存区满时，新 TLS 会话无法缓存，导致全握手、CPU 升高、延迟上升；可通过 $ssl_session_reused、缓存命中率、共享内存统计及间接指标（如握手耗时、RSS 增长）确认溢出，并按公式 cache_size ≈ (new_sessions_per_sec × timeout_sec × 0.5KB) 合理预估大小，建议启用 session tickets 作为无状态补充并建立监控告警闭环。
当 Nginx 的 ssl_session_cache 共享内存区（如 shared:SSL:10m）被填满，新 TLS 会话将无法缓存，导致 SSL/TLS 握手退化为全握手（full handshake），CPU 升高、延迟上升、并发能力下降。这不是报错，但影响隐蔽且严重。
如何确认是否发生共享内存溢出
关键指标是 Nginx 内置变量 $ssl_session_reused 和监控日志中的缓存命中率；更直接的是检查共享内存使用状态：
- 执行
nginx -T | grep ssl_session_cache确认配置中启用的共享内存名称和大小（如shared:SSL:10m） - 用
nginx -s reload后，运行kill -USR1 $(cat /var/run/nginx.pid)触发主进程输出共享内存统计（需开启debug日志级别或使用第三方工具） - 更实用方式：启用
stub_status模块并配合自定义指标采集 —— 虽不直接暴露 session cache 使用率，但可观察Accepts/Handled/Requests偏差、TLS 握手耗时突增等间接信号 - 通过 OpenResty 或 Nginx Plus 可直接获取
ssl_session_cache_misses、ssl_session_cache_hits等指标；社区版 Nginx 需依赖nginx-module-vts或 Prometheus Exporter（如nginx-prometheus-exporter）间接估算
合理设置 ssl\_session\_cache 大小与超时
默认 10m 对中小流量够用，但高并发 HTTPS 场景下极易不足。每个缓存条目约占用 256–512 字节（取决于证书链长度和 TLS 版本），按每秒 1000 新会话、平均会话存活 4 分钟计算，峰值需约 1000 × 240 × 0.5KB ≈ 120MB —— 显然远超 10m。
- 根据业务 QPS 和平均会话生命周期预估：公式近似为
cache_size ≈ (new_sessions_per_sec × timeout_sec × 0.5KB)，向上取整到 10m 或 50m 步进 -
ssl_session_timeout不宜设过长（如 4h），建议 5–30 分钟；过长会导致内存长期被无效会话占用，且现代客户端重连频繁，短超时反而提升缓存周转率 - 避免多个 server 块重复定义同名 shared cache（如都写
shared:SSL:10m），Nginx 会合并为同一区域，但若配置不一致可能引发未定义行为；统一在 http 块顶层定义一次即可
启用会话票证（Session Tickets）作为补充机制
session cache 是服务端缓存，有内存瓶颈；session tickets 是服务端加密后下发给客户端存储的会话信息，服务端无状态，不占共享内存。
- 添加配置：
ssl_session_tickets on;（默认开启），并设置密钥轮转：ssl_session_ticket_key /etc/nginx/ticket.key;（至少一个 80 字节随机二进制文件） - 注意兼容性：旧客户端（如 Android 4.4 以下、Java 7u95 前）不支持 tickets，此时仍依赖 session cache；建议保留 cache + tickets 双机制
- 密钥需定期轮换（如每周），并确保多 worker 进程、多台 Nginx 实例使用相同 ticket key 才能跨进程/节点复用
监控与告警建议
不能只看「有没有报错」，要建立量化基线：
- 采集
ssl_session_cache_hits / (ssl_session_cache_hits + ssl_session_cache_misses)比率，持续低于 85% 即预警；低于 70% 视为严重 - 结合
$ssl_protocol和$ssl_cipher日志字段，分析是否特定 TLS 版本（如 TLSv1.3）占比突增 —— 因 TLS 1.3 默认禁用传统 session cache，仅用 tickets，此时 miss 率天然升高，属正常现象 - 用
log_format记录$ssl_session_reused（值为.<code> 或 <code>s表示复用，.表示未复用），通过日志分析工具（如 Loki + Grafana）统计复用率趋势 - 对共享内存使用率无直接指标时，可用
ps aux | grep nginx观察 worker 进程 RSS 是否随流量增长异常攀升（间接反映 cache 压力）
本质上，这不是故障修复，而是容量规划与协议演进下的常态优化。TLS 1.3 普及后，传统 session cache 重要性下降，但 tickets 配置不当或 key 管理缺失，同样导致性能回退。关键在监控闭环 + 配置适配。
