Nginx 无法直接透传 SSL Session ID 给后端，但可通过 hash $ssl_session_id consistent 实现会话保持式负载均衡，或用 proxy_set_header X-SSL-Session-ID $ssl_session_id 透传自定义请求头。
不能直接透传 SSL 会话 ID（Session ID）给后端，因为该值在 TLS 层生成、仅存在于客户端与 Nginx 的加密连接中，Nginx 作为 TLS 终止点可读取它，但标准 HTTP 代理头不支持携带原始 Session ID 字段。不过，你可以用 $ssl_session_id 变量做哈希路由或构造自定义请求头，实现等效效果。
用 $ssl_session_id 实现会话保持式负载均衡
这是最常见且实用的做法：让同一客户端的多次 HTTPS 请求始终落到同一台后端，提升缓存命中率。
Ai Coach Batch Session Summary
下载
批量分析录音转写，输出多维度拓客报告。触发词：录音分析、总结、音频总结、拜访记录总结。当用户提及「分析录音」「看看录音数据」「最近的录音」「通话记录」且意图为批量统计/分析时触发。仅出现「录音」或「拜访」时需结合上下文，若仅查看单条详情则不触发。
- 必须在
upstream块中使用hash $ssl_session_id consistent;，而非ip_hash（后者受 NAT 和代理影响大） - 确保 Nginx 启用了 SSL 模块（
--with-http_ssl_module），且配置了有效的证书和私钥 -
$ssl_session_id在 TLS 握手完成后即可用，无需额外模块或 Lua - 示例配置：
upstream api_cluster { hash $ssl_session_id consistent; server 10.0.1.10:8000 weight=3 max_fails=2 fail_timeout=30s; server 10.0.1.11:8000 weight=2; }
将 Session ID 映射为自定义请求头透传
若后端确实需要原始 Session ID（如用于审计或关联 TLS 层日志），可将其作为普通 HTTP 头转发，但需注意这不是标准字段，后端需主动解析。
- 在
location块内添加：proxy_set_header X-SSL-Session-ID $ssl_session_id; - 该变量只在启用 SSL 的 server 块中有效；若未走 HTTPS，值为空字符串
- 避免用引号包裹变量名：
"$ssl_session_id"❌，应写为$ssl_session_id✅ - 后端需从请求头
X-SSL-Session-ID中读取，不能依赖SSL_SESSION_ID环境变量（那是 OpenSSL 内部状态）
注意事项与常见误区
直接“透传 Session ID”容易误解为复用 TLS 层原生字段，实际中需明确边界：
- Nginx 无法把原始 TLS 握手包里的 Session ID 直接转发给后端——那属于加密通道内部信息，后端无密钥无法解密
- 若 Nginx 不终止 TLS（即 SSL Passthrough），则根本拿不到
$ssl_session_id，此时只能靠$ssl_preread_server_name做 SNI 路由 - Session ID 是会话级标识，不是连接级；重启 Nginx 或会话超时后会变化，不适合长期存储或作为用户唯一标识
- 相比
$request_id（全链路追踪用），$ssl_session_id更适合服务层缓存亲和性，二者用途不同，不可混用
