@xy #133 我所有的原生解锁机都显示DNS解锁，不管哪个商家的都一样，不管是否原生解锁，脚本内只要使用了Check_DNS_2函数的地方(Dazn/HotStar/Disnety+/Netflix/TVBAnywhere+)，而dns客户端又是smartdns这种，对公共上游（比如8.8.8.8）返回的多个地址进行最优连接速度筛选，只返回单个IP的，一律误判为DNS解锁。问题出在脚本判断不在商家 Check_DNS_1和Check_DNS_3判断逻辑倒问题不大，前者判断是否返回rfc1918私有地址，后者对于一个虚构子域名判断是否无条件返回IP，唯独Check_DNS_2只判断返回IP个数不太可靠
@buggysoul #138 其实脚本不是万能的，这个脚本的初衷更多的是对于在新装机状态，或者自己了解机器情况的状态下进行测试，在最大程度上还原真实的解锁性质。比如说一开始我在最初的几个版本上加入了“代理解锁”、“warp解锁等”等功能，但是这些功能的引入，会不同程度产生一些负面影响（哪怕概率极低的微小影响），考虑到这些都是机器使用者主观开启的功能，或是在购买机器时心知肚明的，所以后续又不得不阉割掉，所以现在如果你开启代理服务器，或者使用warp，脚本都会显示“原生解锁”，当然这明显是误判，但是没有办法，脚本并非万能，不得不两害相权取其轻。所以对于一些自己架设的功能，脚本宁愿选择绕过，也要保持在系统纯净状态下，最大程度的准确判断，请您理解
@buggysoul #130 大部分流媒体都不使用这一条判断
@xy #131 问题是我的半屏都显示DNS解锁，实际并不是
@buggysoul #132 感谢分享，麻烦贴个图，然后具体是哪个商家？
@xy #133 我所有的原生解锁机都显示DNS解锁，不管哪个商家的都一样，不管是否原生解锁，脚本内只要使用了Check_DNS_2函数的地方(Dazn/HotStar/Disnety+/Netflix/TVBAnywhere+)，而dns客户端又是smartdns这种，对公共上游（比如8.8.8.8）返回的多个地址进行最优连接速度筛选，只返回单个IP的，一律误判为DNS解锁。问题出在脚本判断不在商家
Check_DNS_1和Check_DNS_3判断逻辑倒问题不大，前者判断是否返回rfc1918私有地址，后者对于一个虚构子域名判断是否无条件返回IP，唯独Check_DNS_2只判断返回IP个数不太可靠
@buggysoul #132 了解了，你是在每台小鸡上都安装了smartdns吧，因为别人都没这个问题，我需要判断一下是否有需要去掉这个机制
@xy #135 是的，每台解锁机都装了smartdns，优选速度最快的IP对看流媒体太重要了
@buggysoul #136 其实理论上讲，你的smartdns是对本地dns的劫持（优化）行为，这种行为正好符合dns解锁的特征，所以严格意义上来说，脚本并没有判断错
@xy #137 某种意义上确实是，只是不明真相的会对结果存在疑惑，我个人了解真实情况倒无所谓
@buggysoul #138 其实脚本不是万能的，这个脚本的初衷更多的是对于在新装机状态，或者自己了解机器情况的状态下进行测试，在最大程度上还原真实的解锁性质。比如说一开始我在最初的几个版本上加入了“代理解锁”、“warp解锁等”等功能，但是这些功能的引入，会不同程度产生一些负面影响（哪怕概率极低的微小影响），考虑到这些都是机器使用者主观开启的功能，或是在购买机器时心知肚明的，所以后续又不得不阉割掉，所以现在如果你开启代理服务器，或者使用warp，脚本都会显示“原生解锁”，当然这明显是误判，但是没有办法，脚本并非万能，不得不两害相权取其轻。所以对于一些自己架设的功能，脚本宁愿选择绕过，也要保持在系统纯净状态下，最大程度的准确判断，请您理解
docker 镜像似乎不存在