要让静态资源 HTTPS 服务真正跑在硬件加速路径上，核心是仅保留 CPU 硬件直解的 AEAD 套件（如 AES-GCM、CHACHA20-POLY1305），并确保 CPU 支持 AES-NI 或 ARMv8 Crypto Extensions、OpenSSL 编译启用 AES-NI、Nginx 配置 ssl_ciphers 锁定纯 AEAD+PFS 套件、禁用 CBC/RC4/3DES 等非加速套件、强制 TLSv1.2+ 协议及服务器优先协商，最后通过 openssl speed、perf stat 和 Wireshark 抓包实测验证是否命中硬件加速路径。
要让静态资源 HTTPS 服务真正跑在硬件加速路径上，核心不是“多选套件”，而是只留能被 CPU 硬件直解的 AEAD 套件，并确保 OpenSSL 和 CPU 共同就绪。AES-NI（x86）或 ARMv8 Crypto Extensions（ARM64）能把 AES-GCM 加解密开销压到接近零，但前提是 Nginx 实际协商到的套件必须匹配这些指令集——否则再强的 CPU 也白搭。
确认硬件与 OpenSSL 已就绪
硬件加速不会自动生效，得先验证基础条件是否满足：
- 检查 CPU 是否支持 AES-NI：grep -m1 -o aes /proc/cpuinfo——有输出即支持（Intel 第二代酷睿起、AMD Bulldozer 起基本都带）
- 确认 OpenSSL 编译时启用了 AES-NI：openssl version -a | grep -i "aesni\|engine"——看到 enable-aesni 或类似标志才算到位
- Nginx 无需额外配置，只要 OpenSSL ≥1.1.1（推荐），且 ssl_ciphers 中含 AES128-GCM-SHA256 等 GCM 套件，就会自动走 AES-NI 指令路径
ssl_ciphers 必须锁定纯 AEAD + PFS 子集
只有 AES-GCM 和 CHACHA20-POLY1305 能被现代硬件高效处理；CBC、RC4、3DES 等不仅慢，还完全无法加速，必须彻底剔除：
- 推荐精简配置（兼顾 TLS 1.2 兼容性）：ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
- 明确禁用所有非 AEAD 套件：删掉含 CBC、SHA1、MD5、3DES、RC4 的任何组合
- CHACHA20-POLY1305 不走 AES-NI，但纯软件性能优异，适合移动或老 CPU；若追求极致硬件利用率，可暂不启用
配合协议与协商控制确保命中硬解路径
光有套件不够，还得让客户端实际协商到它们：
- 强制协议版本：ssl_protocols TLSv1.2 TLSv1.3;——TLS 1.3 默认只用 AEAD，但 TLS 1.2 下需靠 ssl_prefer_server_ciphers on; 才能按你写的顺序优先匹配
- 避免混入 TLS 1.2 兼容兜底项（如 ECDHE-RSA-AES128-SHA），否则客户端可能协商到 CBC 套件，彻底绕过硬件加速
- 搭配 ssl_ecdh_curve secp384r1:prime256v1; 提升 ECDHE 密钥交换效率，减少握手阶段 CPU 开销
实测验证是否真在硬件上跑
配置生效 ≠ 硬件在干活，必须用工具确认：
- 本地压测对比：openssl speed -evp aes-128-gcm，分别在启用/禁用 AES-NI 的环境中运行，吞吐差 3–5 倍才说明加速生效
- 线上监控：perf stat -e cycles,instructions,cache-misses -p $(pgrep nginx)，若 instructions/cycle 接近 2–3，说明 CPU 流水线饱满，AES-NI 正满载运行
- 抓包验证：用 Wireshark 查看 TLS 握手中的 Cipher Suite 字段，确认实际协商的是 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这类 GCM 套件
