高效配置nginx ssl加密套件的关键是分版本控制、精简列表、靠前命中、服务端主导：tls1.3套件（如tls13-aes-256-gcm-sha384）必须前置且纯用tls13-前缀，tls1.2套件紧随其后仅保留ecdhe+aead组合（如ecdhe-rsa-aes128-gcm-sha256），禁用cbc/sha1/rc4等非aead套件，启用ssl_prefer_server_ciphers on和ssl_protocols tlsv1.2 tlsv1.3，并配合ssl_ecdh_curve优化性能。
高效不是堆砌算法，而是让 Nginx 在第一次匹配时就选中能被硬件加速、支持前向保密、且客户端广泛兼容的套件。核心思路是：分版本控制、精简列表、靠前命中、服务端主导。
按 TLS 版本严格分段排列
TLS 1.3 和 TLS 1.2 的套件机制完全不同，混写会引发静默降级或握手变慢：
- TLS 1.3 套件必须用标准前缀，且放在最前面：
TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256 - TLS 1.2 套件紧随其后，仅保留 ECDHE + AEAD 组合：
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305 - 绝对避免把 DHE、AES-CBC（如 AES128-SHA）、SHA1 或 RC4 套件插在中间——它们既无硬件加速，又拖慢协商流程
优先选用硬件加速型对称加密
AES-GCM 和 ChaCha20-Poly1305 是当前唯一被主流 CPU 原生加速的 AEAD 算法：
- x86_64 服务器（Intel/AMD）基本支持 AES-NI：用 ECDHE-RSA-AES128-GCM-SHA256 放首位，加解密比 CBC 快 3–5 倍
- ARM 架构（如安卓 App 后端、嵌入式设备）更适合 ChaCha20：可将 ECDHE-RSA-CHACHA20-POLY1305 提前
- 禁用所有非 AEAD 模式：!AES-CBC:!RC4:!3DES:!MD5:!SHA1（显式排除更可靠）
控制列表长度与配套指令协同
超过 8 个套件不仅没收益，反而增加 CPU 匹配开销和客户端解析负担：
- 推荐总数控制在 6–8 个高质量组合内，覆盖 RSA/ECDSA 证书、AES/ChaCha20、128/256 位密钥即可
- 必须启用 ssl_prefer_server_ciphers on;：否则客户端可能跳过你排的第一位，选后面低效项
- 必须限定协议 ssl_protocols TLSv1.2 TLSv1.3;：禁用 TLS 1.0/1.1，从源头排除不支持 AEAD 的路径
- 建议指定椭圆曲线 ssl_ecdh_curve secp384r1:prime256v1;：避免 OpenSSL 回退到慢速软件曲线
上线前务必验证是否真生效
配置 reload 成功 ≠ 实际走强套件。需交叉验证：
- 命令行检查： openssl s_client -connect example.com:443 -tls1_2 | grep Cipher，输出应为 ECDHE-RSA-AES128-GCM-SHA256 类，不能含 AES128-SHA
- 确认硬件支持： grep -m1 aes /proc/cpuinfo（有输出即支持 AES-NI）
- 线上抽样：用 Wireshark 查看 TLS Handshake 中的 Cipher Suite 字段，看真实协商结果
- 压测对比：开启前后观察 CPU sys% 和 TLS 握手延迟，真实负载下差异通常超 30%
