核心是启用$ssl_protocol、$ssl_cipher等变量并定义专用日志格式ssl_audit，仅绑定至443 server块，同时确保ssl_protocols仅含tlsv1.2/tlsv1.3、ssl_ciphers明确指定aead套件且启用ssl_prefer_server_ciphers。
要实现 Nginx 日志对 SSL 配置的详细审计，核心不是记录“配置写了什么”，而是真实捕获每次 HTTPS 连接实际协商出的协议版本、加密套件、SNI 域名等关键 TLS 元数据——这些才是验证配置是否生效、客户端兼容性如何、是否存在弱协议残留的直接证据。
启用并组合关键 SSL 日志变量
Nginx 提供一组只在 HTTPS 请求中有效的内置变量，它们由 TLS 握手完成后自动填充，不可伪造、不可绕过：
-
$ssl_protocol：显示真实协商结果，如
TLSv1.2或TLSv1.3 -
$ssl_cipher：显示最终选用的加密套件，如
ECDHE-RSA-AES256-GCM-SHA384或TLS_AES_256_GCM_SHA384 - $ssl_server_name：反映客户端发送的 SNI 域名，用于识别虚拟主机路由行为
-
$ssl_session_reused：值为
r（复用）或.（未复用），辅助分析连接效率 -
$ssl_client_verify：若启用了双向认证，可输出
SUCCESS/FAILED，绑定终端身份可信度
定义专用日志格式并严格限定作用域
必须在 http{} 块中定义自定义格式，并仅在启用 SSL 的 server{} 块中调用，否则变量为空或报错：
示例配置（推荐使用竖线分隔，便于后续解析）：
log_format ssl_audit '$time_iso8601|$remote_addr|$ssl_protocol|$ssl_cipher|$ssl_server_name|$ssl_session_reused|$request_method|$uri|$status|$bytes_sent|$request_time|"$http_user_agent"';然后在监听 443 的 server 块中启用：
⚠️ 切勿将该日志指令写在 HTTP server 块或全局 http 块中。日志路径需确保目录存在且 Nginx worker 有写权限。
同步校验底层 SSL 配置是否合规
日志能记下来，不代表配置真正起效。必须同步检查以下三项：
-
协议限制：确认
ssl_protocols TLSv1.2 TLSv1.3;，禁用 TLSv1.0 和 TLSv1.1 -
套件声明：使用
ssl_ciphers明确列出 AEAD 类型套件（如TLS13-AES-256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256），避免模糊通配 -
服务端优先：启用
ssl_prefer_server_ciphers on;，确保按你指定顺序选择，而非客户端主导
配置后执行 nginx -t && nginx -s reload，再访问一次 HTTPS 页面，检查日志是否出现含完整协议与套件的条目。
用日志做持续审计与问题归因
积累一段时间后，可用简单命令快速定位风险点：
- 查所有 TLSv1.0/TLSv1.1 连接：
grep -E 'TLSv1\.[01]\b' /var/log/nginx/ssl-audit.log | head -10 - 统计高频加密套件：
awk -F'|' '{print $3"/"$4}' /var/log/nginx/ssl-audit.log | sort | uniq -c | sort -nr | head -15 - 发现未在
ssl_ciphers中声明的套件？说明配置未生效，需回溯检查ssl_protocols是否被覆盖或模块缺失
不复杂但容易忽略。
