$ssl_cipher是评估硬件加速占比的关键输入，需结合日志采集、套件分类映射（如GCM/CHACHA20为高利用率，CBC/SHA1为低利用率）及perf/openssl speed验证，最终通过统计高频套件类型估算硬件承担比例。
直接用 $ssl_cipher 本身不能算出硬件消耗占比，但它是最关键的输入线索——你得先知道实际用了哪个套件，才能判断它是否走硬件加速路径。真正的评估要结合三步：日志采集、套件分类映射、系统级性能验证。
从 $ssl_cipher 日志中提取真实协商结果
在 Nginx 的 http 或 server 块里定义带该变量的日志格式：
log_format cipher_log '$remote_addr [$time_local] "$request" $status $ssl_protocol/$ssl_cipher'; access_log /var/log/nginx/cipher-usage.log cipher_log;
重载后，每条 HTTPS 请求都会记录类似：203.0.113.55 [26/May/2026:20:15:33 +0000] "GET / HTTP/1.1" 200 TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256
重点看 / 后面那一段：它告诉你这次连接最终选了什么算法组合，这是后续评估的唯一事实依据。
按硬件加速能力对套件做强度分级
不是所有 AES-GCM 都一样快，也不是所有 ChaCha20 都被优化。需按 CPU 实际支持情况分类：
-
高硬件利用率（≈90%+ 加密开销由 AES-NI 或 ARM NEON 承担）
-
*AES128-GCM-SHA256、*AES256-GCM-SHA384（Intel i3+/AMD Ryzen+/ARMv8.2+） -
*CHACHA20-POLY1305（ARM 服务器、旧安卓、无 AES-NI 的 x86）
-
-
低或零硬件加速（纯软件计算，CPU 占用高、延迟高）
- 含
CBC、SHA1、MD5、3DES、RC4的套件（如ECDHE-RSA-AES128-SHA） -
DHE（非ECDHE）密钥交换（大数运算无指令加速）
- 含
-
TLS 1.3 套件不依赖
ssl_ciphers，但可识别- 日志中
$ssl_protocol显示TLSv1.3时，$ssl_cipher值为TLS_AES_128_GCM_SHA256等，这类全部默认走硬件加速路径，无需额外判断。
- 日志中
关联系统指标反推硬件消耗占比
光有套件名不够，得验证它是否真跑在加速路径上：
-
查当前 CPU 是否支持 AES-NI：
grep -q aes /proc/cpuinfo && echo "AES-NI enabled" || echo "No hardware acceleration"
-
测 AES-GCM 软硬加速吞吐差异（需 OpenSSL ≥1.1.1）：
openssl speed -evp aes-128-gcm -multi $(nproc)
若开启 AES-NI，吞吐通常达 3–5 GB/s；关闭后跌至 1–1.5 GB/s —— 差距就是硬件分担比例的下限。
-
监控 Nginx worker 进程的指令效率：
perf stat -e cycles,instructions,cache-misses -p $(pgrep nginx | head -1) -I 1000
若
instructions/cycle接近 2–3，说明流水线饱满，AES-NI 正在高效工作；若低于 1.2，大概率卡在软件加密循环里。
快速估算方法（生产环境实用版）
假设你已采集 1 小时日志，执行：
awk '{print $10}' /var/log/nginx/cipher-usage.log | \
awk -F'/' '{print $2}' | \
while read c; do
case "$c" in
*GCM*|*CHACHA*) echo "hw" ;;
*CBC*|*SHA1*|*3DES*|*RC4*) echo "sw" ;;
*) echo "other" ;;
esac
done | sort | uniq -c输出如：
9240 hw
187 sw
5 other 则硬件加速套件占比 ≈ 9240 / (9240 + 187) ≈ 98.0% —— 这就是当前流量中加密计算由硬件承担的大致比例。
不复杂但容易忽略的是：这个数字只反映“用了什么”，不代表“跑得多快”。必须配合 perf 或 openssl speed 验证底层是否真启用加速，否则可能因 OpenSSL 编译选项或内核限制导致 GCM 套件仍走软件实现。
