DNS并发查询在IPv6模式下似乎没有生效，大幅拖慢查询速度达到35459ms

im-Kalix

其他人有这个问题吗？我在两个WiFi下都是一样的情况。似乎是路由器会针对发往IPv6地址的DNS查询做限速处理，但为什么发往其他地址的DNS查询也被拖累了？
查询时间在DNS结果页面的记录和最近请求页面的记录是对应的，网络访问速度确实被拖慢了。

［详情］
域名		www.baidu.com
来自服务器	119.29.29.29
地址		14.215.177.39
		14.215.177.38
路径
时间开销		8312 ms
过期时间		239 s

［详情］
域名		hpd.baidu.com
来自服务器	fe80:c283:c9ff:fe07:e1cd
地址		180.101.212.33
路径
时间开销		9185 ms
过期时间		539 s

［详情］
域名		hk9.cf4589a1-71ec-429f-b46a-892af2259b8e.yiyuan.cyou
来自服务器	fe80::c283:c9ff:fe07:e1cd
地址		120.240.163.186
路径
时间开销		35459 ms
过期时间		457 s

im-Kalix

为什么QuantumultX就没有这个问题，Surge就会这样？在实现方式上有什么区别？是否可以改进？

im-Kalix

https://t.me/SURGEPRO/851123
相关讨论在此，其他人成功复现了。

im-Kalix

https://t.me/SURGEPRO/851162
如果Surge能实现图中第三个选项，那就可以解决问题了。

im-Kalix

im-Kalix 这一条我好像理解反了，总之Surge在收到IPv4解析结果后就不必等待IPv6的DNS回应。

im-Kalix

推测是路由器会在返回IPv4记录后拦截相应的IPv6查询结果，以达到强迫IPv4优先的目的。由于Surge在IPv6模式下，收到IPv4查询结果后依然等待IPv6查询，从而造成查询大幅延迟。

需要注意的是，只有DNS服务器直接返回IP地址，而不包含NS记录的时候（即DNS查询详情界面内“路径”栏为空），才会出现上文所说的情况。

im-Kalix

在关闭VPN的情况下，Safari访问http://testipv6.cn/，可以通过全部测试，而且速度很快不会有延迟。
大概率iOS系统的DNS查询方式就是我说的这种，收到IPv4回复后就不会等待IPv6的查询结果。

http://testipv6.cn/mirrors.html.zh_CN
在上面这个网页中，分别在三种环境下进行测试：

彻底关闭VPN；
打开QuantumultX（开启IPv6，全局直连模式）；
打开Surge（开启IPv6，IPv6 VIF为自动，全局直连模式）。

其中1和2的测试都能在几秒钟内完成，而3的测试要花上十几甚至几十秒。

im-Kalix

针对本帖提到的问题，有两种解决方法：

1、在Surge关闭的状态下，先开启IPv6，再启动Surge，然后再关闭IPv6，保存配置。
使用这种方法可以在开启IPv6的同时解决DNS查询速度延迟的问题。
此时的IPv6看似是关闭状态，但实际上Surge依然会发起AAAA查询，同时此时的查询速度是正常的。
【缺点】在Surge关闭或重启后此状态就会失效，需要重复上述操作才能再次解决问题。

【附注】可以使用 http://testipv6.cn/ 检验此方法的效果。这个网站自带了计时功能，可以同时观察连接所消耗的时长。但是在测试前需要先清理DNS缓存，否则会影响计时结果。

2、使用加密DNS：在DNS面板配置加密DNS，比如 https://dns.alidns.com/dns-query 。这时候也不会出现DNS查询延迟的问题。
【缺点】查询速度比默认DNS略慢。且在我过去几个月的使用过程中会偶尔发生DNS查询失效的问题，必须重启Surge才能解决。

希望以上两种我发现的现象可以为这个问题的研究和维护提供帮助。🙂

LisonFan

应该是因为没有 NS 记录导致的查询时间开销很大