Nginx启用高强度加密套件需精确排序、强制服务端优先、限定TLS版本并优化椭圆曲线；推荐配置以ECDHE-AES-GCM/ChaCha20套件开头，禁用弱算法，且须通过SSL Labs或OpenSSL实测验证。
要在 Nginx 中真正启用高强度加密套件，光靠堆砌几个“高分”算法远远不够，核心在于精确排序 + 强制协商顺序 + 协议与密钥交换机制协同。配置错一步，就可能降级到弱套件，甚至导致老客户端握手失败。
明确加密套件的组成和筛选逻辑
Nginx 的 ssl_ciphers 不是简单开关，而是一条按优先级从左到右匹配的规则链。每条套件如 ECDHE-RSA-AES128-GCM-SHA256 包含四部分：
- 密钥交换：ECDHE（支持前向保密）优于 RSA（不支持）
- 身份认证：RSA 或 ECDSA，取决于证书类型
- 对称加密：AES128-GCM、AES256-GCM、ChaCha20-Poly1305 安全且高效；避免 AES-CBC、RC4、3DES
- 摘要算法：SHA256/SHA384 优于 SHA1/MD5（必须禁用）
宏定义如 HIGH 是 OpenSSL 内置别名，代表密钥长度 ≥128 位的套件，但不保证前向保密或现代算法。建议显式列出，避免隐式依赖。
推荐的高强度套件配置（兼顾安全与兼容）
以下配置按优先级降序排列，适用于主流现代客户端（Chrome/Firefox/Safari/Edge 最新版、Android 7+、iOS 10+）：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
如需兼容较旧客户端（例如 Android 4.4.2、Java 7u25），可追加兼容项，但必须放在末尾，确保强套件仍被优先选择：
:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA;
⚠️ 切勿使用 !DHE 全局禁用 DHE——它会同时砍掉合法的 ECDHE；应只排除已知脆弱的 DHE 参数（如短密钥），Nginx 默认已规避。
必须配套的关键指令
ssl_ciphers 单独生效的前提，是其他三项配置同步到位：
-
强制服务端优先：
ssl_prefer_server_ciphers on;—— 否则客户端可无视你的排序，自行选最弱可用套件（TLS 1.2 及更早版本下尤为关键） -
限定协议版本：
ssl_protocols TLSv1.2 TLSv1.3;—— 明确禁用 TLSv1.0 和 TLSv1.1（已被标准弃用） -
优化椭圆曲线：
ssl_ecdh_curve secp384r1:prime256v1;—— 提升 ECDHE 性能与抗侧信道能力；TLS 1.3 下该设置仍影响密钥交换效率
验证是否真正生效
配置重载后，仅 nginx -t 成功不代表安全达标。务必实测：
- 用 SSL Labs Server Test 查看 “Handshake Simulation” 表格，确认各主流客户端协商结果均为 GCM 或 ChaCha20 套件
- 命令行快速验证（需 OpenSSL 1.1.1+）：
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ALL:COMPLEMENTOFALL' 2>/dev/null | grep Cipher
输出应类似Cipher : ECDHE-RSA-AES128-GCM-SHA256 - 日志中记录实际协商套件（需 Nginx ≥1.11.5 + OpenSSL ≥1.0.2）：
在log_format中加入$ssl_protocol/$ssl_cipher，查看访问日志确认每次连接使用的是否为你设定的首选套件
