所谓“黄金比例”并非万能cipher字符串，而是需严格限定TLS 1.2、禁用等保三级禁用算法（如RC4、SHA1、静态RSA），并配合ssl_protocols TLSv1.2 TLSv1.3和ssl_prefer_server_ciphers off才生效；TLS 1.3完全忽略ssl_ciphers，仅用其硬编码的5种AEAD套件。
直接说结论：所谓“黄金比例”不是一套万能 cipher 字符串，而是 ssl_ciphers 仅作用于 TLS 1.2、必须禁用所有等保三级明令禁止的算法、且必须配合 ssl_protocols TLSv1.2 TLSv1.3 和 ssl_prefer_server_ciphers off 才能真正生效。试图靠 cipher 列表“兼顾一切”，反而会因降级或协商失败导致安全水位不一致。
为什么 ssl_ciphers 对 TLS 1.3 完全无效
TLS 1.3 彻底重构了密钥交换与加密套件机制，它只允许五种标准化组合（如 TLS_AES_128_GCM_SHA256），这些由 OpenSSL 内部硬编码实现，ssl_ciphers 指令对其完全不生效。Nginx 启动时若在 ssl_ciphers 中写入 TLS 1.3 套件名（比如带 TLS13- 前缀的），不会报错但也不会被采用；写入旧版套件（如 AES256-SHA）更不会触发 TLS 1.3 回退——协议版本由 ssl_protocols 控制，cipher 只影响 TLS 1.2 协商结果。
常见错误现象：
– SSL Labs 测评显示 TLS 1.3 已启用，但 cipher 列表里全是 TLS 1.2 套件 → 正常，无需修改
– 启用了 TLSv1.3 却仍看到 ECDHE-RSA-AES128-GCM-SHA256 被标为“支持” → 这是 TLS 1.2 的协商结果，和 TLS 1.3 无关
等保三级不可妥协的硬性过滤条件
以下关键词一旦出现在 ssl_ciphers 字符串中，即违反等保三级传输加密要求，必须从列表中彻底剔除：
-
SSLv3、TLSv1、TLSv1.1（协议层已禁，但部分旧 cipher 名含这些字样，需一并排除） -
RC4、MD5、SHA1（注意：含-SHA但非-SHA256/-SHA384的均属 SHA1，如ECDHE-RSA-AES128-SHA） -
EXPORT、NULL、ANONYMOUS、PSK、SRP -
AES256-SHA、AES128-SHA、DES-CBC3-SHA（静态 RSA 密钥交换，无前向保密）
性能影响：剔除这些后，cipher 列表长度通常缩短 40%～60%，但现代客户端协商速度反而更快（候选集更小、AEAD 解密更高效）；兼容性影响：IE11 on Win7/8.1 仍可连，但 IE11 on Win10 默认倾向 TLS 1.3，实际走的是另一条路径。
面向 IE11 / Android 5–6 的 TLS 1.2 兼容套件取舍
若真实存在必须支持 Windows 7 + IE11、OpenSSL 1.0.2u 固件、Java 8u161- 等环境，只能在 TLS 1.2 框架内加极少量 CBC 套件，且必须满足三个前提：
– ssl_protocols 明确限定为 TLSv1.2 TLSv1.3（禁用 TLS 1.0/1.1）
– ssl_prefer_server_ciphers 保持 off（Nginx 1.11.0+ 默认值）
– 所有 CBC 套件必须使用 SHA256 或 SHA384，禁用任何 -SHA
可谨慎加入的套件（仅限必要）：
-
ECDHE-RSA-AES128-SHA256：IE11 on Win7/8.1 默认启用，TLS 1.2 下已规避 POODLE -
ECDHE-RSA-AES256-SHA384：金融/政务类旧系统常见依赖，性能略低但未牺牲安全性 -
ECDHE-RSA-CHACHA20-POLY1305：对 Android WebView 和低功耗设备更友好，但 Java 7/8 不支持，慎用
绝对不要加：ECDHE-RSA-AES128-SHA（SHA1）、DHE-RSA-AES128-SHA（DHE 性能差且 SHA1）、AES128-GCM-SHA256（缺少密钥交换前缀，Nginx 解析失败）
最终配置必须验证的三个隐性点
即使 cipher 字符串看起来完美，以下三点疏忽仍会导致“表面合规、实际降级”：
-
ssl_ecdh_curve未显式指定secp256r1:secp384r1→ IE11 和部分 Java 客户端可能 fallback 到不安全曲线（如sect163k1），或协商失败 -
ssl_dhparam文件缺失或过期（若保留 DHE 套件）→ Nginx 会自动生成 1024-bit DH 参数，违反等保三级“密钥长度 ≥ 2048-bit”要求 - 未在日志中启用
$ssl_protocol和$ssl_cipher变量 → 无法确认真实连接到底走了 TLS 1.2 还是 TLS 1.3，也无法定位是哪个客户端触发了弱 cipher 回退
最易被忽略的是：cipher 列表再严谨，如果 ssl_protocols 漏写了 TLSv1.3，或者 OpenSSL 运行时版本低于 1.1.1，那所有 TLS 1.3 相关的安全收益就归零——而这个事实，nginx -t 根本不会提示。
