当 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（值为 . 或 s 表示复用，. 表示未复用），通过日志分析工具（如 Loki + Grafana）统计复用率趋势
• 对共享内存使用率无直接指标时，可用 ps aux | grep nginx 观察 worker 进程 RSS 是否随流量增长异常攀升（间接反映 cache 压力）

本质上，这不是故障修复，而是容量规划与协议演进下的常态优化。TLS 1.3 普及后，传统 session cache 重要性下降，但 tickets 配置不当或 key 管理缺失，同样导致性能回退。关键在监控闭环 + 配置适配。