[Bug]: 关于在预设V3-绕过大陆路由规则下Shadowsocks切换至sing-box 内核时 gstatic.com 无法访问导致Google登录出现静态资源无法获取点击登录无反应 #5383

ambiguous-pointer · 2024-07-18T11:09:57Z

ambiguous-pointer
Jul 18, 2024

预期情况

切换至sing-box 内核时 gstatic.com 应该走国内分流

实际情况

在预设V3-绕过大陆路由规则下Shadowsocks协议切换至sing-box 内核时 gstatic.com 无法访问这个网站需要cn内访问但是似乎被错误解析了导致访问失败，但是开启全局代理会可以访问，但这应该并不是正常的。

复现方法

管理员运行程序
设置->参数设置
Core类型设置
Shadowsocks切换至sing-box
点击确实关闭设置窗口
路由规则选择V3-绕过大陆
开启代理
访问 gstatic.com失败

日志信息

以下时切换至sing-box内核时的日志信息【似乎是因为命中了match[1] rule_set=geosite-geolocation-!cn => remote】
+0800 2024-07-18 18:40:15 INFO [1131983404 0ms] inbound/http[http]: inbound connection from 127.0.0.1:63466
+0800 2024-07-18 18:40:15 INFO [1131983404 0ms] inbound/http[http]: inbound connection to www.gstatic.com:443
+0800 2024-07-18 18:40:15 DEBUG [1131983404 0ms] router: sniffed protocol: tls, domain: www.gstatic.com
+0800 2024-07-18 18:40:15 DEBUG [1131983404 0ms] router: match[4] rule_set=[geosite-cn geosite-geolocation-cn] => direct
+0800 2024-07-18 18:40:15 INFO [1131983404 0ms] outbound/direct[direct]: outbound connection to www.gstatic.com:443
+0800 2024-07-18 18:40:15 DEBUG [1131983404 0ms] dns: lookup domain www.gstatic.com
+0800 2024-07-18 18:40:15 DEBUG [1131983404 0ms] dns: match[1] rule_set=geosite-geolocation-!cn => remote
+0800 2024-07-18 18:40:15 INFO outbound/shadowsocks[proxy]: outbound connection to 8.8.8.8:53
+0800 2024-07-18 18:40:15 DEBUG [1131983404 108ms] dns: lookup failed for www.gstatic.com: context canceled
+0800 2024-07-18 18:40:15 DEBUG [1131983404 108ms] inbound/http[http]: connection closed: process connection from 127.0.0.1:63466: context canceled
+0800 2024-07-18 18:40:15 INFO [288332285 0ms] inbound/http[http]: inbound connection from 127.0.0.1:63468
+0800 2024-07-18 18:40:15 INFO [288332285 0ms] inbound/http[http]: inbound connection to www.gstatic.com:443
+0800 2024-07-18 18:40:15 DEBUG [288332285 0ms] router: sniffed protocol: tls, domain: www.gstatic.com
+0800 2024-07-18 18:40:15 DEBUG [288332285 0ms] router: match[4] rule_set=[geosite-cn geosite-geolocation-cn] => direct
+0800 2024-07-18 18:40:15 INFO [288332285 0ms] outbound/direct[direct]: outbound connection to www.gstatic.com:443
+0800 2024-07-18 18:40:15 DEBUG [288332285 0ms] dns: lookup domain www.gstatic.com
+0800 2024-07-18 18:40:15 DEBUG [288332285 0ms] dns: match[1] rule_set=geosite-geolocation-!cn => remote
+0800 2024-07-18 18:40:15 INFO outbound/shadowsocks[proxy]: outbound connection to 8.8.8.8:53
+0800 2024-07-18 18:40:16 DEBUG [288332285 93ms] dns: lookup failed for www.gstatic.com: context canceled
+0800 2024-07-18 18:40:16 DEBUG [288332285 93ms] inbound/http[http]: connection closed: process connection from 127.0.0.1:63468: context canceled
+0800 2024-07-18 18:40:16 INFO [1348730283 0ms] inbound/http[http]: inbound connection from 127.0.0.1:63470
+0800 2024-07-18 18:40:16 INFO [1348730283 0ms] inbound/http[http]: inbound connection to edge.microsoft.com:443
+0800 2024-07-18 18:40:16 DEBUG [1348730283 1ms] router: sniffed protocol: tls, domain: edge.microsoft.com
+0800 2024-07-18 18:40:16 DEBUG [1348730283 1ms] router: match[6] port_range=0:65535 => proxy

额外信息

在使用Xray内核下日志如下【似乎是走的直连】
2024/07/18 18:41:48 [Info] [1292794750] proxy/http: request to Method [CONNECT] Host [www.gstatic.com:443] with URL [//www.gstatic.com:443]
2024/07/18 18:41:48 [Info] [1292794750] app/dispatcher: sniffed domain: www.gstatic.com
2024/07/18 18:41:48 [Info] [1292794750] app/dispatcher: taking detour [direct] for [tcp:www.gstatic.com:443]
2024/07/18 18:41:48 [Info] [1292794750] transport/internet/tcp: dialing TCP to tcp:www.gstatic.com:443
2024/07/18 18:41:48 [Debug] transport/internet: dialing to tcp:www.gstatic.com:443
2024/07/18 18:41:48 127.0.0.1:63499 accepted //www.gstatic.com:443 [http -> direct]
2024/07/18 18:41:48 [Info] [1292794750] proxy/freedom: connection opened to tcp:www.gstatic.com:443, local endpoint 192.168.184.136:63500, remote endpoint 203.208.41.34:443
2024/07/18 18:41:48 [Info] [1292794750] proxy: CopyRawConn readv
2024/07/18 18:41:51 [Info] [999262526] proxy/http: request to Method [HEAD] Host [msedge.b.tlu.dl.delivery.mp.microsoft.com] with URL [http://msedge.b.tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/da421fd3-a679-418c-8790-7cfcec77ad0a?P1=1721885113&P2=404&P3=2&P4=Ac8hAd6CPfPl%2fLiuzkM3HWZg3qW1v1N5iigAe%2bUTi9gtEtRTCKPo%2b3dAnJd5EOuJ8vYWr61I3wDQ1qmeZeokmA%3d%3d]
2024/07/18 18:41:51 [Info] [999262526] app/dispatcher: taking detour [direct] for [tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80]
2024/07/18 18:41:51 [Info] [999262526] transport/internet/tcp: dialing TCP to tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80
2024/07/18 18:41:51 [Debug] transport/internet: dialing to tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80
2024/07/18 18:41:51 127.0.0.1:63494 accepted http://msedge.b.tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/da421fd3-a679-418c-8790-7cfcec77ad0a?P1=1721885113&P2=404&P3=2&P4=Ac8hAd6CPfPl%2fLiuzkM3HWZg3qW1v1N5iigAe%2bUTi9gtEtRTCKPo%2b3dAnJd5EOuJ8vYWr61I3wDQ1qmeZeokmA%3d%3d [http -> direct]
2024/07/18 18:41:51 [Info] [999262526] proxy/freedom: connection opened to tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80, local endpoint 192.168.184.136:63501, remote endpoint 222.220.212.5:80
2024/07/18 18:41:51 [Info] [999262526] proxy: CopyRawConn readv
2024/07/18 18:41:51 [Info] [999262526] proxy/http: request to Method [GET] Host [msedge.b.tlu.dl.delivery.mp.microsoft.com] with URL [http://msedge.b.tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/da421fd3-a679-418c-8790-7cfcec77ad0a?P1=1721885113&P2=404&P3=2&P4=Ac8hAd6CPfPl%2fLiuzkM3HWZg3qW1v1N5iigAe%2bUTi9gtEtRTCKPo%2b3dAnJd5EOuJ8vYWr61I3wDQ1qmeZeokmA%3d%3d]
2024/07/18 18:41:51 [Info] [999262526] app/dispatcher: taking detour [direct] for [tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80]
2024/07/18 18:41:51 [Info] [999262526] transport/internet/tcp: dialing TCP to tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80
2024/07/18 18:41:51 127.0.0.1:63494 accepted http://msedge.b.tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/da421fd3-a679-418c-8790-7cfcec77ad0a?P1=1721885113&P2=404&P3=2&P4=Ac8hAd6CPfPl%2fLiuzkM3HWZg3qW1v1N5iigAe%2bUTi9gtEtRTCKPo%2b3dAnJd5EOuJ8vYWr61I3wDQ1qmeZeokmA%3d%3d [http -> direct]
2024/07/18 18:41:51 [Debug] transport/internet: dialing to tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80
2024/07/18 18:41:51 [Info] [999262526] proxy/freedom: connection opened to tcp:msedge.b.tlu.dl.delivery.mp.microsoft.com:80, local endpoint 192.168.184.136:63502, remote endpoint 222.220.212.5:80
2024/07/18 18:41:51 [Info] [999262526] proxy: CopyRawConn readv

我确认已更新至最新版本

是

我确认已查询历史issues

是

ambiguous-pointer · 2024-07-18T11:12:03Z

ambiguous-pointer
Jul 18, 2024
Author

已经使用检查更新按钮更新了软件版本 sing-box版本和 geofiles

0 replies

ambiguous-pointer · 2024-07-18T11:18:41Z

ambiguous-pointer
Jul 18, 2024
Author

似乎并不存在 #4561 #4561 (comment) 中的插件问题

0 replies

wtfr-dot · 2024-07-22T04:44:18Z

wtfr-dot
Jul 22, 2024

因为singbox里把它列入代理列表里，但是解析出来的ip是国内的，xray这边就直连了，你把gstatic.com在路由配置里把它加入代理里，让两者路由一致即可，这个域名我这里一直是列入代理的，不影响Google登录。

0 replies

ambiguous-pointer · 2024-07-22T08:55:55Z

ambiguous-pointer
Jul 22, 2024
Author

Uploading 全局模式.mp4…

https://github.com/user-attachments/assets/ddd42807-d899-4366-9ce7-f54c25b5ac1a
但是似乎设置了也是不行的。但是只要开全局模式就可以了【路由是否如此设置？？】

4 replies

wtfr-dot Jul 22, 2024

Uploading 全局模式.mp4…

https://github.com/user-attachments/assets/ddd42807-d899-4366-9ce7-f54c25b5ac1a 但是似乎设置了也是不行的。但是只要开全局模式就可以了【路由是否如此设置？？】

只需gstatic.com就行了，要单独建一个规则，作为路由配置的第一个proxy，放在direct的前面，因为匹配是按从上到下顺序，还要注意geosite:category-ads-all这个规则集，它有时会阻止正常的域名，特别是singbox的广告过滤规则误伤比较大

ambiguous-pointer Jul 25, 2024
Author

我在如下添加后是可以在这个规则下进行访问

wtfr-dot Jul 25, 2024

你直接在绕过大陆(whitelist)那个集合里面去加，放在第一个位置，如果你单独创建一个规则集，其它规则不能用了，其实在现有规则集里添加自定义规则是常规操作，因为默认规则本来就满足不了所有需求

alanyagger Sep 17, 2024

非常感谢大佬我找了几个小时没发现问题最后还是在log里看到gstatic走到竟然是直连就是还不太明白为什么更新后这个域名会被解析到国内

rocketraccooo-n · 2024-07-23T09:58:27Z

rocketraccooo-n
Jul 23, 2024

这个问题我碰到过，是xray的dns匹配规则和sing-box不太一样导致的。xray的长这样：

"servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn",
          "geosite:geolocation-cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      "1.1.1.1",
      "8.8.8.8",
      "https://dns.google/dns-query"
    ]

xray先匹配geosite:cn和geosite:geolocation-cn，以及geoip:cn，然后将剩下的全部发往国外，也就是对国内采取的一网打尽的态度。sing-box上来使用的geosite-geolocation-!cn会遗漏相当多的域名，总体不建议使用。

这里再多说两句关于TUN的DNS解析问题。TUN模式底下，很多表面上是规则集解析问题，但事实上是 Chrome/Firefox 的安全DNS导致的。Clash的文档也有提到这个：https://docs.gtk.pw/contents/tun.html 。简而言之，TUN模式为了得到域名以便走不同的规则，需要对自己进行中间人攻击（也就是域名嗅探）来得到域名和IP，开启安全DNS之后所有的域名请求全部看起来都是HTTPS，域名嗅探就不能生效了，DNS请求会全部发到（需要proxy才能到的）国外，导致速度奇慢以及超时。而如果浏览器检测到有系统代理或者VPN，会自动关闭这个功能（至少Firefox是这样），所以系统代理模式就会感觉比TUN快：

@2dust 我认为TUN模式相比代理模式体感上大幅减速的原因其实和这个高度相关，特别是一旦开了安全DNS，Chrome就会将国内网站的DNS解析请求以DoH的形式仍然发往国外。

5 replies

2dust Jul 23, 2024
Maintainer

能否提供改进的建议？比如修改dns或路由规则？

rocketraccooo-n Jul 23, 2024

首先自然是需要建议用户关闭安全DNS否则TUN模式应该永远都不会表现太好，这个没有办法从v2rayN这边干预；对于sing-box的DNS规则，可以使用下面这个作为参考：

"servers": [
      {
        "tag": "remote",
        "address": "8.8.8.8",
        "strategy": "ipv4_only",
        "detour": "proxy"
      },
      {
        "tag": "local",
        "address": "dhcp://auto"
      },
      {
        "tag": "blocked",
        "address": "rcode://refused"
      }
    ],
    "rules": [
      {
        "rule_set": [
          "geosite-cn",
          "geosite-geolocation-cn"
        ],
        "server": "local"
      },
      {
        "rule_set": [
          "geosite-category-ads-all"
        ],
        "server": "blocked",
        "disable_cache": true
      }
    ]

这里有几点，一是dns规则集部分模仿xray的dns规则先将国内部分一网打尽，剩下的全走remote，二是国内地址使用dhcp://auto以利用本地系统的dns缓存进一步加速地址解析（当然也可以继续使用阿里dns）。只是注意dhcp://auto需要本地有正常的网络连接，不然会在启动时出错

Arcticn Aug 3, 2024

关于安全DNS的问题，在非tun打开系统代理的情况下，由于uBlcok一个默认启用的功能会导致发生DNS泄露，一个方便的解决方法是使用浏览器的安全dns，因此我平时一直使用最大保护模式。而这个模式不会在检测到代理时自动关闭，也可以在控制台观察到被proxy的dns请求，但是速度仍然比tun模式快不少，不知道是为什么

rocketraccooo-n Aug 3, 2024

@Arcticn
之前我的回答不够准确，其实复现TUN的情况，只要使用SOCKS代理就可以了。按如下设置手动设置系统SOCKS代理：

或者Win10/11底下也可以用：

然后开启Chrome的安全DNS：

然后打开新的网页，或者按Ctrl+F5强制DNS请求并刷新网页，就能观察到大规模的拖慢和打不开的现象：

然后取消安全DNS，问题马上就消失。
后来我了解了一下HTTP代理的基本原理，才知道域名是HTTP代理协议的一部分，也就是DNS请求是一定会发给proxy进行解析的 - 这也就意味着HTTP代理模式底下安全DNS应该一定会被绕过，所以是不会出现如SOCKS/TUN的情况下需要进行DNS劫持的情况的

Arcticn Aug 4, 2024

原来是这样，明白了，谢谢！

wtfr-dot · 2024-07-23T14:53:26Z

wtfr-dot
Jul 23, 2024

使用代理时都建议浏览器关闭安全dns，特别是有透明代理的路由器里，这是因为开启安全dns会绕过dns劫持，对于v2rayN来说，最好建议将xray的路由策略默认为AsIs，因为路由分流主要在singbox，我在#5287提到过，而且保证singbox和xray的geo文件来源一致即可，最新的singbox已经不兼容xray的geo文件了

0 replies

HaaiSo · 2024-07-25T09:45:54Z

HaaiSo
Jul 25, 2024

同样有这个问题

0 replies

ovo4096 · 2024-07-25T14:34:00Z

ovo4096
Jul 25, 2024

移除路由设置里面直连的 geosite:cn 规则就可以解决这个问题了

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug]: 关于在预设V3-绕过大陆路由规则下Shadowsocks切换至sing-box 内核时 gstatic.com 无法访问导致Google登录出现静态资源无法获取点击登录无反应 #5383

{{title}}

Replies: 8 comments 9 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

[Bug]: 关于在预设V3-绕过大陆路由规则下Shadowsocks切换至sing-box 内核时 gstatic.com 无法访问 导致Google登录出现静态资源无法获取 点击登录无反应 #5383

预期情况

实际情况

复现方法

日志信息

额外信息

我确认已更新至最新版本

我确认已查询历史issues

Replies: 8 comments · 9 replies

ambiguous-pointer Jul 18, 2024 Author

ambiguous-pointer Jul 18, 2024 Author

ambiguous-pointer Jul 22, 2024 Author

ambiguous-pointer Jul 25, 2024 Author

2dust Jul 23, 2024 Maintainer

[Bug]: 关于在预设V3-绕过大陆路由规则下Shadowsocks切换至sing-box 内核时 gstatic.com 无法访问导致Google登录出现静态资源无法获取点击登录无反应 #5383

Replies: 8 comments 9 replies

ambiguous-pointer
Jul 18, 2024
Author

ambiguous-pointer
Jul 18, 2024
Author

ambiguous-pointer
Jul 22, 2024
Author

ambiguous-pointer Jul 25, 2024
Author

2dust Jul 23, 2024
Maintainer