最有效降低 https cpu 负荷的方式是优先配置 aes-gcm 和 chacha20-poly1305 套件并禁用不支持硬件加速的算法；需启用 ssl_prefer_server_ciphers、tls 1.2+ 协议、优化椭圆曲线，并验证 aes-ni 实际生效。
直接把 AES-GCM 和 ChaCha20-Poly1305 套件放在最前面，同时剔除所有不支持硬件加速的算法（如 RC4、3DES、AES-CBC），是降低 HTTPS CPU 负荷最有效的方式。现代服务器 CPU 普遍支持 AES-NI 和 PCLMULQDQ 指令集，但只有 AES-GCM 和 ChaCha20-Poly1305 能真正利用它们；其他算法只能走软件模拟路径，吞吐量低 3–5 倍，还拉高 CPU 占用。
只保留硬件友好的 AEAD 套件
AEAD（认证加密）模式是硬件加速的前提。AES-GCM 和 ChaCha20-Poly1305 都属于 AEAD，而 AES-CBC、RC4、3DES 全部不支持硬件加速，必须排除。
- ✅ 推荐写法（TLS 1.2 兼容）：
ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305"; - ❌ 必须禁用：
AES256-SHA、AES128-SHA、DHE-RSA-AES256-GCM-SHA384（DHE 无硬件加速）、RC4、3DES-EDE-CBC、DES-CBC-SHA 等所有含 CBC、SHA1、MD5、EXPORT 或 NULL 的套件 - 验证是否生效：
openssl ciphers -V 'ECDHE:AESGCM:CHACHA20' | grep -E 'AES|CHACHA'—— 输出应只含 GCM 或 CHACHA，不含 CBC 或 SHA1
强制服务端按你写的顺序选套件
Nginx 默认把选择权交给客户端，哪怕你配了 AES-GCM，老客户端也可能选上慢且不安全的 RSA-SHA。必须收权：
- 在 server 或 http 块中启用：
ssl_prefer_server_ciphers on; - 该指令对 TLS 1.2 关键，对 TLS 1.3 无效（协议已固定），但仍需保留以保障旧协议安全
- 不加这行，配置再好也白搭——协商结果完全由客户端决定
配合 TLS 版本与密钥交换优化
硬件加速只对完整链路生效。光有 GCM 套件不够，协议和密钥交换也得匹配：
- 协议基线：
ssl_protocols TLSv1.2 TLSv1.3; —— 明确禁用 TLSv1.0/1.1（它们强制使用 CBC，绕过你的 GCM 配置） - 椭圆曲线指定：
ssl_ecdh_curve secp384r1:prime256v1; —— secp384r1 运算更快、抗侧信道更强；prime256v1 保障 Android 旧设备兼容 - TLS 1.3 套件前置（Nginx 1.13+）：
把TLS13-AES-128-GCM-SHA256等前缀套件放在 ssl_ciphers 最前面，避免 TLS 1.3 客户端 fallback 到 TLS 1.2 协商
实测确认硬件真在工作
配置生效 ≠ 加速生效。要验证 CPU 是否真的跑在 AES-NI 路径上：
- 对比基准：
openssl speed -evp aes-128-gcm—— 启用 AES-NI 时吞吐应达 2–3 GB/s，禁用时通常不足 1 GB/s - 压测监控：
perf stat -e cycles,instructions,cache-misses -p $(pgrep nginx)—— 若 instructions/cycle ≥ 2.0，说明流水线饱满，AES-NI 正满载运行 - 线上验证：
用openssl s_client -connect yourdomain.com:443 -tls1_2查看返回的 Cipher 行，确认是ECDHE-RSA-AES128-GCM-SHA256这类而非ECDHE-RSA-AES128-SHA
