pymumu
带有 -fallback 参数的上游服务器，存在某些原因导致解析成功率明显偏低
问题现象
对于某个分组下，且带有 -fallback 参数的上游服务器，其成功率明显低于同组中正常使用的其他服务器。
然后经过测试，调换 -fallback 参数的服务器与同组其他服务器的顺序，发现即便这个服务器在正常使用下能保持良好的成功率，在 -fallback 时也会出现明显的成功率偏低问题。
-fallback 中的服务器既尝试过 https 也尝试过 tls ，成功率都明显偏低。
运行环境
-
固件型号
x86 linux Debian 13 -
运营商
不相关 -
smartdns来源以及版本 Github Release 最新版
-
涉及的配置(注意去除个人相关信息) 例如：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS
server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS
server-tls dns.adguard-dns.com -fallback -group globalDNS
重现步骤
- 上游DNS配置。
如上配置后，发现 dns.adguard-dns.com 这个 dns 的成功率只有 30% ，若正常使用：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS
server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS
server-tls dns.adguard-dns.com -exclude-default-group -group globalDNS # 移除 fallback 选项，且试过修改为 https 模式
则 dns.adguard-dns.com 的成功率恢复到 90% 以上的正常成功率。
- 访问的域名。
任意域名
另请考虑这样的测试：
例如： server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -fallback -group globalDNS
假设security.cloudflare-dns.com和doh.cleanbrowsing.org都无法连通（例如从防火墙上阻断），使得smartdns必然连接dns.adguard-dns.com，fallback的成功率是否会大大增加？
这么一说，雀食有个场景被我忽略掉了，那就是如果 globalDNS 组走的线路本身就已经挂了，那必然同组的 fallback 也用不了。
不过我测试的时候是这么测的，并没有人为的造成线路本身不可用，我是利用多开 https://browserleaks.com/dns 这种 dns 泄露测试工具，来触发上游 dns 的请求 qps 限制，此时 cf 和 cleanbrowsing 的 qps 限制会很快打满，然后就能观察到 smartdns 开始启用同组的 fallback dns 了。
我还尝试过在 globalDNS 组中只写一个 server-tls dns.adguard-dns.com -fallback -group globalDNS 此时，再用前面说的工具，可以发现成功率是正常的。
由于我还没研究上游服务器返回什么代码，或者是通过什么标志位来让 smartdns 触发 fallback ，因此我推测当进入 fallback dns 流程时，由于 fallback dns 需要重新 tls 或者 https 握手，但是请求本身没有 hold 主，导致在 dns 在建立通信连接之前，这个 dns 查询已经超时了，最终现象就是同组 fallback 的 dns 成功率很低。
问题现象
对于某个分组下，且带有
-fallback参数的上游服务器，其成功率明显低于同组中正常使用的其他服务器。然后经过测试，调换
-fallback参数的服务器与同组其他服务器的顺序，发现即便这个服务器在正常使用下能保持良好的成功率，在-fallback时也会出现明显的成功率偏低问题。
-fallback中的服务器既尝试过https也尝试过tls，成功率都明显偏低。运行环境
- 固件型号 x86 linux Debian 13
- 运营商 不相关
- smartdns来源以及版本 Github Release 最新版
- 涉及的配置(注意去除个人相关信息) 例如：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -fallback -group globalDNS重现步骤
- 上游DNS配置。 如上配置后，发现 dns.adguard-dns.com 这个 dns 的成功率只有 30% ，若正常使用：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -exclude-default-group -group globalDNS # 移除 fallback 选项，且试过修改为 https 模式则 dns.adguard-dns.com 的成功率恢复到 90% 以上的正常成功率。
- 访问的域名。 任意域名
都是国外DNS，有共同特性：QoS，全不通。 国外DNS，必须走代理，直连不可靠。
问题现象 对于某个分组下，且带有
-fallback参数的上游服务器，其成功率明显低于同组中正常使用的其他服务器。 然后经过测试，调换-fallback参数的服务器与同组其他服务器的顺序，发现即便这个服务器在正常使用下能保持良好的成功率，在-fallback时也会出现明显的成功率偏低问题。-fallback中的服务器既尝试过https也尝试过tls，成功率都明显偏低。 运行环境
- 固件型号 x86 linux Debian 13
- 运营商 不相关
- smartdns来源以及版本 Github Release 最新版
- 涉及的配置(注意去除个人相关信息) 例如：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -fallback -group globalDNS重现步骤
- 上游DNS配置。 如上配置后，发现 dns.adguard-dns.com 这个 dns 的成功率只有 30% ，若正常使用：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -exclude-default-group -group globalDNS # 移除 fallback 选项，且试过修改为 https 模式则 dns.adguard-dns.com 的成功率恢复到 90% 以上的正常成功率。
- 访问的域名。 任意域名
都是国外DNS，有共同特性：QoS，全不通。 国外DNS，必须走代理，直连不可靠。
这里本来就不存在直连这个情况
问题现象 对于某个分组下，且带有
-fallback参数的上游服务器，其成功率明显低于同组中正常使用的其他服务器。 然后经过测试，调换-fallback参数的服务器与同组其他服务器的顺序，发现即便这个服务器在正常使用下能保持良好的成功率，在-fallback时也会出现明显的成功率偏低问题。-fallback中的服务器既尝试过https也尝试过tls，成功率都明显偏低。 运行环境
- 固件型号 x86 linux Debian 13
- 运营商 不相关
- smartdns来源以及版本 Github Release 最新版
- 涉及的配置(注意去除个人相关信息) 例如：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -fallback -group globalDNS重现步骤
- 上游DNS配置。 如上配置后，发现 dns.adguard-dns.com 这个 dns 的成功率只有 30% ，若正常使用：
server-https https://security.cloudflare-dns.com/dns-query -exclude-default-group -group globalDNS server-https https://doh.cleanbrowsing.org/doh/security-filter/ -exclude-default-group -group globalDNS server-tls dns.adguard-dns.com -exclude-default-group -group globalDNS # 移除 fallback 选项，且试过修改为 https 模式则 dns.adguard-dns.com 的成功率恢复到 90% 以上的正常成功率。
- 访问的域名。 任意域名
都是国外DNS，有共同特性：QoS，全不通。 国外DNS，必须走代理，直连不可靠。
这里本来就不存在直连这个情况
配置反映不出来。 DNS走代理得特别处理。
另外发现了 tcp 上游 dns 成功率也偏低（带有 -bootstrap-dns ），目前成功率比较高的是字节的 dns 180.184.1.1 ，成功率较低的是 alidns 223.5.5.5 223.6.6.6 2400:3200::1 2400:3200:baba::1 ，很低的是 114dns 114.114.114.114 114.114.115.115 。但是当我手动用 kdig +tcp 命令去查的时候，又能持续查询，即 kdig 命令没有失败的。
成功率这个叫法可能有误导，其实应该是结果采纳率
这样的么，我简单捋了下代码，看到原始数据都是类似 success_count 这样的。
我理解的成功率是指，是否正常从上游 dns 拿到了结果，如果上游 dns 无响应或者不可达了，那么就是一次对该上游 dns 的失败。
成功率和采纳率是两个完全不一样的定义呀