企业级多代际客户端安全接入关键在于分层控制：以TLS 1.2/1.3为基线，通过套件排序、协议限制（ssl_protocols TLSv1.2 TLSv1.3）、服务端优先（ssl_prefer_server_ciphers on）及椭圆曲线指定（ssl_ecdh_curve），实现现代客户端走AEAD强路径、过渡客户端可控使用ECDHE-RSA-AES128-SHA256、遗留客户端不直连主服务，同时彻底禁用RC4、SHA1、CBC弱套件及SSLv3/TLS1.0-1.1。
配置 ssl_ciphers 实现企业级多代际客户端安全接入，关键不是“全量兼容”，而是分层控制：以 TLS 1.2/1.3 为基线，用套件排序+协议限制+服务端优先权，让新客户端走强路径、旧客户端走可控弱路径，同时杜绝已知漏洞入口。
明确分代策略：按终端能力划三类客户端
企业环境中真实存在的客户端往往跨多个技术代际，需分类施策：
-
现代客户端（Chrome 80+/Firefox 78+/Safari 14+/Edge 90+/iOS 15+/Android 12+）：默认支持 TLS 1.3 和 AEAD 套件，应优先匹配
ECDHE-ECDSA-AES128-GCM-SHA256或CHACHA20-POLY1305，获得最低延迟与最高安全性 -
过渡客户端（Windows 7 + IE11、Android 5–6 WebView、Java 8u161 以下、部分国产浏览器内核）：仅支持 TLS 1.2，且依赖 SHA256 签名和 CBC 模式，可谨慎启用
ECDHE-RSA-AES128-SHA256，但必须禁用-SHA（SHA1）结尾套件 - 遗留客户端（Windows XP + IE6/8、Java 6/7、极老嵌入式设备）：存在严重协议缺陷（如不支持 SNI、无 PFS），不应直接放行 HTTPS；建议通过反向代理做协议终结或强制重定向至降级通道，而非在主服务中开启 RC4/3DES/SSLv3
套件排序必须体现证书类型与性能优先级
若部署了 RSA + ECDSA 双证书（推荐用于高并发 API 网关），ssl_ciphers 必须交错排列，确保协商不降级错配：
- ECDSA 套件前置：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305 - 紧接 RSA 套件：
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305 - 仅当业务强依赖 IE11/旧 Java 才追加：
ECDHE-RSA-AES128-SHA256（注意是-SHA256，非-SHA） - 绝对不写
AES256-SHA、RC4-SHA、DES-CBC-SHA等静态密钥或非 AEAD 套件
配套指令缺一不可，否则配置形同虚设
仅写 ssl_ciphers 不生效。必须同步设置：
-
ssl_protocols TLSv1.2 TLSv1.3;—— 明确关闭 TLS 1.0/1.1（PCI-DSS 与等保三级强制要求） -
ssl_prefer_server_ciphers on;—— 否则客户端可无视你的排序，挑一个它支持但你已禁用的弱套件（尤其 TLS 1.2 下） -
ssl_ecdh_curve secp384r1:prime256v1;—— 加速 ECDHE 计算，降低握手延迟，对 ECDSA 证书效果更明显 - 如使用 OpenSSL 3.0+，可额外加
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256;精准控制 TLS 1.3 套件
验证是否真正落地，不能只看配置文件
改完配置后必须实测确认：
- 用
openssl s_client -connect your.domain:443 -tls1_2查看协商结果，确认是否命中GCM或CHACHA20，且无SHA1、CBC、3DES - 用 SSL Labs Test 扫描，检查评级是否达 A+，重点看 “Key Exchange” 是否全部带 PFS，“Cipher Suites” 是否无红色高危项
- 在 IE11（Win7）、Android 6 WebView、Java 8u151 环境下人工访问，确认能建立连接且不报证书错误（说明 SHA256 兼容性已覆盖）
