开启 ssl_prefer_server_ciphers on 是强制服务端选密前提，但必须配合严格排序的 ssl_ciphers、禁用旧协议（TLSv1.0/1.1）、指定安全曲线及实测验证，否则仍可能协商弱算法。
要让 Nginx 真正按服务端意愿优先使用最高强度的加密算法，ssl_prefer_server_ciphers on 是必要条件，但不是充分条件。它本身不决定“哪个算法更强”，只是把选择权从客户端手里收回来——后续能否选到强算法，完全取决于你配置的 ssl_ciphers 是否合理、是否排序得当，以及是否配合其他关键限制。
必须开启并放在正确位置
该指令需显式启用，且建议写在 server 块内（或 http 块全局生效），不能只靠默认值：
-
ssl_prefer_server_ciphers on;—— 必须写，Nginx 默认是off - 仅对 TLS 1.2 及更早版本生效；TLS 1.3 的套件由协议强制规定，无需也不受此指令影响，但仍需保留该配置以保障旧协议安全
- 若配置在多个 server 块中，确保没有被低优先级块覆盖（例如 include 文件中误设为 off）
ssl_ciphers 必须严格排序、剔除弱项
开启 prefer 后，Nginx 才会严格按你写的顺序从左到右匹配第一个客户端支持的套件。所以顺序即安全等级：
- 开头放 ECDHE + AES-GCM 或 ChaCha20-Poly1305 类组合，例如：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 - 明确排除已淘汰算法：用
!RC4:!MD5:!SHA1:!DES:!3DES:!EXPORT:!aNULL:!eNULL等后缀强化过滤 - 避免混入 RSA 密钥交换套件（如
AES128-SHA），它们不支持前向保密（PFS），即使排在后面也存在降级风险
必须协同控制协议版本与密钥交换参数
再强的 cipher list，若允许老旧协议或弱密钥交换，仍可能协商出不安全连接：
- 禁用 TLSv1.0 和 TLSv1.1：
ssl_protocols TLSv1.2 TLSv1.3; - 指定高性能安全曲线：
ssl_ecdh_curve secp384r1:prime256v1;（提升 ECDHE 效率，兼顾兼容性） - 启用会话复用减少重复握手开销：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;，间接鼓励客户端持续使用当前安全通道
验证是否真正生效
改完配置不能只 reload 就算完，务必实测确认协商结果：
- 用
openssl s_client -connect yourdomain.com:443 -tls1_2查看Cipher行输出，确认是否为你设定的第一个强套件 - 使用在线工具如 SSL Labs（ssllabs.com）做全维度扫描，重点看 “Handshake Simulation” 中各客户端实际协商到的 cipher
- 检查 Nginx error log，确认无
no suitable signature algorithm或曲线不匹配类警告
