最有效手段是精简启用AES-GCM与ChaCha20-Poly1305等现代AEAD套件，禁用CBC、RC4等非AEAD模式，强制服务端主导协商并关闭TLS 1.0/1.1。
直接把 AES-GCM 和 ChaCha20-Poly1305 这两类能被 CPU 硬件加速的 AEAD 套件放在最前面，删掉所有非 AEAD 的算法（比如 AES-CBC、RC4、3DES），再配合服务端优先协商和协议限制，就能让 HTTPS 加密真正跑在硬件路径上，大幅降低 CPU 占用。
只保留硬件友好的 AEAD 套件
现代 CPU（Intel i3+/AMD Ryzen/ARMv8）对 AES-GCM 和 ChaCha20-Poly1305 有原生指令支持，加解密效率比传统 CBC 模式高 3–5 倍。其他算法如 AES-CBC、RC4、3DES 不仅慢，还完全无法加速，必须剔除：
- ✅ 推荐组合（按优先级从左到右）：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 - ❌ 必须移除：含
CBC、SHA1、MD5、3DES、RC4的任何套件（例如ECDHE-RSA-AES128-SHA）
确保协商命中硬件路径
客户端可能主动提出弱套件，光配对还不行，得让服务端真正主导：
- 开启
ssl_prefer_server_ciphers on;（对 TLS 1.2 生效） - 限定协议为
ssl_protocols TLSv1.2 TLSv1.3;（彻底禁用 TLS 1.0/1.1，它们不支持 AEAD） - 若用 ECDSA 证书，可进一步精简为单一强项：
ECDHE-ECDSA-AES128-GCM-SHA256
适配不同设备架构
AES-GCM 在 x86 服务器上靠 AES-NI 加速，而 ChaCha20 在 ARM 移动端或老旧 CPU 上更轻量：
- 服务器为主：把
AES128-GCM放最前 - 移动端或混合后端：把
CHACHA20-POLY1305提前，尤其当后端是安卓 App 或嵌入式设备时 - 反向代理场景（
proxy_pass https://）：用proxy_ssl_ciphers单独配置上游连接，例如：proxy_ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305";
并配proxy_ssl_protocols TLSv1.2 TLSv1.3;和proxy_ssl_ecdh_curve secp384r1:prime256v1;
验证是否真走硬件加速
改完配置后必须实测，不能只看 nginx -t：
- 命令行检查协商结果：
openssl s_client -connect example.com:443 -tls1_2 | grep Cipher
输出应为ECDHE-RSA-AES128-GCM-SHA256或ECDHE-RSA-CHACHA20-POLY1305，不能出现AES128-SHA - 查 CPU 是否支持 AES-NI：
grep -m1 -o aes /proc/cpuinfo（有输出即支持） - OpenSSL 是否启用：
openssl version -a | grep -i aesni（应显示enable-aesni） - 压力测试时监控
perf stat -e cycles,instructions,cache-misses -p $(pgrep nginx)，若 instructions/cycle 接近 2–3，说明 AES-NI 正在满载运行
