最有效手段是精简启用aes-gcm与chacha20等现代aead套件，禁用cbc、rc4等非aead模式，强制服务端主导协商并关闭tls 1.0/1.1。
直接用现代 AEAD 加密套件替代老旧算法，是兼顾安全与性能最有效的手段。关键不是“加功能”，而是“筛掉低效又危险的选项”，让 Nginx 只协商真正高效、被硬件加速支持的加密方式。
选对算法：优先 AES-GCM 和 ChaCha20
现代 CPU（Intel i3+/AMD Ryzen 起）普遍支持 AES-NI 指令集，AES-GCM 加解密速度比传统 CBC 模式快 3–5 倍；ChaCha20 在无 AES-NI 的设备（如部分 ARM 服务器或旧手机）上表现更优，延迟更低。
- 明确启用 ECDHE 密钥交换 + AES-GCM/ChaCha20 组合，例如：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 - 禁用所有非 AEAD 模式（如 AES-CBC、RC4、3DES），它们既慢又不安全
- 避免混入 SHA1 或 MD5 签名的套件（如 ECDHE-RSA-AES128-SHA），这些已淘汰且无硬件加速
精简列表：减少协商开销和 CPU 判断负担
ssl_ciphers 不是“越多越好”。过长的列表会让 Nginx 在每次 TLS 握手时花更多 CPU 时间遍历、匹配、排序；客户端也要同步解析。
- 控制在 6–8 个高质量套件内即可覆盖主流终端
- 删除重复逻辑的变体（如同时写 AES128-GCM 和 AES256-GCM，除非业务强依赖 256 位密钥）
- 移除仅用于兼容古董客户端的套件（如 SSLv3、TLS_RSA_WITH_AES_128_CBC_SHA），它们既无硬件加速，又拖慢整体协商
- 使用冒号分隔、严格按优先级从高到低排列，Nginx 会逐个尝试，靠前的命中即停
强制服务端主导协商：避免降级与冗余计算
默认情况下，客户端可提出任意 cipher suite（包括它自己支持但你早已禁用的弱算法）。开启 ssl_prefer_server_ciphers on 后，Nginx 才真正按你写的顺序做主。
- 必须与精简、现代的 ssl_ciphers 同时配置，否则开启也无效
- 配合 ssl_protocols TLSv1.2 TLSv1.3，彻底屏蔽 TLSv1.0/v1.1 —— 它们不支持 AEAD 套件，且强制使用慢速算法
- TLSv1.3 自动忽略 ssl_ciphers 和此指令，但它本身只允许 AEAD 套件，所以无需额外干预
验证是否生效：别只信配置文件
改完不测试，等于没改。重点确认两点：是否真用上了 GCM/ChaCha20，是否避开了老旧算法。
- 用命令行快速检查：
openssl s_client -connect yoursite.com:443 -tls1_2 | grep Cipher - 输出应显示类似 ECDHE-RSA-AES128-GCM-SHA256 或 ECDHE-RSA-CHACHA20-POLY1305，而非 AES128-SHA 或 DES-CBC3-SHA
- 搭配在线工具（如 SSL Labs Test）查看协议支持、密钥交换强度和前向安全性是否达标
