mod_log_config 无法记录 SSL 会话 ID，因其未被 mod_ssl 导出为可记录变量；Session ID 属 TLS 内部状态，日志触发时已不可访问；可用 %{SSL_PROTOCOL}x、%{SSL_SESSION_RESUMED}x 等替代分析。
mod_log_config 无法直接记录 SSL 会话 ID
Apache 的 mod_log_config 模块本身**不提供记录 TLS/SSL 会话 ID（Session ID）的内置格式符**。OpenSSL 虽然在握手阶段生成并维护 Session ID，但 mod_ssl 并未将其暴露为 %{}x 类型的可记录变量（如 %{SSL_SESSION_ID}x 不存在）。你尝试写 %{SSL_SESSION_ID}x 或类似变体，日志中只会输出空字符串或 -。
为什么 Session ID 不可用？
Session ID 是 TLS 层内部状态，仅在握手完成前或重用时短暂存在；而 mod_log_config 日志触发点在 HTTP 请求处理阶段（即握手成功、TLS 已建立之后），此时 OpenSSL 的 session 对象可能已被释放或不可访问。Apache 官方文档和源码中均无对应字段支持 —— 这不是配置问题，是模块设计限制。
-
%{SSL_PROTOCOL}x、%{SSL_CIPHER}x等能用，是因为它们由 mod_ssl 在会话建立后显式导出为环境变量 -
SSL_SESSION_ID未被导出，也未纳入SSLOptions +StdEnvVars范围 - 即使启用
LogLevel debug和SSLDebug，输出的是调试事件流，不是结构化日志字段
替代方案：用 mod_ssl + expr 提取 TLS 握手日志中的 Session ID（有限可行）
如果你必须关联请求与 Session ID，唯一可行路径是绕过 mod_log_config，改用 Apache 2.4+ 的 expr 语法结合 LogFormat 中的 %{expr=...}s，但前提是 Session ID 已以某种方式“透出”到请求上下文 —— 实际上它没有。所以真正能做的只有：
- 启用 OpenSSL 底层调试日志（非生产推荐）：
export SSL_DEBUG=1+LogLevel ssl:debug，然后 grep"Session-ID:"（注意：格式不固定，含换行和空格，难解析） - 用
tcpdump抓包 + Wireshark 解密（需私钥），在 ClientHello/ServerHello 中直接查看 Session ID 字段（TLS 1.2 可靠，TLS 1.3 中该字段已弃用，改用 PSK） - 若使用 TLS 1.3，Session ID 已被 Pre-Shared Key (PSK) 机制取代，应关注
%{SSL_SESSION_RESUMED}x（值为Initial或Resumed）和 ALPN 协商结果，而非 Session ID 本身
更现实的分析目标：用已有字段替代 Session ID 关联
多数会话级分析需求（如连接复用率、客户端协议兼容性、证书协商一致性）其实不需要原始 Session ID。以下字段组合已足够支撑：
-
%{SSL_PROTOCOL}x+%{SSL_CIPHER}x：识别加密套件与协议版本分布 -
%{SSL_SESSION_RESUMED}x：判断是否为会话复用（Resumed表示复用成功） -
%{SSL_SECURE_RENEG}x：检查重协商安全性 -
%h+%{User-Agent}i+%t：配合时间窗口做客户端行为聚类（比 Session ID 更稳定）
Session ID 本身不具备业务语义，且生命周期短、重复率高（尤其在负载均衡后），强行采集反而增加日志体积和解析复杂度。真要追踪端到端 TLS 行为，应该在流量入口（如 WAF、LB）或客户端侧做埋点，而不是依赖 Apache 日志。
