根本原因是SSL终止在负载均衡器，后端Nginx仅处理明文HTTP，无法接触客户端原始证书及指纹；仅SSL直通模式下Nginx才可能获取并计算指纹。
负载均衡器后的 Nginx 无法获取真实访客的 SSL 指纹，根本原因在于 SSL 握手终止位置发生了偏移——SSL 连接在负载均衡器（如 ALB、CLB、Nginx Ingress Controller 或自建 LVS+Keepalived）上就已结束，后续到后端 Nginx 的通信是明文 HTTP 或非终端 TLS，因此后端 Nginx 根本接触不到客户端原始证书及其指纹。
SSL 终止模式决定指纹是否可达
负载均衡器通常支持两种 TLS 处理方式，直接影响指纹能否传递：
- SSL 终止（Termination）：最常见配置。负载均衡器解密 HTTPS 流量，再以 HTTP（或可选的 HTTP/2）转发给后端 Nginx。此时客户端证书、SNI、TLS 版本、加密套件等握手信息全部丢失，Nginx 只看到普通 HTTP 请求，自然无法提取 SSL 指纹。
- SSL 直通（Passthrough / TCP 模式）：负载均衡器仅做四层转发（如监听 443 端口并透传 TCP 流），不参与 TLS 握手。此时客户端与后端 Nginx 建立完整 TLS 连接，Nginx 才能访问客户端证书（若启用 client certificate 验证）并计算其指纹。
Nginx 本身不主动计算或暴露 SSL 指纹
即使 SSL 终止未发生，Nginx 默认也不会生成或输出证书指纹。它只在启用 ssl_verify_client on 且客户端提供证书时，将证书内容通过变量（如 $ssl_client_cert）暴露。要获取指纹，需额外操作：
- 用 OpenSSL 命令对
$ssl_client_cert内容做哈希（如openssl x509 -noout -fingerprint -sha256），但 Nginx 不支持运行外部命令； - 借助 Lua 模块（如 OpenResty）在请求阶段解析并计算指纹，再注入到日志或响应头；
- 由上游负载均衡器代为提取并注入 HTTP 头（如
X-SSL-Fingerprint-SHA256），前提是该设备支持证书解析与头注入能力（如 AWS ALB 不支持，但某些 WAF 或自研 LB 可实现）。
常见误判场景与验证方法
很多排查者误以为“Nginx 日志里没看到 $ssl_protocol 就代表指纹丢了”，其实这是两个层面的问题：
- 若负载均衡器开启 SSL 终止，
$ssl_protocol、$ssl_cipher等变量恒为空，说明 Nginx 未参与 TLS 层，此时谈指纹无意义； - 可用
curl -Iv https://your-domain.com观察实际握手细节：若 Server 响应头显示的是负载均衡器标识（如server: awselb/2.0），而非 Nginx，则确认 SSL 已在其处终止； - 检查负载均衡器控制台或配置，确认监听协议是
HTTPS → HTTP（终止）还是TCP:443 → TCP:443（直通）。
真正需要指纹时的可行路径
如果业务强依赖客户端证书指纹（如金融级双向认证、设备绑定），不能依赖后端 Nginx 计算，而应：
- 强制使用 SSL 直通模式，并在 Nginx 中启用双向认证：
ssl_client_certificate指向 CA 证书，ssl_verify_client on； - 在 Nginx 日志中记录
$ssl_client_fingerprint（OpenResty 支持该变量，原生 Nginx 不支持）； - 或改由负载均衡器上游网关（如 API 网关、Service Mesh 边车）统一完成证书校验与指纹提取，避免后端重复处理。
