nginx加密套件优先顺序核心是服务端严格按从左到右顺序选取客户端支持的第一个强套件，需在server块中配置ssl_ciphers，并与ssl_protocols tlsv1.2 tlsv1.3、ssl_prefer_server_ciphers on、ssl_ecdh_curve共存，tls1.3套件前置，tls1.2仅保留ecdhe+aead组合，彻底剔除rc4、des、sha1、cbc等风险项。
Nginx 配置加密套件的优先顺序，核心不是“堆砌算法”，而是让服务端严格按你指定的强度从左到右选第一个客户端支持的套件。只要顺序合理、内容干净，就能从源头切断降级路径——攻击者再怎么干扰握手，也没得可降。
必须写在 server 块里，且和协议、协商控制指令共存
ssl_ciphers 只在 server 块中生效（http 或 location 里写无效），且必须和以下三项同时存在，缺一不可：
-
ssl_protocols TLSv1.2 TLSv1.3;（禁用 TLSv1.0/1.1） -
ssl_prefer_server_ciphers on;（把选择权收回来，只认你排的顺序） -
ssl_ecdh_curve secp384r1:prime256v1;（避免低效曲线拖慢 ECDHE）
套件列表要分层写，TLS 1.3 套件放最前
现代 Nginx + OpenSSL 1.1.1+ 环境下，推荐这样组织 ssl_ciphers：
- TLS 1.3 的五种标准套件（硬编码，不参与协商）放在最前面
- 紧跟其后是 TLS 1.2 下真正生效的强套件，全部限定为 ECDHE + AEAD（AES-GCM 或 ChaCha20-Poly1305）
- 不混用 CBC 模式、RSA 密钥交换、SHA1/MD5 签名的旧套件
示例配置：
ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256: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';
明确剔除所有已知风险项
别依赖 !RC4:!SHA1 这类黑名单写法——它容易漏配、干扰阅读，还可能被 OpenSSL 版本差异影响。直接不写就是最稳妥的禁用：
- 不含 RC4、DES、3DES、MD5、SHA1（非 AEAD 场景）
- 不含 EXPORT、NULL、aNULL、eNULL、STATIC RSA（如 RSA-AES256-SHA）
- 不含任何 CBC 模式套件（如 AES128-SHA），它们易受 Lucky13 等侧信道攻击
验证是否真按预期工作nginx -t 只检查语法，完全无法确认实际协商结果。必须实测：
- 用 SSL Labs（ssllabs.com）跑完整测试，看 “Handshake Simulation” 表格里各客户端最终选中的 Cipher
- 命令行快速验证 TLS 1.2 协商：
openssl s_client -connect example.com:443 -tls1_2 -cipher 'ALL:COMPLEMENTOFALL' 2>/dev/null | grep "Cipher is"
输出应显示
ECDHE-RSA-AES128-GCM-SHA256或类似 AEAD 套件，而非AES128-SHA或RC4-MD5
不复杂但容易忽略。
