直接用Nmap检测Nginx真实对外协商的密码套件，而非仅依赖配置文件：运行docker命令执行ssl-enum-ciphers脚本，重点关注weak/medium标记套件及不支持前向保密的TLS_RSA_WITH_*类套件，并结合debug日志与openssl s_client实测验证配置是否生效。
直接看 Nginx 实际对外协商的密码套件，而不是只检查配置文件里写了什么。很多漏洞扫描告警（比如“弱加密套件”“CVE-2016-2183”“不支持前向保密”）都源于服务器真实启用的套件与预期不符——可能被历史配置覆盖、被 CDN/网关降级、或客户端强制回退到老旧算法。
用 Nmap 快速验证真实支持的套件
这是最贴近攻击者视角的检测方式，能暴露 Nginx 真实暴露在外的加密能力：
- 运行命令：docker run --rm -v $(pwd)/results:/results securecodebox/nmap nmap --script ssl-enum-ciphers -p 443 yourdomain.com -oX /results/output.xml
- 结果中重点关注标为 weak 或 medium 的套件，例如含
DES、RC4、3DES、CBC-SHA、SHA1的条目 - 特别留意是否出现
TLS_RSA_WITH_*类套件——它们不支持前向保密（PFS），一旦私钥泄露，所有历史流量可被解密
检查 Nginx 配置是否真正生效
常见陷阱是配置写对了，但没生效或被覆盖：
- 确认
ssl_ciphers指令在http或server块中定义，且未被子块重复定义覆盖 - 检查是否启用了
ssl_prefer_server_ciphers on—— 若为off（默认值），客户端可主导选择弱套件，导致配置形同虚设 - 排查前端是否有 WAF、CDN、负载均衡器：它们可能终止 TLS 并用自己的套件重连后端，此时 Nginx 配置再强也无效
日志中定位异常协商行为
开启 OpenSSL debug 日志，观察握手阶段是否被动降级：
- 在
http { }中添加：error_log /var/log/nginx/ssl_debug.log debug; - 重启 Nginx 后，用
openssl s_client -connect yourdomain.com:443 -cipher 'AES128-SHA' -tls1_2主动触发弱套件连接 - 查看日志中是否出现 no shared cipher（说明已成功屏蔽）或 SSL_do_handshake() failed（需结合具体错误码判断）
对照权威清单人工核验关键项
一份安全的 ssl_ciphers 应同时满足：禁用弱算法、强制 PFS、优先 AEAD 模式：
- 必须排除：
DES、RC4、3DES、MD5、SHA1、TLS_RSA_WITH_* - 推荐组合（兼容主流客户端）：ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
- 若需支持旧客户端（如 Windows 7 IE11），可追加
ECDHE-RSA-AES128-SHA256，但避免引入CBC或SHA1
