关键在于分层控制ssl_ciphers：TLS 1.3套件（如TLS13-AES-256-GCM-SHA384）必须前置且纯用TLS13-前缀；TLS 1.2套件紧随其后，仅限ECDHE+AEAD组合；启用ssl_prefer_server_ciphers on和ssl_protocols TLSv1.2 TLSv1.3，并配合ssl_ecdh_curve与会话缓存优化性能。
要让 Nginx 真正高效、可靠地选择强加密套件，关键不是堆砌算法，而是控制协商逻辑、分清协议层级、剔除冗余干扰。配置效率低，往往表现为 TLS 1.2 握手变慢、TLS 1.3 被降级、或客户端协商出非预期套件——这些问题几乎都源于 ssl_ciphers 的结构失当，而非算法本身不够“高级”。
严格按 TLS 版本分段排列套件
TLS 1.3 和 TLS 1.2 的套件机制完全不同：前者使用硬编码名称（如 TLS13-AES-256-GCM-SHA384），后者依赖服务端排序协商。混写或顺序错位会直接导致性能下降或静默降级。
- TLS 1.3 套件必须放在最前面，且仅用标准前缀：
TLS13-AES-128-GCM-SHA256、TLS13-CHACHA20-POLY1305-SHA256、TLS13-AES-256-GCM-SHA384 - TLS 1.2 套件紧随其后，全部限定为 ECDHE + AEAD 组合：如
ECDHE-RSA-AES128-GCM-SHA256、ECDHE-ECDSA-CHACHA20-POLY1305 - 绝对避免把 DHE、CBC 模式（如
AES256-SHA）或 SHA1 套件穿插在 ECDHE 套件中间——它们计算开销大，且现代客户端默认不选
启用服务端优先权并限定协议范围
ssl_prefer_server_ciphers on 对 TLS 1.2 至关重要，它确保 Nginx 按你写的顺序匹配，而不是由客户端挑最弱可用项；而 ssl_protocols TLSv1.2 TLSv1.3 则从源头禁用已淘汰的 TLS 1.0/1.1，减少协商分支和无效尝试。
- 不加
ssl_prefer_server_ciphers on，即使写了最强套件，客户端仍可能选中次优甚至不安全的组合 - 只写
TLSv1.3不写TLSv1.2会导致旧版 Safari、部分嵌入式设备无法建连；两者共存是当前生产环境的合理底线
配合椭圆曲线与会话缓存减少计算负担
ECDHE 的密钥交换性能高度依赖曲线选择。未配置 ssl_ecdh_curve 时，OpenSSL 可能回退到低效曲线或触发额外协商步骤。
- 推荐显式指定：
ssl_ecdh_curve secp384r1:prime256v1（兼顾安全性与 Windows/macOS 兼容性） - 搭配会话复用：
ssl_session_cache shared:SSL:10m和ssl_session_timeout 4h，大幅降低重复握手的 CPU 开销 - OCSP Stapling（
ssl_stapling on）也建议开启，避免客户端直连 CA 验证证书状态，缩短首字节时间
验证是否真正生效，而非仅语法通过
重载配置（nginx -s reload）成功不代表安全达标。必须实测协商结果：
- 用 SSL Labs Server Test 查看 “Handshake Simulation”，确认 Chrome/Firefox/Safari/iOS 等主流客户端实际协商出的是 GCM 或 ChaCha20，且协议版本为 TLS 1.2 或 1.3
- 本地用 OpenSSL 快速验证：
openssl s_client -connect example.com:443 -tls1_3和-tls1_2分别测试，观察Cipher输出行 - 检查 Nginx 错误日志是否有
no suitable signature algorithm类警告——常因ssl_ecdh_curve不匹配或证书类型（RSA/ECDSA）与套件不匹配引发
