FLY_MC
> 建议不要讨论xray了，用隔壁的hy tuic完事 乐 为啥啊 有问题不让说是吧... 哈哈
> 服务器端口开放了吗 防火墙卸了，端口全开，trojan-go FullCone没问题，似乎不是服务器那边的事
> @Natsuki-Kaede 使用nekoray客户端会表现出另外一种情况，如果是使用v2ray内核加hysteria.exe的vpn模式，NatTypeTester测试显示UdpBlocked 如果切换使用sing-box内核，没有hysteria.exe情况下的vpn模式，同样的hysteria服务端，NatTypeTester测试显示FullCone 怀疑是无论clash内核加hysteria.exe或v2ray内核加hysteria.exe的情况下，有某些限制导致vpn模式（或叫tun模式）下UdpBlocked 而单内核客户端如sing-box连接hysteria服务端就会处理得比较完善，可以测试出FullCone 另外这边测试只是用了udp协议，没有使用wechat-video协议 刚刚尝试了nekoray sing-box内核，同配置无法连接orz（v2ray内核+hysteria内核下正常） 同时也试了试Clash Meta内核，测出UnsupportedServer，或许是我配置有问题，我再试试
> @Natsuki-Kaede 使用nekoray客户端会表现出另外一种情况，如果是使用v2ray内核加hysteria.exe的vpn模式，NatTypeTester测试显示UdpBlocked 如果切换使用sing-box内核，没有hysteria.exe情况下的vpn模式，同样的hysteria服务端，NatTypeTester测试显示FullCone 怀疑是无论clash内核加hysteria.exe或v2ray内核加hysteria.exe的情况下，有某些限制导致vpn模式（或叫tun模式）下UdpBlocked 而单内核客户端如sing-box连接hysteria服务端就会处理得比较完善，可以测试出FullCone 另外这边测试只是用了udp协议，没有使用wechat-video协议 刚刚修改了Clash Meta的tun配置，覆盖掉了原本的tun配置，现在支持fullcone了 客户端用的是Clash Verge，但是不知道为什么，auto-route如果改为false或者去掉了 auto-detect-interface项的注释时，就连不上了emmm tun: enable: true device: meta stack: system dns-hijack: - 'any:53' auto-route: true #auto-detect-interface: false mtu: 9000 endpoint_independent_nat: true
+1 redir-host和fake-ip均有这个问题，正确设置了namepolicy和fallback-filter后，应该直接fallback的域名仍会通过nameserver解析，并且有可能会采用nameserver中dns返回的结果 贴上我的dns字段： ``` dns: enable: true prefer-h3: true listen: 0.0.0.0:53 ipv6: true use-hosts: true default-nameserver: - 223.5.5.5 - 119.29.29.29 - tls://223.5.5.5 - https://223.5.5.5/dns-query nameserver-policy: "geosite:cn": - https://223.5.5.5/dns-query - https://doh.pub/dns-query...
> > +1 redir-host和fake-ip均有这个问题，正确设置了namepolicy和fallback-filter后，应该直接fallback的域名仍会通过nameserver解析，并且有可能会采用nameserver中dns返回的结果 > > 贴上我的dns字段： > > ``` > > dns: > > enable: true > > prefer-h3: true > > listen: 0.0.0.0:53 > > ipv6: true >...
> > 说明你就没理解fallback是干什么用的 https://wiki.metacubex.one/config/dns/diagram/ fallback和nameserver字段之间是并发关系，fallback-filter只是用来控制最终取哪边的结果，但两边**一定**都会做解析。 说到底都用meta内核了，本来就应该放弃fallback字段，哪怕meta官方也是建议只用policy字段解决 太有理解了👍 https://wiki.metacubex.one/config/dns/#fallback-filter https://wiki.metacubex.one/config/dns/?h=fallback#geosite 有没有看过这两个字段的具体解释， 首先fallback-filter字段在废弃之前是有效的，geosite规则只会使用fallback解析，我一开始设定的是geolocation-!cn ，即便如此泄露问题依然存在 另外我也尝试用nameserver-policy去准确地控制geolocation-!cn使用走代理的境外dns，结果是依然会泄露，OpenClash永远在用nameserver中设定的服务器查询 以上两种情况在Clash Verge客户端v1.182 Meta内核中不存在泄露问题 这已经说明了存在的问题
> 你都在说些什么东西。。胡子眉毛一把抓是吧。 表达“dns行为不及预期”时，都是报出具体配置文件，讲清楚tun/redirect/tproxy/mixed，并指出具体哪个网站的解析超出预期，才能正经分析的。 如果涉及到geosite，也要言明版本的。 要是只会说dns泄漏，那就是没有明确需求，鉴定为不良林看多了。那也简单，他怎么说你就怎么做咯。 回复是一句不看的，文档是完全不读的，测试是一点没有的，上来给我扣一个不良林看多了的帽子，你多少有点搞笑在里面 需求不必多说，大家差不多都是不想把某一部分域名交给nameserver进行一次多余的解析，不管是出于安全还是性能考虑。同样的透明代理passwall是不漏的，另外ipleak怎么你了，ipleak不能说明问题是吧，就说就说 别在回复我了谢谢，扣的帽子还你， 正常的issue反馈问题让你来杠出优越感了😅 edited: issue里面提到客观存在的问题您一点不提，我发的文档也一个字不看，就搁这来硬杠，歪这么多回复没一点用，不是来解决问题的话我劝您去微博玩玩，起码看的人多（
> > > 我不太明白，泄漏是指udp的dns请求被运营商等中间拦截分析的话，为什么不全部选择dot tls的请求方式不就好了吗 > > > > > > 用doh一样会被上游看到，打个比方，我用阿里doh，但是阿里的doh依然会像运营商发起dns请求，可能为了cdn会像你运营商的dns服务器发起请求，虽然我不知道运营商那边显示的是阿里发起的请求还是我。如果用谷歌的doh，那就没有意义了 > > 我觉得这有点过度焦虑了 > > * 如果是tls://223.5.5.5 只要运营商无法劫持查看修改我认为差不多就可以了，之前我就想到这个问题了，因为公司网络和运营商可能会拦截统计个人的dns解析请求来分析访问的网站，所以我全部都换为tls了， > * 即使223.5.5.5的cdn节点也会向上游dns拉取数据，我觉得也没多大所谓了，我觉得问题不大，应该更多的时候是命中缓存，而且阿里dns要解析的数据多了去了，而且偶尔解析几个国外域名也很正常，有些软件内部甚至写死了dns地址（虽然情况比较少） > * 阿里dns的cdn节点应该是阿里在管理，不是运营商就行，阿里我感觉应该没那么无聊 > * 我觉得下面这些问题更是我想知道的，有没大佬支支招 >...
> Could you explain more details of the feature you propose? > @kakkokari-gtyih I think @Natsuki-Kaede is suggesting that it should never be possible for an instance that has open...