直接启用 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 提示
