条件：
使用Tproxy模式代理，DNS处于mix模式。未修改shell配置的dns（保持默认基础dns为127.0.0.1）。
现象
通过日志探查到大量的：
17690 | [warning] | TCP | [TCP] dial Ⓜ️ 微软服务 (match DomainKeyword/microsoft) [240e:xxx:xxxx:xxxx:xxxx:1577:774a:33b9]:50446 --> edge.microsoft.com:443 error: connect failed: dial tcp 28.0.0.5:443: i/o timeout connect failed: dial tcp [fc00::5]:443: i/o timeout
另有cdn-apple.com、 settings-win.data.microsoft.com若干出现类似warning。
问题发生时Ⓜ️ 微软服务和apple域名归属的规则组均选择的是本地直连状态。
分析与讨论：
比较浅地看了一下代码，看到[direct server](direct-nameserver: [ $dns_nameserver ])是直接配置为基本dns的参数值的。由于把基础dns改为上游公有dns之后会导致局域网域名的失效，由此想请教一下以下一些问题：
1、为何绝大部分直连域名没有出问题，反而这种跟随规则组走直连的域名会被解析到一个无效的fakeip？是我不应该这么使用/配置吗，还是说是逻辑上有一些问题呢？
同时也对这里的原理和程序行为比较好奇：在Tproxy+mix模式这种情况下，设置基本dns为127.0.0.1，clash内核会把流量转交到dnsmasq后转交路由器上游dns吗？还是说会形成死循环：劫持到clash内核——转交127后——又被劫持到clash内核？
2、除了及时添加fakeip-filer以外，如果想要保留路由器本机提供解析服务（主要还有局域网域名的解析），是否还有更好地解决办法或者配置策略？
本人有不少地方也还是一知半解的状态，如果有说的不对的地方还请指正，望不吝赐教。
谢谢！
Environment & Conditions:
- Proxy Mode:
Tproxy
- DNS Mode:
mix
- The ShellCrash DNS settings are unmodified (the default base DNS is kept as
127.0.0.1).
Symptoms / Issue Description:
I discovered a massive amount of the following warnings in my logs:
17690 | [warning] | TCP | [TCP] dial Ⓜ️ Microsoft Services (match DomainKeyword/microsoft) [240e:xxx:xxxx:xxxx:xxxx:1577:774a:33b9]:50446 --> edge.microsoft.com:443 error: connect failed: dial tcp 28.0.0.5:443: i/o timeout connect failed: dial tcp [fc00::5]:443: i/o timeout
Similar warnings also frequently appear for domains like cdn-apple.com and settings-win.data.microsoft.com.
When this issue occurs, the rule groups handling these domains (e.g., "Ⓜ️ Microsoft Services" and Apple rules) are both explicitly set to DIRECT.
Analysis & Discussion:
I briefly looked at the source code and noticed that direct-nameserver is directly configured to inherit the parameter value of the base DNS (direct-nameserver: [ $dns_nameserver ]). Since changing the base DNS to an upstream public DNS would cause local LAN domain resolution to fail, I would like to ask the following questions:
1. Why do the vast majority of DIRECT domains work perfectly fine, but these specific domains (which are routed to DIRECT via rule groups) get resolved to an invalid Fake-IP, causing timeouts? Is this a misconfiguration on my part, or is there a logical flaw in the underlying routing process?
I'm also quite curious about the underlying principles and program behavior here:
In the Tproxy + mix DNS mode scenario, if the base DNS is set to 127.0.0.1, does the Clash core hand over the query to dnsmasq, which then forwards it to the router's upstream DNS? Or does it create a DNS loop: hijacked by the Clash core -> forwarded to 127.0.0.1 -> hijacked by the Clash core again?
2. Besides manually adding these problematic domains to the fake-ip-filter, are there any better solutions or configuration strategies if I want to retain the router's local DNS resolution service (primarily to keep LAN domains resolving correctly)?
My understanding of some of these mechanics is still a bit limited, so please feel free to correct me if I'm mistaken. Any insights or guidance would be greatly appreciated.
Thank you!
条件：
使用Tproxy模式代理，DNS处于mix模式。未修改shell配置的dns（保持默认基础dns为127.0.0.1）。
现象
通过日志探查到大量的：
17690 | [warning] | TCP | [TCP] dial Ⓜ️ 微软服务 (match DomainKeyword/microsoft) [240e:xxx:xxxx:xxxx:xxxx:1577:774a:33b9]:50446 --> edge.microsoft.com:443 error: connect failed: dial tcp 28.0.0.5:443: i/o timeout connect failed: dial tcp [fc00::5]:443: i/o timeout另有cdn-apple.com、 settings-win.data.microsoft.com若干出现类似warning。
问题发生时Ⓜ️ 微软服务和apple域名归属的规则组均选择的是本地直连状态。
分析与讨论：
比较浅地看了一下代码，看到[direct server](direct-nameserver: [ $dns_nameserver ])是直接配置为基本dns的参数值的。由于把基础dns改为上游公有dns之后会导致局域网域名的失效，由此想请教一下以下一些问题：
1、为何绝大部分直连域名没有出问题，反而这种跟随规则组走直连的域名会被解析到一个无效的fakeip？是我不应该这么使用/配置吗，还是说是逻辑上有一些问题呢？
同时也对这里的原理和程序行为比较好奇：在Tproxy+mix模式这种情况下，设置基本dns为127.0.0.1，clash内核会把流量转交到dnsmasq后转交路由器上游dns吗？还是说会形成死循环：劫持到clash内核——转交127后——又被劫持到clash内核？
2、除了及时添加fakeip-filer以外，如果想要保留路由器本机提供解析服务（主要还有局域网域名的解析），是否还有更好地解决办法或者配置策略？
本人有不少地方也还是一知半解的状态，如果有说的不对的地方还请指正，望不吝赐教。
谢谢！
Environment & Conditions:
Tproxymix127.0.0.1).Symptoms / Issue Description:
I discovered a massive amount of the following warnings in my logs:
17690 | [warning] | TCP | [TCP] dial Ⓜ️ Microsoft Services (match DomainKeyword/microsoft) [240e:xxx:xxxx:xxxx:xxxx:1577:774a:33b9]:50446 --> edge.microsoft.com:443 error: connect failed: dial tcp 28.0.0.5:443: i/o timeout connect failed: dial tcp [fc00::5]:443: i/o timeoutSimilar warnings also frequently appear for domains like
cdn-apple.comandsettings-win.data.microsoft.com.When this issue occurs, the rule groups handling these domains (e.g., "Ⓜ️ Microsoft Services" and Apple rules) are both explicitly set to
DIRECT.Analysis & Discussion:
I briefly looked at the source code and noticed that
direct-nameserveris directly configured to inherit the parameter value of the base DNS (direct-nameserver: [ $dns_nameserver ]). Since changing the base DNS to an upstream public DNS would cause local LAN domain resolution to fail, I would like to ask the following questions:1. Why do the vast majority of
DIRECTdomains work perfectly fine, but these specific domains (which are routed toDIRECTvia rule groups) get resolved to an invalid Fake-IP, causing timeouts? Is this a misconfiguration on my part, or is there a logical flaw in the underlying routing process?I'm also quite curious about the underlying principles and program behavior here:
In the
Tproxy+mixDNS mode scenario, if the base DNS is set to127.0.0.1, does the Clash core hand over the query todnsmasq, which then forwards it to the router's upstream DNS? Or does it create a DNS loop: hijacked by the Clash core -> forwarded to127.0.0.1-> hijacked by the Clash core again?2. Besides manually adding these problematic domains to the
fake-ip-filter, are there any better solutions or configuration strategies if I want to retain the router's local DNS resolution service (primarily to keep LAN domains resolving correctly)?My understanding of some of these mechanics is still a bit limited, so please feel free to correct me if I'm mistaken. Any insights or guidance would be greatly appreciated.
Thank you!