合规通关比例=success请求数/https且$ssl_client_verify非空的请求数，需排除http、495/496状态及重定向干扰，并通过结构化日志记录验证结果与原因。
直接看 $ssl_client_verify 的值，就能判断客户端证书是否通过验证——它不是“有没有证书”，而是“证书是否被信任链认可”。合规通关比例 = 成功验证请求数 / 所有启用双向认证的请求数，关键在准确归集和排除干扰。
明确 $ssl_client_verify 的真实取值含义
该变量由 Nginx 在 SSL 握手完成后填充，仅当配置了 ssl_client_certificate 且启用了 ssl_verify_client on 时有效。常见值有：
- SUCCESS：客户端提供了有效证书，且该证书能被指定 CA 证书链成功验证（含有效期、吊销状态、用途匹配等）
-
FAILED:reason：证书存在具体问题，如
FAILED:No certificate（未提供）、FAILED:Certificate expired、FAILED:Unknown issuer等 - NONE：客户端未发送证书（注意：这不等于失败，而是“未提供”，常见于可选认证场景）
⚠️ 注意：NONE 和 FAILED 都属于“未通关”，但原因不同；日志中必须保留完整 reason 字符串，不能只截取前缀。
在 access_log 中结构化记录验证结果
避免用默认日志格式模糊处理。推荐在 log_format 中显式提取验证状态与原因：
log_format ssl_audit '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_user_agent" "$http_referer" '
'ssl_verify="$ssl_client_verify" '
'ssl_subject="$ssl_client_s_dn" '
'ssl_issuer="$ssl_client_i_dn"';
access_log /var/log/nginx/ssl_audit.log ssl_audit;
这样每条日志都带验证结果和证书元数据，便于后续用 grep、awk 或 ELK 聚合分析。例如统计 SUCCESS 比例：
awk '$12 ~ /SUCCESS/ {s++} NR>0 {t++} END {printf "通关率: %.2f%\n", s/t*100}' /var/log/nginx/ssl_audit.log
区分“认证路径启用”与“实际触发双向认证”的请求
不是所有请求都走双向认证路径。需结合 location 或 if 判断实际启用场景，否则分母失真：
- 若只在特定 API 路径（如
/api/v3/private）强制开启ssl_verify_client on，则只统计该路径下的请求 - 避免把
ssl_verify_client optional下的普通 HTTPS 请求混入分母——它们本就不需要证书 - 可通过
$ssl_client_verify非空（即不为 ""）来过滤真正进入双向认证流程的请求，作为合规统计的基准分母
识别并剔除干扰项以反映真实合规率
以下情况不应计入“合规通关比例”的分子或分母：
- HTTP 请求（未走 TLS）：用
$scheme != "https"过滤掉 - 495/496 状态码请求：Nginx 在证书验证失败时返回这些状态，说明已进入双向认证流程但未通过，应计入分母，但不计入分子
- 重定向到非 TLS 地址的请求：可能绕过证书校验，需检查
$scheme和$request_uri是否一致
真正有效的统计口径是：HTTPS 请求中，且 $ssl_client_verify 有值（非空）的请求总数为分母；其中值为 SUCCESS 的数量为分子。
