优化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 握手时的匹配负担，也拖慢客户端解析速度：

SSL Certificate Monitor

检查一个或多个域名的 SSL/TLS 证书到期时间、颁发者、协议及 SAN 信息，用于应要求检查证书、监控到期或验证 HTTPS 等场景。

下载

• 推荐写法（兼顾兼容性与性能）：
  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%，说明仍有非硬件加速算法在运行