启用 ssl_session_tickets 可实现无状态 tls 会话复用，需配置 ssl_session_ticket_key 指向 48 字节密钥文件、禁用 ssl_session_cache、支持多密钥轮换，并通过 openssl s_client 验证 new/reused 状态。
在 Nginx 中启用 ssl_session_tickets，核心目标是让 HTTPS 客户端复用 TLS 会话，跳过完整握手，降低延迟和服务器开销。它特别适合负载均衡、CDN 或多节点集群场景——不需要共享缓存、不依赖 Redis，靠客户端自己携带加密票据，服务端本地解密即可恢复会话。
为什么必须用 tickets 而不是 session cache
传统 ssl_session_cache shared:SSL:50m 依赖单机共享内存，多节点时必须引入外部同步组件（如 Redis），增加延迟、配置复杂度和故障风险。而 session tickets 是无状态的：Nginx 把会话上下文加密打包成票据交给客户端，只要所有节点使用同一套密钥，任意机器都能独立解密并复用——天然适配横向扩展架构。
关键配置项与注意事项
仅开启 ssl_session_tickets on 不够，必须配合密钥管理才能真正生效：
- 必须显式指定密钥文件：
ssl_session_ticket_key /etc/nginx/ticket.key；不配置该指令时，Nginx 会自动生成临时密钥，导致票据频繁失效、复用率归零 - 密钥必须是严格 48 字节的二进制随机数据，生成命令为：
openssl rand 48 > /etc/nginx/ticket.key - 密钥文件权限设为
0400，属主为 Nginx 运行用户（如www-data或nginx） - 禁用冲突机制：注释或删除所有
ssl_session_cache行，二者互斥；若同时存在，Nginx 优先走 cache，tickets 将被忽略 - 建议在每个
server块中配置，而非仅放在http块，避免被虚拟主机覆盖
生产环境必须支持密钥轮换
长期使用同一密钥存在安全风险——一旦泄露，所有历史票据都可能被解密重放。Nginx 支持最多 10 个密钥按顺序加载：
- 第一行密钥用于加密新票据（客户端下次收到的）
- 所有列出的密钥都可用于解密旧票据（保障滚动期间不中断）
- 轮换时，在配置最前面新增一行密钥路径，不要替换或删除旧行
- 示例配置：
ssl_session_ticket_key /etc/nginx/ticket.key.v20260601;<br>ssl_session_ticket_key /etc/nginx/ticket.key.v20260501;<br>ssl_session_ticket_key /etc/nginx/ticket.key.v20260401;
- 保留最近 3–4 个密钥足够，旧密钥可归档，无需立即删除
如何快速验证是否生效
不用抓包，终端两条命令即可确认：
- 首次连接（应新建会话）：
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | grep "New, TLS"→ 输出含 New 即正常 - 二次连接（带票据重试）：
openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Reused, TLS"→ 输出含 Reused 且Session-ID:为空，表示票据复用成功 - 集群环境需额外验证跨节点效果：用 curl 或浏览器反复刷新，观察不同后端 IP 是否仍能复用（可通过 Nginx 日志或
$upstream_addr确认）
