nginx -t仅校验语法，无法识别ssl_ciphers中废弃套件；需结合openssl ciphers -v查实际支持列表、nmap ssl-enum-ciphers实测广播套件，并注意TLS1.3套件须用TLS13-前缀声明。
直接用 nginx -t 无法判断 ssl_ciphers 中的套件是否已废弃，它只校验语法和文件路径。真正要识别废弃套件，得结合 OpenSSL 版本行为、Nginx 解析逻辑与实际协商结果来交叉验证。
看 OpenSSL 支持范围是否覆盖所列套件
Nginx 本身不定义哪些套件“有效”，而是把 ssl_ciphers 字符串传给 OpenSSL。若 OpenSSL 版本太旧（如 1.0.2），它根本不认识 TLS_AES_128_GCM_SHA256；若版本太新（如 3.0+），又可能默认禁用 ECDHE-RSA-AES128-SHA 这类 SHA-1 套件。
- 查当前 Nginx 链接的 OpenSSL：
nginx -V 2>&1 | grep -i openssl - 查该 OpenSSL 实际支持的套件列表：
openssl ciphers -s -v 'ALL:COMPLEMENTOFDEFAULT' | head -20（注意加引号避免 shell 解析） - 若你在
ssl_ciphers里写了ECDHE-RSA-AES128-SHA，但在上述命令输出中找不到，说明该套件已被 OpenSSL 废弃或编译时禁用
用 nmap 或 sslscan 看真实启用的套件
配置写得再全，没被 OpenSSL 加载或被协议层过滤，就等于不存在。必须实测服务端实际广播了哪些套件。
- 运行：
nmap --script ssl-enum-ciphers -p 443 your-domain.com - 重点看输出中带 broken、weak、insecure 标签的条目，比如
TLS_ECDHE_RSA_WITH_RC4_128_SHA或TLS_RSA_WITH_3DES_EDE_CBC_SHA——这些就是明确被标准认定为废弃的 - 若某套件出现在你的
ssl_ciphers配置里，但扫描结果中完全没出现，说明它已被 OpenSSL 忽略（即逻辑上“已废弃”）
检查配置中是否混入已移除的命名方式
OpenSSL 1.1.1+ 起逐步淘汰部分旧命名，Nginx 不报错但实际无效：
-
AES128-SHA（无 ECDHE 前缀）→ 仅 RSA 密钥交换，TLS 1.2 下仍可用，但 TLS 1.3 已彻底移除，且现代审计视为弱套件 -
ECDHE-ECDSA-AES128-SHA256→ SHA256 是哈希，不是问题；但若证书是 RSA，客户端不会选 ECDSA 套件，形同虚设 -
!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA这类排除项比硬写套件列表更可靠，避免遗漏新增废弃项
留意 TLS 1.3 的特殊处理规则
TLS 1.3 套件（如 TLS_AES_128_GCM_SHA256）不参与 ssl_ciphers 的传统排序逻辑，必须显式前置并用 TLS13- 前缀声明，否则可能被降级到 TLS 1.2 套件。
- 错误写法：
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:TLS_AES_128_GCM_SHA256;（TLS 1.3 套件被忽略） - 正确写法：
ssl_ciphers TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256; - 若配置含 TLS 1.3 套件但扫描结果中只有 TLS 1.2 套件，说明 TLS 1.3 套件未生效，本质是“配置了也等于废弃”
