Nginx 无 proxy_ssl_session_tickets 指令，实际需协同配置 ssl_session_tickets（面向客户端）与 proxy_ssl_session_reuse（面向后端）：前者需统一48字节密钥、禁用共享缓存；后者须置于 upstream 块内，配合 keepalive、HTTP/1.1 长连接及 SNI 透传，并确保后端也启用并同步票据密钥。
Nginx 并不存在 proxy_ssl_session_tickets 这个指令——这是常见误解。实际生效的是两个独立但协同的机制：
-
面向客户端（浏览器）：用
ssl_session_tickets控制 TLS 会话票据，实现 入向 无状态复用； -
面向后端（HTTPS 上游）：用
proxy_ssl_session_reuse控制与上游的 TLS 会话复用，实现 出向 连接复用。
两者不能混用，也不能靠虚构指令“一键优化”。真正提升大规模反向代理集群的会话复用效率，关键在于把这两条链路都配对、配稳、配准。
面向客户端：启用并统一 ssl_session_tickets
这是让浏览器复用会话的基础，必须在所有 Nginx 节点上严格一致：
- 生成唯一 48 字节密钥：
openssl rand 48 > /etc/nginx/ticket.key，不可编辑、不可重复 - 分发到每台机器相同路径，权限设为
0400，属主为 Nginx 运行用户（如www-data或nginx） - 在
http或server块中启用：ssl_session_tickets on;ssl_session_ticket_key /etc/nginx/ticket.key; - 禁用冲突的
ssl_session_cache shared:SSL:...，否则 Nginx 会优先走缓存、忽略票据
面向后端：正确配置 proxy_ssl_session_reuse
这是减少 Nginx 与 HTTPS 后端握手开销的核心，且必须放在 upstream 块内才生效：
- 在
upstream中显式开启：proxy_ssl_session_reuse on;（默认值虽为on，但建议显式写出，避免被继承覆盖） - 搭配连接池：
keepalive 64;（数值按并发压力设定，例如单 worker 承载约 5k 并发时，设 64–128 较稳妥） - 强制 HTTP/1.1 长连接：
proxy_http_version 1.1;+proxy_set_header Connection ''; - 透传 SNI：
proxy_ssl_server_name on;（对接云网关、泛域名或 mTLS 后端时必备）
后端也得配合：确保上游支持并启用 session tickets
Nginx 能复用的前提，是后端也发出并接受票据。若后端是 Spring Boot、Node.js、或云服务（如 ALB、API Gateway），需确认：
- 后端 TLS 配置已启用 session ticket（如 Spring Boot 的
server.ssl.session.cache.size非零，或明确开启sessionTickets） - 多实例后端使用了相同的票据密钥（尤其自建集群），否则 Nginx 拿到的票据可能无法被其他后端节点解密
- 避免后端设置过短的
sessionTimeout（如低于 1 分钟），导致票据频繁失效
验证是否真实生效，不靠猜
两条命令即可交叉确认：
- 查客户端复用：
openssl s_client -connect example.com:443 -servername example.com -reconnect 2>/dev/null | grep "Reused, TLS"
出现 Reused 且Session-ID:为空，说明票据启用成功 - 查后端复用：
在log_format中加入$upstream_ssl_session_reused，统计一小时内r（复用）占比；健康集群应稳定 ≥ 85% - 观察连接数：
ss -tnp | grep :443 | grep nginx，ESTAB 数量应长期稳定在keepalive × worker_processes附近，大幅波动说明复用失败
