直接在Nginx日志中记录$ssl_protocol和$ssl_cipher可实时获取每条HTTPS请求真实协商的协议版本与加密套件，是最轻量、零侵入的安全分析方式；需在http块定义含两变量的日志格式，并在HTTPS server块中启用该access_log，配合nginx -t与-s reload生效，HTTP请求对应字段为空或“-”不影响完整性。
直接在 Nginx 日志里记录 $ssl_protocol 和 $ssl_cipher，就能拿到每条 HTTPS 请求真实协商的协议版本与加密套件——这是最轻量、零侵入、实时生效的安全性分析方式。
配置日志格式以捕获关键字段
在 http 块中定义一条含这两个变量的日志格式，例如：
log_format tls_audit '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol $ssl_cipher';
然后在对应 server 块中启用：
access_log /var/log/nginx/https-audit.log tls_audit;
执行 nginx -t && nginx -s reload 后，每条 HTTPS 访问日志末尾就会追加类似 TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 的字段。注意：HTTP 请求该位置为空或显示为 -，不影响日志完整性。
快速识别不合规连接
用 shell 命令对日志做定向筛查，效率远高于人工翻查：
- 查老旧协议：
grep -E 'TLSv1\.0|TLSv1\.1' /var/log/nginx/https-audit.log - 查弱加密套件：
grep -i -E '(rc4|des|export|null|md5|sha1)' /var/log/nginx/https-audit.log - 查缺失前向保密（仅限 TLSv1.2+）：
grep 'TLSv1\.2' /var/log/nginx/https-audit.log | grep -v -E '(ECDHE|DHE)' - 查明文流量（SSL 未终止）：
awk '$12 == "-" {print}' /var/log/nginx/https-audit.log（假设$ssl_protocol是第 12 字段）
结合 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';
定位问题后推动有效整改
发现风险连接不能只归档，要结合上下文判断根因：
- 若某 IP 大量使用 TLSv1.0，且
$http_user_agent显示为 IE6 或 WinXP 系统，属于历史终端遗留问题，可评估是否关闭兼容 - 若大量 TLSv1.0 出现在同一网段，可能是客户端不支持 SNI 导致降级，需确认是否真需保留该协议
- 若
$ssl_server_name字段为空或异常，可能前端有代理未透传 SNI，影响证书匹配逻辑
