UDP流量会在本地发起DNS请求？

[Minhao-Geng]

我所有的ip-rules都加了no-resolve，按理来说走节点的流量不会有本地dns请求，dns解析应该都是节点服务器完成。

只有cn的流量是本地解析。tcp这块倒是没问题，所有墙外流量都是代理解析dns，我昨天开了respect rules然后nameserver只写

• https://1.1.1.1/dns-query
• https://8.8.8.8/dns-query。
  direct nameserver 用阿里和腾讯公共dns，所以国内流量都是国内这俩dns解析。

问题出在我看log时发现cloudflare和google这两dns走了代理，说明一定有dns解析从本地发出，这个log后一条就是个udp流量，说明前面那个1.1.1.1的代理是为了获取这个udp流量的real ip。 这udp请求一定会在本地发起dns吗？我的兜底rule是走代理，所以不存在有不匹配的域名走直连。

我的配置如下·：

dns:
  default-nameserver:
  - https://223.6.6.6/dns-query
  - tls://223.5.5.5
  direct-nameserver:
  - https://223.5.5.5/dns-query
  - tls://223.6.6.6
  - https://doh.pub/dns-query
  - dot.pub
  direct-nameserver-follow-policy: false
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
  - '*.lan'
  - '*.local'
  - '*.arpa'
  - time.*.com
  - ntp.*.com
  - time.*.com
  - +.market.xiaomi.com
  - localhost.ptlogin2.qq.com
  - '*.msftncsi.com'
  - www.msftconnecttest.com
  fake-ip-filter-mode: blacklist
  fake-ip-range: 198.18.0.1/16
  fallback-filter:
    domain: []
    geoip: false
    geoip-code: CN
    ipcidr: []
  ipv6: false
  listen: :53
  nameserver:
  - https://1.1.1.1/dns-query
  - https://8.8.8.8/dns-query
  prefer-h3: true
  proxy-server-nameserver:
  - https://223.5.5.5/dns-query
  - tls://223.6.6.6
  - https://doh.pub/dns-query
  - dot.pub
  respect-rules: true
  use-hosts: false
  use-system-hosts: true

[mengdegege]

观察来看，确实是这样，UDP连接貌似都必须传递IP，所以会在出站前发起解析。
搜了一下，据一些消息片段了解，有的项目在尝试或者已经实现在UDP代理中传递域名代理服务器，具体没有去实测过。可能需要服务端的配合。
这一块应该是涉及UDP协议的底层机制相关，或者不同的代理协议有不同的处理方式，可能还要配合服务端的支持。水平有限，也是搞不太懂。

只知道UDP出站，不管是直连还是代理，都必须解析，如果出站代理不支持UDP，就会继续往下匹配，直到最后一条规则（除非主动拒绝），还是会发起解析。所以通常认为的走代理的都不需要解析这个行为，不适用于UDP。如果很在意DNS泄露之类的问题，除了避免IP类型规则外，还要注意UDP流量。UDP请求（特别是google，也包括其他的一些采用了quick的应用和站点）会导致需要代理的域名，在没有很严格的dns policy的情况下，直接用nameserver解析。
另一种做法就是，直接把可能走代理的UDP流量全部拦截了，尤其是在代理链路对UDP支持可能不是太好的情况下。实测下来拦截UDP对于一般使用场景的体验更好。

[mengdegege]

找了几个singbox客户端对比了一下，发现这个确实是mihomo特有的现象。其他的基本是按规则，如果代理域名启用了fake ip就是下发fake ip，有的日志疑似出站前是解析了一次，但依然拿到的是fake ip。而且不管是sing 还是 mihomo的日志显示和连接列表，看起来最终连接的目标其实都是域名。如果这样的话那这一次跳过fake ip的解析是bug吗？还是有什么特别的用意呢。希望有懂的人能赐教一下。虽然不是很在乎DNS泄露，按照现有的DNS 策略也可以避免所谓的泄露。
就单纯比较想知道，这个解析是不是必须的。
而且，如果要为了去迎合这个解析行为，专门去配置复杂的 本来可以依靠fakeip就全部省去的复杂策略，实测下来是对网络流畅性有影响的，还挺明显。现在为了体验只能直接拒绝udp(感觉不完整了😰)。
这是nekobox上的日志


下面这个是meta的

而如果拦截udp，则不会有这种解析行为，反复测试下来基本上很明确这种解析动作是udp连接触发的。

[sMetase]

应该是这样的情况，翻到 Mihomo 内核的更新说明：

端午节内核更新
https://github.com/MetaCubeX/mihomo/releases/tag/v1.19.10
https://github.com/MetaCubeX/ClashMetaForAndroid/releases/tag/v2.11.13
整体udp部分的dns解析已延迟到连接发起阶段，在rule匹配过程中仅匹配没有配置no-resolve的ip规则时会触发。
对于direct和wireguard出站，会遵循和tcp部分相同的逻辑，即当direct-nameserver（或wireguard配置的dns）存在时丢弃rule匹配过程中的解析结果对域名发起重解析。该重解析逻辑仅对fakeip生效。
对于reject和dns出站，不再需要解析。
对于其他出站依然会在udp连接发起时进行解析，目前不会将域名直接发送到远程服务器上。
此外该版本tun入站的udp部分内存占用也已优化。

[mengdegege]

应该是这样的情况，翻到 Mihomo 内核的更新说明：

端午节内核更新
https://github.com/MetaCubeX/mihomo/releases/tag/v1.19.10
https://github.com/MetaCubeX/ClashMetaForAndroid/releases/tag/v2.11.13
整体udp部分的dns解析已延迟到连接发起阶段，在rule匹配过程中仅匹配没有配置no-resolve的ip规则时会触发。
对于direct和wireguard出站，会遵循和tcp部分相同的逻辑，即当direct-nameserver（或wireguard配置的dns）存在时丢弃rule匹配过程中的解析结果对域名发起重解析。该重解析逻辑仅对fakeip生效。
对于reject和dns出站，不再需要解析。
对于其他出站依然会在udp连接发起时进行解析，目前不会将域名直接发送到远程服务器上。
此外该版本tun入站的udp部分内存占用也已优化。

那就应该是了，只是对比下来同样的ss出站节点，sb好像不会有这种解析，也不知道是日志没有体现出来，还是确实是实现上面有差异。感觉这种UDP流量如果说技术上可以实现发送域名的话，直接传递域名是不是会更优一些？而且，因为这种解析的需要，会使得域名解析策略变得很复杂。

[nasaboy]

[mengdegege]

tcp没有发现,如果有这种情况, 可以检查一下在这个命中的规则及以上规则里有没有IP类型规则且没有加no-resolve的.

[nasaboy]

确实是我自己搞错了，没启用fake-ip模式