排查nginx tls签名算法不支持问题需结合error.log日志分析（如no suitable signature algorithm）与openssl s_client实测客户端支持的signature algorithms，再核对ssl_conf_command配置是否拼写正确、范围过严或与旧客户端兼容性冲突。
排查 Nginx TLS 协商中签名算法（Signature Algorithms）不支持的问题，关键不是猜配置，而是让日志和实测说话——错误往往藏在 OpenSSL 的具体报错里，而不是“握手失败”四个字。
看 error.log 里有没有 signature 相关线索
打开 /var/log/nginx/error.log，搜索含 SSL_do_handshake() failed 的行，重点看紧邻的 OpenSSL 错误码和文字描述：
- 出现 error:14094410:SSL routines:ssl3_read_bytes:handshake failure，且上下文无证书链或版本提示 → 很可能卡在签名算法协商阶段
- 出现 tlsv1 alert illegal parameter 或 tlsv1 alert unsupported certificate → 客户端发来的签名算法列表被服务端拒绝，常见于服务端用
ssl_conf_command SignatureAlgorithms过度收紧 - 若日志中明确出现 no suitable signature algorithm（debug 日志级别下可见），基本可锁定为签名算法无交集
用 openssl s_client 实测客户端实际发送了哪些签名算法
模拟真实 ClientHello，观察它声明支持哪些签名算法：
- 运行：
echo | openssl s_client -connect yourdomain.com:443 -tls1_2 -servername yourdomain.com 2>&1 | grep "Signature Algorithms" - 若返回空或只显示极少数（如仅
ecdsa_secp256r1_sha256），而你的 Nginx 配置中强制指定了更窄的集合（比如只留rsa_pss_rsae_sha256），旧客户端（如 Android 4.4、Java 7/8u1xx）就会失败 - 对比不同客户端：用 iOS 12、Android 8、curl 7.58、Java 11 分别测试，确认是普遍失败还是特定环境
检查 ssl_conf_command SignatureAlgorithms 是否写错或过严
这个指令不参与密码套件协商，但会直接干预签名算法列表的发送。常见问题：
-
大小写/拼写必须完全匹配 OpenSSL 官方命名：写成
signaturealgorithms或Signature_Algorithms会静默失效，Nginx 日志只警告unknown command，实际仍走默认列表 -
剔除 SHA-1 类算法是安全做法，但需注意兼容性：如配置
ssl_conf_command SignatureAlgorithms ecdsa_secp256r1_sha256:rsa_pss_rsae_sha256;，则 IE11/Win7、Android 4.4 及更早系统无法完成握手——这不是 bug，是主动放弃兼容 - 不要盲目加冒号结尾或多余空格：末尾多一个空格，OpenSSL 解析失败，配置等同于没写
临时绕过配置，验证是否真由签名算法导致
快速判断问题归属：
- 注释掉所有
ssl_conf_command SignatureAlgorithms行，reload Nginx，再试连接。如果恢复成功，问题就出在这里 - 用
openssl ciphers -V 'ECDHE-ECDSA-AES128-GCM-SHA256'查该套件默认绑定的签名算法，确认是否与你的ssl_conf_command冲突 - 若业务必须兼顾老旧终端，可放宽为：
ssl_conf_command SignatureAlgorithms ecdsa_secp256r1_sha256:rsa_pkcs1_sha256:rsa_pss_rsae_sha256;，保留 PKCS#1 v1.5 作为 fallback
