升级到 v1.9.1 以上的版本后, 内网DNS解析出现一些奇怪的问题

[luanyaolingwu]

我使用的是LineageOS, 所以能很方便的打开允许客户端使用VPN的功能
所以一直以来都是手机v2RayNG挂好直接开热点分享网络出去使用了，一直到没修改路由界面前的时候使用的是 "绕过局域网地址" + 没有自定义路由, 然后更新之后发现DNS解析出现问题:

• Windows表现为显示小地球图标
• Android设备显示无网络过一段时间后会提示已连接并且能正常打开网页(进Termux手动nslookup的话也是DNS超时, 但Chrome能得的开网页 PlayStore也貌似一切正常((反正我用着没感觉出问题)

分享出来的WLAN热点是可以正常访问网络的 如下图: (加--no-sslrevoke是因为解析挂掉之后报错 curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOCATION_OFFLINE (0x80092013) - 由于吊销服务器已脱机，吊销功能无法检查吊销。 )

但很奇怪的是, 一新建一个新的IP direct置于最终代理前面任意位置 [↓↓ IP ↓↓]

0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/3,160.0.0.0/5,168.0.0.0/6,172.0.0.0/12,172.32.0.0/11,172.64.0.0/10,172.128.0.0/9,173.0.0.0/8,174.0.0.0/7,176.0.0.0/4,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4

就能正常的进行DNS解析了

所以我认为此事是一个玄学，而不是一个软件bug

因为在多次测试尝试之后，只有我一个不支持UDP的Socks代理才会这样, 走VLESS SplitHttp的UDP能过的另外一个节点并无出现问题？
所以，这是为什么捏？我对此感到好奇 (在实验前已确认路由规则为v2RayNG默认)

[2dust]

能否把你使用没有问题的版本和有问题的版本，设置一致的情况下，导出下完整配置，脱敏发出来

重构路由的时候，基本上做到了把原来的规则都转换过来了，但是也不排除漏掉或出错的

[2dust]

你前面发的ip是什么意思，能说的更详细些？

[luanyaolingwu]

先暂时忽视一下, 我的表述有点问题

我使用的是LineageOS, 所以能很方便的打开允许客户端使用VPN的功能 所以一直以来都是手机v2RayNG挂好直接开热点分享网络出去使用了，一直到没修改路由界面前的时候使用的是 "绕过局域网地址" + 没有自定义路由, 然后更新之后发现DNS解析出现问题:

• Windows表现为显示小地球图标
• Android设备显示无网络过一段时间后会提示已连接并且能正常打开网页(进Termux手动nslookup的话也是DNS超时, 但Chrome能得的开网页 PlayStore也貌似一切正常((反正我用着没感觉出问题)

分享出来的WLAN热点是可以正常访问网络的 如下图: (加--no-sslrevoke是因为解析挂掉之后报错 curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOCATION_OFFLINE (0x80092013) - 由于吊销服务器已脱机，吊销功能无法检查吊销。 )

但很奇怪的是, 一新建一个新的IP direct置于最终代理前面任意位置 [↓↓ IP ↓↓]

0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/3,160.0.0.0/5,168.0.0.0/6,172.0.0.0/12,172.32.0.0/11,172.64.0.0/10,172.128.0.0/9,173.0.0.0/8,174.0.0.0/7,176.0.0.0/4,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4

就能正常的进行DNS解析了

所以我认为此事是一个玄学，而不是一个软件bug

因为在多次测试尝试之后，只有我一个不支持UDP的Socks代理才会这样, 走VLESS SplitHttp的UDP能过的另外一个节点并无出现问题？ 所以，这是为什么捏？我对此感到好奇 (在实验前已确认路由规则为v2RayNG默认)