关键不是记录完整SSL握手过程，而是通过$ssl_protocol、$ssl_cipher、$ssl_session_reused、$ssl_server_name和$upstream_connect_time等变量记录协商结果与耗时线索，精准定位HTTPS性能瓶颈。
要在 Nginx 中记录详细的 HTTPS 访问与握手日志，关键不是追求“完整握手过程”（Nginx 不支持抓取 ClientHello 等原始 TLS 数据），而是通过一组稳定可用的内置变量，把每次连接协商出的关键结果和耗时线索准确记下来。这些字段足够定位兼容性问题、复用失效、TLS 降级或后端握手拖慢等常见瓶颈。
必须启用的 SSL 日志变量
这些变量只在 启用了 SSL 终止 的 server 块中有效（即 listen 443 ssl;），且 Nginx 必须自己加载证书完成握手：
- $ssl_protocol：实际协商的 TLS 版本，如 TLSv1.3 或 TLSv1.2，一眼识别是否被强制降级
- $ssl_cipher：最终采用的加密套件，例如 ECDHE-ECDSA-AES128-GCM-SHA256，可排查弱算法或不兼容组合
- $ssl_session_reused：值为 r 表示会话复用成功（跳过完整握手），. 表示新建会话——这是判断握手开销最直接的信号
- $ssl_server_name：客户端通过 SNI 发送的目标域名，用于确认多域名配置是否按预期路由
- $upstream_connect_time：Nginx 连接后端服务的耗时（含后端 TLS 握手），若该值明显高于 $upstream_response_time，说明后端 HTTPS 配置有问题
定义并启用增强型日志格式
在 http{} 块中添加自定义格式（注意空格与引号匹配）：
log_format ssl_debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$ssl_protocol/$ssl_cipher "$ssl_server_name" $ssl_session_reused '
'$request_time $upstream_response_time $upstream_connect_time';
然后在对应 HTTPS 的 server{} 块内启用（不能写在 http 块或 HTTP server 中）：
access_log /var/log/nginx/ssl-debug.log ssl_debug;
确保日志路径目录存在，且 Nginx worker 进程有写权限（如 chown nginx:nginx /var/log/nginx）。
快速识别三类典型问题
查日志时不用逐行读，盯住这几类组合模式即可定位根源：
- 大量 $ssl_session_reused . + $ssl_protocol TLSv1.2：说明会话缓存未生效（比如 ssl_session_cache 没配在 http 块顶层，或 ssl_session_timeout 太短），又被迫走高开销的 TLS 1.2 全握手
- $upstream_connect_time 持续 >500ms，且远大于 $upstream_response_time：大概率是后端 HTTPS 握手慢，检查其是否支持 TLS 1.3、证书链是否完整（缺中间 CA 会触发客户端 OCSP 查询）
- 同一 IP 频繁出现 $ssl_session_reused . 但 $ssl_protocol TLSv1.3：说明客户端不支持 session resumption（如某些旧版 iOS），此时应开启 ssl_session_tickets on; 作为无状态兜底
验证是否生效
执行 nginx -t 检查语法，再 nginx -s reload 重载；用 curl -k https://your-domain.com 触发一次请求；查看日志文件末尾是否出现类似：
192.168.1.100 - - [02/Oct/2026:16:20:33 +0000] "GET / HTTP/1.1" 200 1234 "" "curl/8.10.1" TLSv1.3/ECDHE-ECDSA-AES128-GCM-SHA256 "example.com" r 0.023 0.012 0.008
若所有 SSL 字段为空或显示短横线，大概率是 server 块漏了 ssl 关键字，或 access_log 被误放在了 HTTP server 块里。
