关键在于白名单式精确控制，即仅保留ECDHE-ECDSA/RSA-AES128/256-GCM-SHA256/384、CHACHA20-POLY1305等PFS+AEAD强套件，禁用3DES、RC4、MD5；配合ssl_protocols TLSv1.2 TLSv1.3和ssl_prefer_server_ciphers off等指令，在TLS握手阶段主动拒绝弱算法协商。
要真正禁用 3DES、RC4 和 MD5 这类高危弱加密算法，关键不是“删掉几个名字”，而是通过 ssl_ciphers 配置实现**白名单式精确控制**——只保留现代强套件，从源头排除所有含这些算法的协商可能。
只保留支持前向保密（PFS）和 AEAD 的强套件
3DES、RC4、MD5 均属于已被标准弃用的算法，Nginx 不会主动过滤它们，除非你明确不列出来。推荐直接使用以下显式白名单（兼容 TLSv1.2，TLSv1.3 自动启用更强默认）：
ECDHE-ECDSA-AES128-GCM-SHA256ECDHE-RSA-AES128-GCM-SHA256ECDHE-ECDSA-AES256-GCM-SHA384ECDHE-RSA-AES256-GCM-SHA384ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305
这些套件全部满足：ECDHE 密钥交换（保障前向保密）、AES-GCM 或 ChaCha20-Poly1305（AEAD 认证加密）、SHA256/SHA384（安全哈希），且不含任何 3DES、RC4、MD5 字样。
严格配合 ssl\_protocols 和其他关键指令
单设 ssl_ciphers 不够，必须协同收紧协议层与协商逻辑：
-
ssl_protocols TLSv1.2 TLSv1.3;—— 彻底禁用 TLSv1.0/v1.1 及更早协议（它们天然允许弱套件） -
ssl_prefer_server_ciphers off;—— 现代客户端协商更可靠；设为on反而可能干扰 TLSv1.3 协商 -
ssl_ecdh_curve secp384r1:secp521r1;—— 避免使用弱椭圆曲线（如 sect163k1） -
ssl_dhparam /etc/nginx/dhparam.pem;—— 若启用 DHE，需提供 ≥3072 位 DH 参数
验证是否真已清除，别信配置文件写了什么
配置重启后，必须实测服务器实际对外暴露的套件：
- 运行
nmap --script ssl-enum-ciphers -p 443 your-domain.com，确认输出中无3DES、RC4、MD5、SHA（非 SHA256/SHA384）等关键词，且无标记为 weak 或 broken 的条目 - 用
openssl s_client -connect your-domain.com:443 -cipher "3DES" -tls1_2测试，应返回handshake failed或no ciphers available - 浏览器打开 DevTools → Security 标签页，查看 Cipher Suite，应显示类似
TLS_AES_128_GCM_SHA256（TLSv1.3）或ECDHE-RSA-AES128-GCM-SHA256（TLSv1.2）
常见误操作与规避建议
很多团队改完仍被扫描报高危，问题常出在细节：
- 避免用
HIGH:!RC4:!3DES类模糊写法——HIGH在不同 OpenSSL 版本含义不同，无法保证清除干净 - 不要混用宏与具体套件，例如
HIGH:ECDHE-RSA-AES128-GCM-SHA256:!RC4可能因解析顺序意外保留弱套件 - 切勿留空
ssl_ciphers或设为DEFAULT——旧版 Nginx 默认含 RC4/3DES，新版虽改进但仍建议显式声明 - 注意
-SHA默认指 SHA1，ECDHE-RSA-AES128-SHA就是违规项；只有-SHA256或-SHA384才合规
