nginx标准版本不支持$ssl_curve变量，因其ssl模块未导出tls握手中的椭圆曲线信息；可从$ssl_cipher推断常用曲线，或改用envoy/caddy、ebpf等方案获取精确数据。
OpenSSL 和 Nginx 本身并不提供名为 $ssl_curve 的内置变量，该变量在标准 Nginx（包括主流发行版和官方编译版本）中并不存在。因此，无法直接通过 log_format 引用 $ssl_curve 来记录客户端协商的椭圆曲线（ECC curve）名称。
为什么 $ssl_curve 不可用
Nginx 的 SSL 模块（ngx_http_ssl_module）暴露的 SSL 相关变量有限，当前稳定版（截至 1.25.x）仅支持：
-
$ssl_protocol（如 TLSv1.3） -
$ssl_cipher（如 ECDHE-ECDSA-AES128-GCM-SHA256） -
$ssl_ciphers（服务端配置的完整 cipher list） -
$ssl_server_name、$ssl_session_reused等
它不解析或导出 TLS 握手过程中客户端在 supported_groups（RFC 8422）扩展里通告的椭圆曲线列表，也不暴露服务端最终选择的曲线（如 secp256r1 或 x25519）。这个信息存在于 OpenSSL 的 SSL 对象内部，但未被 Nginx 封装为变量。
替代方案：从 $ssl_cipher 推断常用曲线
虽然无法直接获取曲线名，但可通过 $ssl_cipher 的值合理推断所用密钥交换曲线（尤其对 ECDHE 套件）：
-
ECDHE-ECDSA-或ECDHE-RSA-开头的套件，密钥交换必依赖 ECC 曲线 - 常见映射关系：
-
...-SHA256/...-SHA384→ 多数对应secp256r1（NIST P-256）或secp384r1 -
CHACHA20-POLY1305套件（如ECDHE-ECDSA-CHACHA20-POLY1305）→ 通常搭配x25519（尤其在 TLS 1.3 中）
-
- 在 log_format 中记录：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$ssl_protocol" "$ssl_cipher"';后续可用日志分析工具（如 awk / Logstash / Grafana Loki）按 cipher 正则聚类，间接反映曲线使用分布。
真正获取曲线需定制或换工具
若必须精确采集客户端
supported_groups或服务端选定曲线，有以下可行路径：-
OpenSSL 应用层日志：修改 OpenSSL 构建时启用
enable-ssl-trace，或使用openssl s_client -msg -tls1_3 ...手动抓包分析 handshake message；不适合生产高负载场景 -
eBPF / BCC 工具：用
sslsniff或自定义 eBPF probe 拦截内核 SSL/TLS socket 数据，在 TLS ClientHello 解析supported_groups扩展；适合 Linux 4.15+，零侵入，可实时聚合 -
Envoy / Caddy 等现代代理：Envoy 支持
%DOWNSTREAM_TLS_CIPHER_SUITES%和%DOWNSTREAM_TLS_CURVE%（实际为tls.context.curve），Caddy v2.8+ 也提供{http.request.tls.curve}变量，比 Nginx 更透明
性能调优建议（不依赖 $ssl_curve）
针对高负载下 ECC 性能瓶颈，更有效的方式是：
- 统一优先启用
x25519：在ssl_ecdh_curve中设为x25519:secp256r1:secp384r1，x25519 计算更快且抗侧信道 - 禁用低效曲线：避免
secp192r1、secp224r1等已淘汰曲线 - 启用 TLS 1.3：自动协商 x25519 + HKDF，省去 ServerKeyExchange，显著降低握手延迟
- 监控
nginx_stub_status中的Accepts/Handled/Requests比率 + OpenSSLSSL_get_ex_data_X509_STORE_CTX_idx相关计数器（需 patch）
不复杂但容易忽略。
-
OpenSSL 应用层日志：修改 OpenSSL 构建时启用
