开启 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，不写等于没配。不能只依赖 http 块的全局设置，尤其在有多个 HTTPS server 块（如主站、API 子域名、跳转入口）时，必须每个块都明确包含：
ssl_prefer_server_ciphers on;-
ssl_ciphers—— 内容要合理、排序要靠前 ssl_protocols TLSv1.2 TLSv1.3;ssl_ecdh_curve secp384r1:prime256v1;
否则可能出现主站强加密，而某个子路径因继承缺失或被 include 文件覆盖，回退到弱默认策略。
ssl_ciphers 必须精细排序，开头即最强
开启 prefer 后，Nginx 会从左到右匹配第一个客户端支持的套件。所以顺序 = 安全等级。推荐直接使用明确、现代、支持前向保密（PFS）和 AEAD 模式的组合：
- 优先放
ECDHE-ECDSA-AES128-GCM-SHA256、ECDHE-RSA-AES256-GCM-SHA384、ECDHE-RSA-CHACHA20-POLY1305 - 禁用已淘汰算法：在末尾加
!RC4:!MD5:!SHA1:!DES:!3DES:!EXPORT:!aNULL:!eNULL - 避免模糊表达如
HIGH或!aNULL:!MD5，它们无法过滤掉非 PFS 套件（如 RSA-AES128-SHA） - 不混入任何 RSA 密钥交换套件（如
AES128-SHA），哪怕排在最后，也存在被诱导降级的风险
协议与密钥交换必须同步收紧
再强的套件列表，若允许 TLSv1.0 握手或使用弱曲线，仍可能协商出不安全连接：
- 只启用
ssl_protocols TLSv1.2 TLSv1.3;—— 明确去掉TLSv1和TLSv1.1（它们等价于 TLSv1.0） -
ssl_ecdh_curve必须指定，例如secp384r1:prime256v1，否则 ECDHE 可能退化到 ffdhe2048 等低强度参数 - 可选但推荐：配置
ssl_dhparam /path/to/dhparam.pem（2048 位以上），强化 DH 类密钥交换
验证是否真正生效
改完配置后 reload 不等于生效，必须实测确认协商结果：
- 用 OpenSSL 检查 TLSv1.2 协商：
openssl s_client -connect yourdomain.com:443 -tls1_2 | grep "Cipher is"
输出应为你ssl_ciphers列表中最靠前的那个强套件 - 用 SSL Labs 的 SSL Server Test 全面扫描，重点看：
– “Handshake Simulation” 中各客户端是否都协商到ECDHE+GCM或CHACHA20
– “Key Exchange” 是否显示 PFS
– 整体评级是否达到 A+ - 检查 Nginx 错误日志，确认无
SSL相关警告、fallback 提示或协议不匹配报错
