ssl_prefer_server_ciphers on 本身不提升安全性，仅确保服务端加密套件顺序生效；必须配合严格限制的 ssl_ciphers（禁用 RC4/DES/SHA1 等弱算法）、ssl_protocols（仅 TLSv1.2+）及实测验证，否则无法防御降级攻击。
开启 ssl_prefer_server_ciphers on 本身不能单独防御 TLS 降级攻击，它只是必要条件之一；真正起效必须和 ssl_ciphers、ssl_protocols、证书密钥交换方式协同配置，否则形同虚设。
为什么 ssl_prefer_server_ciphers on 容易被误用
很多人以为只要加上这行就“安全了”，但实际中常见错误包括：
- 配置了
ssl_prefer_server_ciphers on，但ssl_ciphers里仍保留RC4、DES-CBC3-SHA、MD5等已知弱套件 - 未禁用
TLSv1.0和TLSv1.1，导致客户端可强制协商旧协议并绕过服务端 cipher 优先级 - 在 Nginx 1.11.0+ 上设为
on却未意识到：该指令对 TLSv1.3 无效，且会干扰其默认安全行为（TLSv1.3 不协商 cipher，ssl_ciphers和此指令均被忽略） - 未验证最终协商结果，仅凭配置存在就认为生效
如何正确配置以阻断降级路径
降级攻击的核心是让连接回落到不安全的协议或 cipher 组合。要切断所有常见降级路径，需同时控制三个层面：
-
协议层：只允许
TLSv1.2和TLSv1.3，明确禁用TLSv1.0和TLSv1.1：ssl_protocols TLSv1.2 TLSv1.3; -
cipher 层：只保留支持前向保密（PFS）+ AEAD 加密的套件，显式剔除所有含
RC4、DES、3DES、MD5、SHA1、NULL、EXPORT的套件：ssl_ciphers 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; -
协商控制层：启用服务端 cipher 优先级，确保 TLSv1.2 连接严格按上述列表顺序选择：
ssl_prefer_server_ciphers on;
验证是否真能防住降级
光改配置没用，必须实测协商结果。常用方法：
- 用 OpenSSL 强制指定 TLSv1.2 并查看实际协商出的 cipher：
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ALL:COMPLEMENTOFALL' 2>/dev/null | grep Cipher
确认输出中不含RC4、DES、SHA1等关键词，且 cipher 名称与你配置的完全匹配 - 用 SSL Labs Test（
https://www.ssllabs.com/ssltest/）跑完整扫描，重点看 “Handshake Simulation” 表格中各客户端（尤其是老版本 IE、Android 4.4）是否都协商到了强套件；若某客户端仍落到ECDHE-RSA-RC4-SHA，说明你的ssl_ciphers或ssl_prefer_server_ciphers没生效 - 检查 Nginx 错误日志是否有
no suitable signature algorithm或SSL_do_handshake() failed，这类报错常意味着ssl_ciphers过于激进，或 ECDSA 证书缺失对应曲线支持（此时需补ssl_ecdh_curve secp384r1:prime256v1;）
最易被忽略的是：TLSv1.3 虽然自身免疫降级，但它依赖底层 OpenSSL 版本（≥1.1.1）和 Nginx（≥1.13.0）；如果环境不满足，ssl_protocols TLSv1.2 TLSv1.3 实际只启用了 TLSv1.2，此时 ssl_prefer_server_ciphers on 就成了唯一防线——而它又极易因 cipher 配置不当而失效。
