直接看$ssl_client_verify实际值可计算双向认证通关率，即success占全部tls握手请求比例；需满足ssl_verify_client on、ssl_client_certificate有效且日志格式限定在mtls server块内，推荐结构化日志含$ssl_client_verify、$ssl_client_s_dn、$ssl_protocol等字段便于统计分析。

直接看 $ssl_client_verify 在日志里的实际值，就能算出双向认证“通关率”——即 SUCCESS 占全部 TLS 握手请求的比例。这不是统计页面访问量，而是统计每一次 HTTPS 连接在证书验证环节是否真正通过。

确保 $ssl_client_verify 有真实输出

这个变量只有在启用且执行了客户端证书校验时才有意义。关键前提有三个：

• ssl_verify_client 必须设为 on（不是 optional 或 optional_no_ca），否则多数请求会返回 NONE
• ssl_client_certificate 指向的 CA 文件必须存在、可读、格式为 PEM，且包含能覆盖客户端证书的信任链
• 日志格式必须定义在启用了 mTLS 的 server 块内，不能写在全局 http 或纯 HTTP server 中，否则该变量为空字符串或报错

设计可统计的日志格式

用竖线分隔、字段对齐的结构化日志，方便后续用 awk/grep/ELK 统计。推荐包含以下核心字段：

• $ssl_client_verify：直接反映验证结果（SUCCESS / FAILED:reason / NONE）
• $ssl_client_s_dn：即使失败也存在，可用于识别具体是哪个客户端出问题
• $ssl_protocol 和 $ssl_cipher：辅助判断是否因协议降级或套件不匹配导致握手提前中断（这类请求根本到不了 verify 阶段，$ssl_client_verify 不会触发）
• $time_iso8601 和 $request_method：绑定时间与动作，区分是 API 调用还是浏览器试探性连接

示例 log_format：

SSL Certificate Monitor

检查一个或多个域名的 SSL/TLS 证书到期时间、颁发者、协议及 SAN 信息，用于应要求检查证书、监控到期或验证 HTTPS 等场景。

下载

log_format mtls_audit '$time_iso8601|$remote_addr|$ssl_protocol|$ssl_cipher|$ssl_client_verify|$ssl_client_s_dn|$request_method|$uri|$status';

从日志提取合规通关比例

以一小时日志片段为例，可用简单命令快速计算：

• 总握手请求数：grep -c '|' ssl-audit.log
• SUCCESS 数：grep -c 'SUCCESS|' ssl-audit.log
• FAILED 类型分布：grep 'FAILED:' ssl-audit.log | cut -d'|' -f5 | sort | uniq -c（常见如 FAILED:depth lookup:expired、FAILED:no certificate returned）
• NONE 比例高？说明大量客户端根本没发证书——可能路径未强制、前端未配置证书、或 curl 测试漏加 --cert

注意：495/496 错误页请求也会进入 access_log，但它们属于 TLS 层拒绝，不参与 $ssl_client_verify 计算，需单独统计 error_log 中的 warn 级日志来补全漏斗视图。

对接安全看板的关键字段透传

如果后端服务也参与决策，建议在 proxy_pass 前透传关键验证状态：

• proxy_set_header X-Client-Verify $ssl_client_verify;
• proxy_set_header X-Client-DN $ssl_client_s_dn;
• proxy_set_header X-SSL-Protocol $ssl_protocol;

这样业务系统可在自身日志中打标，把“证书有效但接口权限不足”和“证书根本无效”区分开，避免把策略拦截误判为认证失败。