最有效且合规的做法是直接在ssl_ciphers中显式排除RC4、DES、3DES、MD5、SHA1等弱算法，配合ssl_protocols TLSv1.2 TLSv1.3，并保持ssl_prefer_server_ciphers off以确保TLS 1.3生效且协商强套件。
直接在 ssl_ciphers 指令中显式排除 RC4、DES、3DES、MD5、SHA1 等已知不安全算法，是最有效且合规的做法。关键不是“加什么”，而是“明确去掉什么”——避免默认配置引入风险套件。
明确禁用弱算法的写法
推荐使用清晰、可读性强的排除式语法：
ssl_ciphers 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:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;- 或更简洁但等效的排除写法：
ssl_ciphers HIGH:!aNULL:!MD5:!RC4:!3DES:!DES:!EXPORT:!SHA1:!DSS; - 其中
!RC4、!3DES、!DES是硬性移除项，!aNULL去掉匿名认证，!MD5和!SHA1避免哈希降级风险
配合 ssl\_protocols 确保协议层安全
仅改 ssl_ciphers 不够，必须同步收紧协议支持范围：
- 强制启用 TLSv1.2 和 TLSv1.3：
ssl_protocols TLSv1.2 TLSv1.3; - 务必禁用 TLSv1.0 和 TLSv1.1：
ssl_protocols中不能出现它们 - TLSv1.3 默认套件已是强加密（AES-GCM/ChaCha20），无需在
ssl_ciphers中重复指定
验证是否真正生效
配置后必须验证，不能只看 Nginx 是否启动成功：
- 用
nmap --script ssl-enum-ciphers -p 443 your-domain.com扫描，确认输出中无RC4、3DES、DES、MD5、SHA1等关键词，且标记为broken或weak的套件全部消失 - 检查浏览器开发者工具 → Security 标签页，查看实际协商出的 Cipher Suite，应为类似
TLS_AES_128_GCM_SHA256（TLS 1.3）或ECDHE-RSA-AES128-GCM-SHA256（TLS 1.2） - 注意：若仍看到
CBC模式（如AES128-CBC-SHA），说明配置未生效或被覆盖，需排查是否遗漏ssl_prefer_server_ciphers off（Nginx 1.11.0+ 默认值，勿设为 on）
常见误区提醒
这些操作看似简单，但容易踩坑：
- 不要用
ssl_ciphers DEFAULT或留空——Nginx 旧版本默认含 RC4/3DES；新版本虽已改进，但仍建议显式声明 - 避免混用宏与具体套件，例如
HIGH:ECDHE-RSA-AES128-GCM-SHA256:!RC4可能因 OpenSSL 解析顺序导致意外保留弱套件 -
ssl_prefer_server_ciphers on会禁用 TLS 1.3，必须保持off（默认值） - DHE 套件可保留用于兼容极少数老旧设备，但若业务无此需求，建议移除以提升性能和安全性
