Nginx ssl_ciphers 应分层配置：优先AEAD套件（AES-GCM/ChaCha20），TLS 1.2下谨慎保留ECDHE-RSA-AES128-SHA256等强CBC套件以兼容IE11等旧设备，剔除所有非PFS、RC4、SHA1、EXPORT等不安全套件，并配合ssl_protocols TLSv1.2 TLSv1.3和ssl_ecdh_curve确保安全与兼容。
Nginx 的 `ssl_ciphers` 没有放之四海而皆准的“万能列表”，但存在一组经过验证的组合，能在保障现代安全基线的前提下，稳妥覆盖仍有实际流量的旧设备——比如 Windows 7 + IE11、Android 5–6 WebView、部分 Java 7u80 客户端或老旧 IoT 固件。 关键不在堆砌套件，而在**分层筛选、精准保留、明确排除**：用 TLS 1.2 的强 CBC 套件兜底旧环境，用 AEAD 套件支撑主流与未来，同时彻底切断所有已知风险路径。
只留前向保密（PFS）密钥交换
必须剔除所有静态 RSA 密钥交换套件（如 AES256-SHA、DES-CBC3-SHA），它们不支持前向保密，一旦私钥泄露，历史通信可被解密。只保留以 ECDHE- 或 DHE- 开头的套件：
- ECDHE 是首选：性能好、兼容广、移动端友好
- DHE 可按需保留：用于极少数仅支持 DHE 的嵌入式设备（如 OpenSSL 1.0.2 固件），若无此需求，建议移除以提升握手速度
主攻 AEAD 加密，慎用 CBC 套件
AES-GCM 和 ChaCha20-Poly1305 是当前唯一推荐的加密模式，全部具备认证加密（AEAD）能力，天然免疫 BEAST、POODLE 等 CBC 相关攻击。TLS 1.3 全部采用 AEAD，无需额外配置。
若需兼容 IE11（Win7/8.1）、部分金融类旧系统或 Android 5.0–6.0 App，可谨慎加入以下 仅限 TLS 1.2 的 CBC 套件（注意：不是 TLS 1.0/1.1）：
- ECDHE-RSA-AES128-SHA256 —— IE11 默认启用，安全且广泛支持
- ECDHE-RSA-AES256-SHA384 —— 少数合规场景依赖，密钥强度更高
- ECDHE-RSA-AES128-SHA —— 仅在极个别遗留系统中必要时启用（SHA1 签名已不推荐，但 IE11 仍需）
⚠️ 绝对禁用：AES256-SHA、DES-CBC3-SHA、RC4-SHA、含 MD5 或 EXPORT 的任何套件。
配合协议与曲线，堵死降级漏洞
再好的 cipher 列表，若没配对好其他指令，也会失效：
- ssl_protocols TLSv1.2 TLSv1.3; —— 必须禁用 TLS 1.0/1.1；若真要支持 Win7+IE11，可保留 TLSv1.1，但务必配合 cipher 层防御（即不启用任何 TLS 1.1 专属弱套件）
- ssl_prefer_server_ciphers off; —— Nginx 1.11.0+ 默认值，保持即可；设为 on 会禁用 TLS 1.3，得不偿失
- ssl_ecdh_curve X25519:prime256v1:secp384r1; —— X25519 优先用于 TLS 1.3，后两者保障 TLS 1.2 下 ECDHE 兼容性（尤其对 OpenSSL 1.0.2 设备）
- ssl_dhparam —— 仅 DHE 套件需要，若已移除 DHE，此行可省略
一个实测可用的平衡配置示例
适用于面向公众服务（含企业用户、移动 App、IoT 接入），兼顾 PCI DSS 合规与真实终端覆盖率：
ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384;
ssl_prefer_server_ciphers off;
ssl_ecdh_curve X25519:prime256v1:secp384r1;
说明：不含 RC4、不含 SHA1 签名（-SHA）、不含 EXPORT/NULL/ANONYMOUS，CBC 套件仅限 TLS 1.2 且带 SHA256/SHA384，全部支持 PFS。
不复杂但容易忽略。
