优化ssl_ciphers的核心是筛除低效危险选项，仅保留AES-GCM和ChaCha20-Poly1305等硬件加速的AEAD套件，禁用TLS 1.0/1.1，启用ssl_prefer_server_ciphers，并验证生效。
优化 ssl_ciphers 的核心不是“加算法”，而是“筛掉低效又危险的选项”——只保留被硬件加速、现代且安全的 AEAD 套件，同时关闭老旧协议和弱协商逻辑。这样既能堵住漏洞，又能把加解密开销压到最低。
只启用真正被硬件加速的套件
AES-GCM 和 ChaCha20-Poly1305 是目前唯一广泛获得 CPU 硬件支持的 AEAD 加密方式：
- Intel i3 及以上、AMD Ryzen 起的 CPU 普遍支持 AES-NI，AES-GCM 比 AES-CBC 快 3–5 倍
- ARM 设备（如安卓中低端机、部分服务器）无 AES-NI，但 ChaCha20 软件实现更轻量、延迟更低
- 必须剔除所有非 AEAD 模式：AES-CBC、RC4、3DES、SEED、MD5/SHA1 签名套件（如
ECDHE-RSA-AES128-SHA）
精简列表，控制在 6–8 个高质量组合
过长的 ssl_ciphers 列表会增加 Nginx 握手时的匹配负担，也拖慢客户端解析速度：
- 推荐写法（兼顾兼容性与性能）：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 - 若使用 ECDSA 证书且追求极致效率，可进一步缩减为单一强套件：
ECDHE-ECDSA-AES128-GCM-SHA256 - 避免重复逻辑：不必同时保留 AES128-GCM 和 AES256-GCM，除非业务明确要求 256 位密钥强度
强制服务端主导协商并限定协议版本
客户端可能主动提出已被禁用的弱套件，导致协商绕过你的优化：
- 必须开启：
ssl_prefer_server_ciphers on;（对 TLS 1.2 生效） - 明确限定协议：
ssl_protocols TLSv1.2 TLSv1.3;—— 彻底禁用 TLS 1.0/1.1（它们不支持 AEAD，强制使用慢速 CBC） - TLS 1.3 下无需手动指定套件，它本身只允许 AEAD；但需确保 OpenSSL ≥ 1.1.1 且 Nginx 编译支持
验证是否真正生效
改完配置不测试，等于没改：
- 命令行快速检查：
openssl s_client -connect yoursite.com:443 -tls1_2 | grep Cipher
输出应为ECDHE-RSA-AES128-GCM-SHA256或ECDHE-RSA-CHACHA20-POLY1305等目标套件，不能出现AES128-SHA、AES256-SHA等 CBC 类型 - 浏览器验证：Chrome DevTools → Security 标签页，查看 “Connection” 行是否显示 AES_128_GCM 或 CHACHA20
- 上线后观察 CPU 使用率：若
top中 %sy（系统态时间）持续高于 15%，说明仍有非硬件加速算法在运行
