必须启用$ssl_protocol和$ssl_cipher变量，定义专用日志格式tls_audit并仅绑定至443 server块，结合grep等命令筛查老旧协议与弱套件，实现HTTPS加密强度的实时、可验证审计。
要真正看清 HTTPS 连接的安全水位，不能只看 Nginx 配置写了什么，而要看每次握手实际协商出了什么——$ssl_protocol 和 $ssl_cipher 就是记录这个“真实结果”的两个关键变量。它们由 TLS 握手完成后自动填充，不可伪造、不依赖客户端上报，是审计加密强度最直接、最轻量的依据。
定义专用日志格式并精准绑定到 HTTPS 流量
这两个变量仅在启用 SSL 的连接中有效，HTTP 请求里为空或显示为“-”。所以必须在 http{} 块中定义日志格式，并只在监听 443 且启用了 ssl 的 server{} 块中调用，否则会丢失字段或报错。
- 推荐格式（竖线分隔，便于解析）：
log_format tls_audit '$time_iso8601|$remote_addr|$ssl_protocol|$ssl_cipher|$ssl_server_name|$request_method|$status|$bytes_sent|$request_time|"$http_user_agent"'; - 在 HTTPS server 块中启用：
access_log /var/log/nginx/tls-audit.log tls_audit; - 切勿写在 HTTP server 块或全局 http 块中
快速识别不合规连接的常用筛查命令
日志积累后，用 shell 命令即可快速定位风险点，无需人工翻查：
- 查老旧协议：
grep -E 'TLSv1\.0|TLSv1\.1' /var/log/nginx/tls-audit.log - 查弱加密套件：
grep -i -E '(rc4|des|export|null|md5|sha1)' /var/log/nginx/tls-audit.log - 查缺失前向保密（TLSv1.2 场景）：
grep 'TLSv1\.2' /var/log/nginx/tls-audit.log | grep -v -E '(ECDHE|DHE)' - 查明文流量（SSL 未终止）：
awk -F'|' '$3 == "-" {print}' /var/log/nginx/tls-audit.log（假设 $ssl_protocol 是第 3 字段）
结合 ssl_ciphers 配置做闭环验证
日志中出现的套件，必须全部落在你 ssl_ciphers 指令显式声明的范围内。如果发现日志里有 ECDHE-RSA-CHACHA20-POLY1305，但配置中没写它，说明实际生效策略与预期不符——可能是 OpenSSL 版本不支持、Nginx 编译时未启用模块，或被其他 server 块覆盖。
- 生产环境建议使用明确、精简的 cipher 列表，例如：
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; - 同时确保
ssl_protocols TLSv1.2 TLSv1.3;，并启用ssl_prefer_server_ciphers on;
辅助分析：用 $ssl_server_name 和 $ssl_session_reused 定位问题根源
光看协议和套件还不够，加上这两个字段能进一步缩小排查范围：
-
$ssl_server_name可确认是否因 SNI 不匹配导致降级（比如老旧客户端不发 SNI，触发默认 server 块，而该块可能配置宽松） -
$ssl_session_reused值为r或.，若大量连接未复用，可能提示 TLS 1.2 下会话票据未生效，或 TLS 1.3 下 PSK 机制异常 - 配合
$remote_addr和$http_user_agent，可定位到具体设备型号、操作系统或浏览器版本，判断是终端老化还是恶意扫描
