Nginx TLS审计日志需基于真实握手变量（$ssl_protocol等）构建，定义专用格式并仅限HTTPS server启用；叠加真实IP、SNI、mTLS指纹及脱敏存储，方满足合规溯源要求。
Nginx 中 TLS 优化本身不直接生成日志，但只有在合规启用 TLSv1.2+、强加密套件、SNI 支持与 OCSP Stapling 的前提下，内置 SSL 变量才能真实、不可篡改地反映每次连接的协商结果——这才是加密溯源日志的可信基础。
必须记录真实 TLS 协商元数据
Nginx 提供的 $ssl_protocol、$ssl_cipher、$ssl_server_name、$ssl_session_reused 等变量，由 TLS 握手完成后自动填充，无法伪造或绕过。它们是验证“配置是否生效”“客户端是否合规”“是否存在弱协议回退”的唯一现场证据。
-
$ssl_protocol显示实际使用的版本（如TLSv1.3），不是配置里写的“支持列表” -
$ssl_cipher给出最终选定套件（如TLS_AES_256_GCM_SHA384），可直接比对等保/密评要求的 AEAD 强度 -
$ssl_server_name记录客户端 SNI 域名，用于识别异常访问目标或虚拟主机越权行为 -
$ssl_session_reused（值为r或.）辅助判断连接模式，高频新建会话可能指向扫描或证书失效
定义专用日志格式并严格限定作用域
不能复用默认 combined 格式，必须在 http{} 块中明确定义结构化格式，并只在 listen 443 ssl 的 server{} 块中启用：
log_format tls_audit '$time_iso8601|$remote_addr|$ssl_protocol|$ssl_cipher|$ssl_server_name|$ssl_session_reused|$request_method|$uri|$status|$bytes_sent|$request_time|$upstream_response_time';
然后在 HTTPS server 块中写：
access_log /var/log/nginx/tls-audit.log tls_audit;
⚠️ 若误配到 HTTP server 块或全局 http 块，变量为空或报错，日志失去审计价值。
还原真实客户端身份与网络上下文
单条 TLS 日志无法定位风险源，需叠加三类信息构建可追溯链路：
- 启用
ngx_http_realip_module，通过set_real_ip_from指定可信上游（如云厂商 LB 网段），确保$remote_addr是终端真实 IP，而非代理地址 - 在响应头中透传
X-Forwarded-For和X-Forwarded-Proto，供后端服务或 SIEM 工具复原原始请求路径与协议类型 - 若启用双向认证（mTLS），优先记录
$ssl_client_fingerprint（40 字符 SHA-1 指纹），它比$ssl_client_s_dn更稳定、唯一、免解析；再辅以$ssl_client_verify判断证书有效性（SUCCESS/FAILED/NONE）
日志输出与存储需满足合规刚性要求
- 日志路径权限设为
640，属主为独立审计账号（如audit:nginx），禁止 Nginx worker 进程直接写入原始敏感字段 - 启用 Rsyslog TLS 双向认证远程同步，服务端强制校验客户端证书，并将日志存入 WORM 存储（如 ZFS append-only 目录或 MinIO 启用保留策略的版本化 bucket）
- 对含
$http_authorization或$args的扩展字段，必须脱敏（推荐log_by_lua_block过滤 Bearer token、password 等），避免原始凭据落盘
不复杂但容易忽略
