nginx中优化加密套件是提升https安全评分至a+最有效方式：剔除不安全算法，仅保留pfs+aead套件；tls1.2用ssl_ciphers配置ecdhe-aes-gcm/chacha20，tls1.3用ssl_conf_command指定原生套件；协同收紧协议版本、服务端优先及openssl选项，并通过openssl命令和ssl labs验证生效。
直接在 Nginx 中优化加密套件，是提升 HTTPS 安全评分（如 SSL Labs A+）最有效、最可控的一环。关键不是堆砌套件数量，而是精准剔除所有已知不安全算法，明确启用现代 AEAD 套件，并严格区分 TLS 1.2 与 TLS 1.3 的配置逻辑。
只保留前向保密 + AEAD 类型套件
TLS 1.2 和 TLS 1.3 都强制要求前向保密（PFS），且 TLS 1.3 已完全移除非 AEAD 模式（如 CBC、RC4、SHA-1）。因此必须排除以下类型：
- aNULL、eNULL（无认证/无加密）
- MD5、SHA1（哈希弱，易碰撞）
- DES、3DES、RC4（已被攻破或性能极差）
- CBC 模式套件（如 ECDHE-RSA-AES128-SHA），即使带 GCM 也要确认后缀是 -GCM-SHA256 或 -GCM-SHA384
只保留真正现代、被硬件加速支持的组合：ECDHE 密钥交换 + AES-GCM 或 ChaCha20-Poly1305 + SHA256/SHA384。
分开配置 TLS 1.2 与 TLS 1.3 套件
TLS 1.3 不认 ssl_ciphers，必须用 ssl_conf_command Ciphersuites 单独指定原生套件；而 TLS 1.2 则靠 ssl_ciphers 控制。两者不可混写，否则可能静默失效：
- 为 TLS 1.2 配置：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; - 为 TLS 1.3 配置（放在
server块中、ssl_certificate之后）：ssl_conf_command Ciphersuites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";
注意：TLS 1.3 套件名必须完整、大小写敏感，不能加空格或斜杠，也不能混入任何 TLS 1.2 套件名。
协议版本与协商策略协同收紧
光有强套件不够，还要确保它们真能被选中：
- 显式启用且仅启用安全协议：
ssl_protocols TLSv1.2 TLSv1.3;（严禁包含 TLSv1.1 或更低） - 强制服务端主导协商（对 TLS 1.2 生效）：
ssl_prefer_server_ciphers on; - 禁用不安全的密钥交换和签名算法（通过 OpenSSL 层）：
可在ssl_conf_command中追加：ssl_conf_command Options "-ServerPreference -UnsafeLegacyRenegotiation";
验证是否真正生效
配置保存后必须验证，不能只看语法检查或浏览器锁图标：
- 用 OpenSSL 测试 TLS 1.2 握手：
openssl s_client -connect example.com:443 -tls1_2 | grep Cipher，输出应为类似Cipher is ECDHE-RSA-AES128-GCM-SHA256 - 用 OpenSSL 测试 TLS 1.3 握手：
openssl s_client -connect example.com:443 -tls1_3 | grep -E "(Protocol|Cipher)"，Protocol 应为TLSv1.3，Cipher 应匹配你写的TLS_AES_256_GCM_SHA384等 - 提交到 SSL Labs 扫描，重点查看 “Handshake Simulation” 表格中各客户端实际协商出的协议与套件
只要这三步都通过，安全评分基本稳拿 A+，且真实连接中不再暴露老旧算法风险。
