ssl_prefer_server_ciphers on 是执行开关，本身不提升安全性，必须配合显式配置的强加密套件顺序（如ECDHE+AES-GCM/ChaCha20）、禁用RC4/DES/SHA1等弱算法、限定TLSv1.2+协议及server块内统一部署才有效。
开启 ssl_prefer_server_ciphers on 是让 Nginx 在 TLS 握手时按你设定的顺序选用加密套件，但它本身不提升性能或安全性——关键在于你给它排了什么顺序、禁了哪些旧算法、是否匹配现代协议。对静态站点来说，目标很明确：在保障兼容性的前提下，优先协商 ECDHE + AES-GCM 或 ChaCha20 这类低延迟、高安全、支持前向保密的组合。
必须和 ssl_ciphers 显式配合使用
单独写 ssl_prefer_server_ciphers on; 没有效果。它只是“执行开关”，真正起作用的是 ssl_ciphers 里列出的套件及其顺序。
- 删掉所有已淘汰算法：RC4、DES、3DES、MD5、SHA1（签名除外）、EXPORT、NULL
- 避免模糊表达如
HIGH或!aNULL:!MD5，它们无法排除非 PFS 套件或 SHA1 签名套件 - 推荐直接用明确、现代的套件列表，例如：
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
限定协议版本并启用 ECDH 曲线优化
TLS 版本控制和套件控制是两道独立防线。即使套件再强，若允许 TLSv1.0 协商，仍可能降级到弱组合。
- 强制只用安全协议：
ssl_protocols TLSv1.2 TLSv1.3;（不要写TLSv1，它等价于 TLSv1.0） - TLSv1.3 自动忽略
ssl_ciphers和ssl_prefer_server_ciphers，但该指令对 TLSv1.2 握手仍生效，所以必须保留 - 搭配
ssl_ecdh_curve secp384r1:prime256v1;，兼顾性能（secp384r1 更快）与老设备兼容性（prime256v1 支持更广）
配置位置与验证方式要到位
这个参数虽小，但放错位置或漏验证，等于白配。
- 统一写在
server块内，和ssl_certificate、ssl_ciphers等 SSL 参数保持一致；避免在http块全局启用却在某个server中漏配ssl_ciphers，导致该站点策略失效 - 改完先运行
nginx -t检查语法，再nginx -s reload - 用 OpenSSL 验证 TLSv1.2 协商结果：
openssl s_client -connect yourdomain.com:443 -tls1_2 | grep "Cipher is"
确认输出的套件是你ssl_ciphers列表中最靠前的那个强套件 - 用 SSL Labs 的 SSL Server Test 全面扫描，重点看 “Cipher Suites” 是否全为 ECDHE+GCM/ChaCha20，“Key Exchange” 是否显示 PFS，目标评级 A+
