如何利用 ssl_prefer_server_ciphers on 强制优先使用服务端推荐的加密算法顺序

直接启用 ssl_prefer_server_ciphers on 是让 Nginx 在 TLS 1.2 握手时按服务端 ssl_ciphers 顺序优先选择强加密套件的必要前提，但必须显式配置于每个 server 块、搭配严格排序的 ECDHE+AEAD 套件、禁用弱算法、限定 TLSv1.2+ 协议、指定安全曲线并实测验证才真正生效。

直接启用 ssl_prefer_server_ciphers on 是让 Nginx 在 TLS 1.2 握手时按你写的顺序选加密套件的必要动作，但它本身不决定“哪个更强”——真正起作用的是你如何组织整套配置，并确保它们协同生效。

必须显式启用并放在 server 块内

该指令默认是 off，不写等于没配。不能依赖全局设置或默认值，需在每个启用 HTTPS 的 server 块中明确写出：

• ssl_prefer_server_ciphers on;
• 避免被 include 文件、location 块或低优先级配置覆盖（例如某子域名配置里误设为 off）
• 它对 TLSv1.3 无效（协议已硬编码套件），但必须保留，以保障 TLSv1.2 行为受控

ssl_ciphers 必须精细排序，开头即最强

开启 prefer 后，Nginx 才会从左到右严格匹配第一个客户端支持的套件。因此顺序 = 安全等级：

• 把支持前向保密（PFS）、AEAD 模式、低延迟的组合放最前面，例如：
  ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305
• 明确排除弱算法：用 !RC4:!MD5:!SHA1:!DES:!3DES:!EXPORT:!aNULL:!eNULL 强化过滤
• 避免模糊写法如 HIGH 或 !aNULL:!MD5，它们无法剔除非 PFS 套件（如 RSA-AES）
• 兼容性降级项（如 ECDHE-RSA-AES128-SHA）只能用冒号接在末尾，且仅限必要场景

协议与密钥交换参数必须同步收紧

再强的套件列表，若允许老旧协议或弱密钥交换，仍可能协商出不安全连接：

• 只启用现代协议：ssl_protocols TLSv1.2 TLSv1.3;（务必去掉 TLSv1.0 和 TLSv1.1）
• 指定高效安全曲线：ssl_ecdh_curve secp384r1:prime256v1;，兼顾性能与兼容性
• 可选增强：ssl_dhparam /path/to/dhparam.pem;（2048 位以上 DH 参数）

验证是否真正生效，不能只靠 reload

改完配置后必须实测确认协商结果，而非仅依赖 nginx -t：

• 命令行检查 TLSv1.2 协商：
  openssl s_client -connect yourdomain.com:443 -tls1_2 | grep "Cipher is"
  输出应是你 ssl_ciphers 中最靠前的强套件（如 ECDHE-RSA-AES256-GCM-SHA384）
• 用 SSL Labs Server Test 查看 “Handshake Simulation”，确认 Chrome、Firefox、Android 各版本均协商到 ECDHE+GCM/ChaCha20，且 Key Exchange 显示 PFS
• 检查 Nginx 错误日志，留意是否有 SSL fallback、cipher mismatch 或 curve unsupported 提示