要让nginx真正用上强加密套件，必须配置ssl_ciphers按优先级排序（tls13套件前置）、启用ssl_prefer_server_ciphers on、限定ssl_protocols tlsv1.2 tlsv1.3，并指定ssl_ecdh_curve secp384r1:prime256v1，缺一不可。
要让 Nginx 真正用上强加密套件，不能只写几个“看着高级”的算法，关键在于排序逻辑、协议协同和实测验证。光靠 ssl_ciphers 一行配置远远不够，必须搭配其他指令才能生效。
明确哪些套件真正安全可靠
现代浏览器和客户端优先支持 AEAD 模式（如 AES-GCM、ChaCha20-Poly1305）和前向保密（PFS）。以下组合兼顾安全性与主流兼容性：
- ECDHE-RSA-AES128-GCM-SHA256 —— RSA 证书最通用的选择
- ECDHE-ECDSA-AES128-GCM-SHA256 —— ECDSA 证书专用，性能更好
- ECDHE-RSA-AES256-GCM-SHA384 —— 密钥更长，无兼容性损失
- ECDHE-RSA-CHACHA20-POLY1305 —— 移动网络下延迟更低
所有这些都以 ECDHE 开头（保障前向保密），使用 GCM 或 ChaCha20（杜绝 CBC 模式漏洞），且完全避开 RC4、3DES、MD5、SHA1、EXPORT、NULL、ANONYMOUS 等已淘汰项。
写出可落地的 ssl_ciphers 配置
把强套件按优先级从左到右排列，TLS 1.3 套件放最前（Nginx 1.13+ 支持），再跟 TLS 1.2 的 ECDHE+AEAD 套件：
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';
若需兼容 Android 4.4.2、Java 7u25 等极旧客户端，可在末尾追加兼容项，但绝不前置：
:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA;
必须配套的关键指令
ssl_ciphers 单独存在是无效的，以下三项必须同步启用：
-
ssl_prefer_server_ciphers on;—— 强制服务端按你写的顺序选套件；否则客户端可能挑最弱可用项 -
ssl_protocols TLSv1.2 TLSv1.3;—— 明确禁用 TLSv1.0 和 TLSv1.1（已被标准弃用） -
ssl_ecdh_curve secp384r1:prime256v1;—— 提升 ECDHE 性能，抗侧信道攻击；Windows 下 Nginx 若版本较旧，可简化为prime256v1
验证是否真正生效
重载配置（nginx -s reload）后，仅语法检查通过不代表安全达标。务必实测：
- 用 SSL Labs Server Test 查看 “Handshake Simulation”，确认 Chrome、Firefox、Safari 等主流客户端协商出的确实是 GCM 或 ChaCha20 套件
- 命令行快速验证：
openssl s_client -connect example.com:443 -tls1_2，观察返回中的Cipher行 - 避免使用
!RC4:!MD5类黑名单写法——现代 OpenSSL 已默认禁用，显式写出反而干扰维护
