必须手动配置稳定密钥，因为Apache默认每次重启生成随机内存密钥，导致集群中票据无法跨节点或跨重启解密，强制退化为全握手；密钥须为48字节二进制文件、全节点完全一致、权限600且不可热更新。
SSLSessionTickets 在分布式架构里为什么必须手动配密钥
Apache 2.4.8+ 默认开启 SSLSessionTickets on，但默认用的是每次启动随机生成的内存密钥；集群中只要任意一台 Apache 重启，它发出去的票据就再也无法被自己或其他节点解密——客户端带着旧票据重连，服务端只能拒绝，退化为全握手。这不是“没生效”，而是票据生命周期和密钥一致性完全失控。
关键点在于：SSLSessionTicketKeyFile 必须指向一个**稳定、二进制、跨节点完全一致**的密钥文件，且不能由 Apache 自动生成或热更新。
- 密钥必须是 48 字节原始二进制（
openssl rand -out /etc/ssl/private/ticket.key 48），不能 base64、hex 或文本编码 - 所有负载节点（包括灰度机）必须用 同一份文件，建议通过 Ansible/Chef 同步，或挂载共享只读存储（如 NFSv4 + noac）
- 文件权限必须为
600，属主为 Apache 运行用户（www-data或apache），否则模块加载失败且无明确报错 - 不要在虚拟主机配置里重复写
SSLSessionTickets off—— 它会覆盖全局设置，导致部分域名失效
多层代理下 SSLSessionTickets 失效的典型链路断点
常见现象：单机测试正常，上线后移动端 TLS 重连仍慢，抓包发现 ClientHello 带 session_ticket 扩展，但 ServerHello 没回 NewSessionTicket。根本原因往往不在 Apache，而在前端代理层。
- 如果 Nginx / ALB / CLB 做了 TLS 终结（即 HTTPS → HTTP），那么
session_ticket扩展在到达 Apache 前已被剥离，Apache 根本收不到票据请求 - 若代理透传 TLS（如 Nginx 的
ssl_pass_through on或四层 TCP 代理），但未配置proxy_ssl_session_reuse off，Nginx 自身会复用上游连接，掩盖 Apache 票据行为 - CDN（如 Cloudflare）启用“Full (strict)”模式时，默认不透传票据扩展；需确认其是否支持并开启 “TLS Session Resumption” 或等效开关
- 检查 Apache 日志是否有
[ssl:warn] [pid] AH01906: ... unable to decrypt session ticket—— 这说明票据抵达了，但密钥不匹配或损坏
验证 SSLSessionTickets 是否真正起效的实操方法
不能只看配置是否存在，要从客户端行为和协议层双向确认。DevTools 和 Wireshark 是最直接的判断依据。
- Chrome / Edge：打开 DevTools → Security 标签页 → 查看 “Connection” 行，确认显示
secure (with TLS 1.3)或secure (with TLS 1.2)，且右侧有Reused session提示（不是 “New session”） - Wireshark 抓包过滤
tls.handshake.type == 4（NewSessionTicket），正常应出现在 ServerHello 之后；客户端重连时的 ClientHello 应含extension: session_ticket（TLS 1.2）或pre_shared_key（TLS 1.3） - 用
curl -vI --tlsv1.2 https://yoursite.com观察响应头，虽然不直接显示票据状态，但若* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256后紧接* Server certificate且无证书链延迟，大概率票据已生效 - 服务端可临时加日志：
LogLevel ssl:trace3，搜索日志中ssl_engine_kernel.c相关行，看到reusing session或new session ticket created即为成功
与 SSLSessionCache 并存时的优先级和资源开销差异
两者不是互斥关系，但行为逻辑完全不同：前者把状态甩给客户端（无服务端存储压力），后者依赖服务端缓存（有共享瓶颈）。在分布式场景下，SSLSessionTickets 是更可靠的选择，但需注意共存时的实际效果。
- Apache 默认同时启用两者；当客户端支持票据时，优先走票据流程，
SSLSessionCache不参与该次复用 -
SSLSessionCache "shmcb:/path/to/cache(512000)"在多进程模型下需共享内存段，集群中必须配合 memcached/Redis 才能跨机生效，运维成本高 - 票据机制本身不消耗服务端内存，但每个票据加密/解密需 CPU（AES-128-CBC），对高并发小包场景（如 API 网关）可能比共享缓存略重
- 禁用
SSLSessionCache不影响票据功能，但建议保留（至少本地 shmcb），作为票据不可用时的兜底（例如老设备或 TLS 1.1 客户端）
真实部署中最容易被跳过的一步，是验证所有节点上的 ticket.key 文件 md5 是否完全一致——哪怕一个字节不同，票据就在那个节点上彻底失效，而错误日志里通常只报“decryption failed”，不会告诉你密钥不匹配。
