问题的表现是同样两个的节点(一个是日本的JPOS_1机房,一个是香港的IPLC线路,正常来讲这两个节点在上海/江苏应该都可以访问且延迟是比较低的,而考虑到江苏的网络情况推断日本的节点表现会更加好),日本节点在上海能够正常访问,但回了江苏之后就无法访问了,节点测试 fail ;而使用香港节点虽然可以正常访问,但速度非常缓慢。
本以为是的 ClashX Pro的问题,但发现手机上的QuantumultX两个节点延迟都是50+ms的延迟,而且访问速度很快。删除ClashX Pro重装ClashX并不能解决问题。 进一步排查问题,查看日志可以看到的很关键的一条:
all DNS requests failed, first error: dial tcp4 1.1.1.1:53
且观察到IP解析出来都是198.18 ,Enhanced Mode Config-DNS Mode
是 fake-ip
。考虑到在家里的翻墙方式是R2S的软路由透明代理实现的,且用了Fake-IP的模式,为了尽量避免麻烦和不必要的影响因素,即便fake-ip可以加速代理的速度(节约一次解析DNS的时间),也把ClashX Pro的DNS Mode 改成 Mapping,这样可以保证不在家的情况下使用ClashX 解析出来的结果都是正常的IP而不是软件中的fake-ip,这样尽可能分离开两个fake-ip模式下会有的理解上的不一致(即便可能ClashX Pro的DNS Mode也选fake-ip也不会存在问题,但毕竟没有尝试过)。
当改变了这个设置之后,发现原先配置的节点域名可以正常解析到自己本来的IP而不是fake-ip了,但问题还是存在,访问极慢且提示1.1.1.1的53解析失败了。尝试着把配置中的dns直接关掉也不能解决问题,于是一个一个路径地注释1.1.1.1
最后发现是 fallback
中的地址链接失败了。
配置为
|
|
根据这个帖子1可以明白clash的解析逻辑是并发请求nameserver
和fallback
中的所有的dns服务器,拿到最快的一个结果看是否是的CN的IP,如果不是则返回fallback
中的解析最快的一个的结果(不是很理解这个逻辑,如果这样的话fallback
被投毒(不确定可行性)或者连不通不就会导致代理存在问题么?就像我这次碰到的问题一样)。telnet一下可以发现确实在江苏无法正常连通 1.1.1.1
这个IP的53端口,至此问题已经确认,那么需要做的就很简单,通过查阅一些别人的配置我在fallback
中新增了两个 DNS 服务:
|
|
再次尝试之后发现果然在江苏不论是哪个节点都可以正常翻墙,且访问速度非常快,所有网页都能很快打开。
参考
记一次解决 clash all DNS requests failed, context deadline exceeded 问题
在 Clash 中 DNS 解析行为和 fallback-filter 的一点理解
[Feature]希望可以由用户显式设置 Nameserver 和 Fallback DNS 是否通过代理来解析域名 #857