应优先启用AES-GCM或ChaCha20-Poly1305等硬件加速套件，禁用RC4、3DES、AES-CBC等低效算法；必须使用ECDHE密钥交换，推荐secp256r1+ECDSA或RSA-SHA256；TLS 1.3需启用并配合OpenSSL 1.1.1+，配置后须验证协商结果与CPU占用。
关键在于选对密码套件，而不是堆砌高强度算法。现代 CPU 普遍支持 AES-NI 和 PCLMULQDQ 指令集，但若配置中混入大量软件模拟的算法（比如 RC4、3DES、非 GCM 模式的 AES-CBC），反而会拖慢速度、抬高 CPU 占用。
优先启用硬件加速友好的对称加密套件
让 Nginx 用上 AES-GCM 或 ChaCha20-Poly1305，这两类算法在主流服务器 CPU 上都有原生指令加速，加解密吞吐量比 AES-CBC 高 3–5 倍，延迟更低。
- 推荐写法（TLS 1.2+）：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:CHACHA20-POLY1305-SHA256; - 避免包含
AES256-CBC、3DES-EDE-CBC、RC4等无硬件加速且已不推荐的套件 - 可通过
openssl ciphers -V 'ECDHE:AESGCM:CHACHA20' | grep -E 'AES|CHACHA'验证是否实际启用
禁用低效的密钥交换与签名组合
ECDHE 是必须的，但具体曲线和签名算法影响很大。使用 secp256r1（NIST P-256）配合 ECDSA 证书，比 RSA 签名的 ECDHE-RSA 更快；而若用 RSA 证书，则应搭配 SHA256 签名，避免 SHA1。
- 删掉含
!ECDHE-ECDSA、!ECDHE-RSA的排除项，确保前向保密生效 - 显式排除低效组合：
!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!SRP:!CAMELLIA:!ARIA - 如部署了 ECDSA 证书，可进一步限定为
ECDHE-ECDSA-AES128-GCM-SHA256单一强套件，减少协商开销
配合 TLS 1.3 彻底简化握手流程
TLS 1.3 不再协商密钥交换算法和签名算法，只保留少数几个高效组合（如 TLS_AES_128_GCM_SHA256），且默认禁用所有已知脆弱算法。它把握手压缩到 1-RTT，还支持 0-RTT（对静态资源重放安全）。
- Nginx 1.13.0+ 必须启用：
ssl_protocols TLSv1.3 TLSv1.2;（禁用 TLS 1.0/1.1） - TLS 1.3 下
ssl_ciphers仅控制 TLS 1.2 行为，TLS 1.3 密码套件由协议固定，无需手动指定 - 确认 OpenSSL 版本 ≥ 1.1.1，并在编译 Nginx 时启用 TLS 1.3 支持
验证与调优建议
改完配置别急着 reload，先做两件事：一是用 nginx -t 检查语法；二是用 openssl s_client -connect your.site:443 -tls1_3 和 -tls1_2 分别测试是否真正协商到目标套件。
- 上线后观察 CPU sys 时间占比：若
top中 %sy 明显高于 15%，说明仍有非硬件加速算法在运行 - 静态资源（JS/CSS/图片）建议开启
ssl_buffer_size 4k;，减少小包加密开销 - 搭配
ssl_session_cache shared:SSL:10m;和ssl_session_timeout 4h;复用会话，避免重复握手计算
