应严格配置ssl_ciphers仅保留ecdhe/rsa-aes128/256-gcm-sha256/384、chacha20-poly1305等pfs+aead强套件，禁用rc4、3des、md5、sha1等弱算法，并配合ssl_protocols tlsv1.2 tlsv1.3和ssl_prefer_server_ciphers on实现握手阶段主动拦截。
直接用现代 AEAD 套件替代老旧算法，是兼顾安全与性能最有效的手段。关键不是“加功能”，而是“筛掉低效又危险的选项”，让 Nginx 只协商真正高效、被硬件加速支持的加密方式。
只保留前向保密 + AEAD 的套件
现代安全基线要求所有启用的套件必须同时满足两个条件：支持前向保密（PFS），使用 AEAD 认证加密（如 AES-GCM、ChaCha20-Poly1305）。这意味着要剔除所有含 RSA 密钥交换、CBC 模式、SHA1/MD5 签名的套件。
- ECDHE-ECDSA-AES128-GCM-SHA256 和 ECDHE-RSA-AES128-GCM-SHA256 是 TLS 1.2 下的主力套件，兼容性好且受 AES-NI 加速
- CHACHA20-POLY1305 适合无 AES-NI 的设备（如部分 ARM 服务器或旧手机），延迟更低
- TLS 1.3 套件必须显式以 TLS13- 开头，例如 TLS13-AES-128-GCM-SHA256，不能混用 TLS 1.2 命名格式
- 避免同时保留 AES128-GCM 和 AES256-GCM —— 除非业务强依赖 256 位密钥，否则统一用 AES128-GCM 更轻量
严格控制协议版本和协商逻辑
ssl_ciphers 只对 TLS 1.2 生效；TLS 1.3 使用内置硬编码套件，不依赖该指令。若配置不当，可能引发降级或静默失败。
- 必须设置 ssl_protocols TLSv1.2 TLSv1.3，彻底禁用 TLSv1.0/v1.1（它们不支持 AEAD）
- TLS 1.2 下需开启 ssl_prefer_server_ciphers on，确保服务端按你写的顺序主导协商
- TLS 1.3 下该指令无效，但不影响其自身安全性 —— 它默认只允许 AEAD 套件
- 不要写 !aNULL:!MD5:!RC4 这类黑名单，现代 OpenSSL 已默认禁用，反而干扰维护
精简列表，减少握手开销
过长的 ssl_ciphers 列表会增加 Nginx 和客户端的解析负担，拖慢 TLS 握手，尤其在高并发场景下明显。
- 控制在 6–8 个高质量套件内即可覆盖 Chrome 70+、Firefox 63+、Safari 12+、Edge 79+
- 把 TLS 1.3 套件放在最前面，确保支持的客户端直接命中，不走协商流程
- 后续紧接 TLS 1.2 的 ECDHE+AEAD 套件，按性能优先排序（如 GCM 在前，ChaCha20 居中，DHE 套件靠后或移除）
- 删除重复逻辑变体（如 ECDHE-RSA-AES128-GCM-SHA256 和 ECDHE-RSA-AES256-GCM-SHA384 同时存在）
验证是否真正生效
改完配置不测试，等于没改。重点确认两点：是否真用上了 GCM/ChaCha20，是否避开了老旧算法。
- 用命令快速检查 TLS 1.2 协商结果：openssl s_client -connect yoursite.com:443 -tls1_2 | grep Cipher
- 输出应显示类似 ECDHE-RSA-AES128-GCM-SHA256 或 ECDHE-RSA-CHACHA20-POLY1305，而非 AES256-CBC-SHA
- 用 openssl s_client -connect yoursite.com:443 -tls1_3 验证 TLS 1.3 是否启用及套件匹配
- 配合在线工具（如 SSL Labs Test）做全维度扫描，确认评级达到 A+，且无 POODLE、BEAST、Sweet32 等漏洞提示
