不支持谷歌服务的手机确认登陆？

[eret9616]

在chrome上登陆账号的时候，我试了规则模式和全局模式 ，都不弹出谷歌服务的确认登陆界面，打开以前的v2rayng就可以，请问需要什么特别设置吗

[Liquidwork]

我也在研究这个问题，怀疑是google fcm消息机mtalk.google.com 可以直连，但是走了代理就不行了。不一定对，我也在查

[Liquidwork]

我用了sing-box就可以连上fcm了，然后登陆推送也可以收到了

[mengdegege]

废劲各种折腾了一圈，反就正常情况下帐号管理页面也会莫名出现无连接之类的情况，可能刷新一下又会好，有时得把play服务关掉，重新启用才行，但又不是完全不可用。
看到大家也有这个问题，又折腾了一圈，反正我这边感觉把网络设置那里的IPv6开关关掉之后，就可以即时弹出提示了，不知道是不是特例。

[eret9616]

网络里的 允许ipv6 设置吗 我现在就是关闭的

[mengdegege]

感觉不太合理，后来又试了一下，可能Pv6开关可能是巧合，后来又做了一些尝试，在保留配置是fake-ip,给google域名集做了个解析策略以防UDP请求要求解析，这样的状态下，试了很久。但总感觉跟这些没多大关系。
总之是能弹提示的，但是比较随缘，有时候很及时，有时候开着账号管理页面等着也没反应。
但好像有个规律，只开起移动数据的时候成功率比较高，而且很快，甚至关闭屏幕一会，一点发送还能收到。同时开启WiFi和移动数据的时候几乎不会收到。关闭移动数据保留WiFi后可能短暂时间能行，但过一会又不行了。可是看来看去，也没看出什么来，搞不明白。。我宽带和手机卡都是联通的。这玩意试多了会报风险，没试出个所以然来🙈🙈

[mengdegege]

我后来观察到，app那里虽然关闭了ipv6，但是好像还是有默认采用ipv6的连接。
然后从配置文件里，把全局的和dns的IPv6 都关了，测试正常。 但关掉之后，本地的ipv6就不行了，不死心又再尝试了一下，开启ipv6的情况下， 把代理集的override.ipversion 改为 ipv4，ipv4_prefer 发现都能正常。
但这时还没法定位问题，因为我还给google@cn，和google域名集的解析分流了。 然后尝试去掉了google@cn试图解析出国内IP的配置，去掉代理集的ipversion:ipv4 配置， 只保留 nameserver-policy: ["rule-set:google": "tls://dns.google#google"] ，再次测试发现也正常。
到这里推测下原因，也许确实是你前面提到的那个看法，可能因为这个服务涉及较多udp连接，必须先取得IP后转发连接，如果没有解析策略的情况下，就会被默认的nameserver 解析，即使走的是代理，甚至于可能IP也是正常可用的，但也有可能由于获得的是不对应区域的IP导致经代理也无法连接。而这种出错的机率，使用ipv4比使用ipv6时要小（猜测）
所以这里有两种可以尝试的办法，一种是把google@cn尝试走一遍国内，没匹配到再走代理，之所以用sub-rule，是因为这样不需要把兜底的CN_ip直连提到前面来，造成很多不必要的解析：

nameserver-policy: 
 "rule-set:google@cn": "https://dns.google/dns-query#代理&ecs=114.114.114.114/32&ecs-override=true"
 'rule-set:google,youtube': 'tls://dns.google#代理'
rules:
 - SUB-RULE,(RULE-SET,google@cn),cn
 - RULE-SET,google,代理
sub-rules:
  cn:
    - RULE-SET,cn_ip,DIRECT

但这样可能存在一定的风险，就是第一条解析出来了google@cn的IP，但是没匹配到 cn_ip规则集， 导致还是走代理，可能会失败。但是这样确实能让一些国内可用的接口走直连。

另一种方式就是只保留 rule-set:google 的大集合，统一走代理解析，走代理连接。

nameserver-policy: 
 'rule-set:google,youtube': 'tls://dns.google#代理'
rules:
 - RULE-SET,google,代理

以上没有严格按照日志去分析，只是是我的环境测试下来的一种猜测，可以尝试一下，不保证能行，但我这目前看起来是正常的，暂时没时间折腾了。
代理集的 ipv4_prefer，可以保留.
另外，如果测试的时候，建议一收到提示，就点下去，但是登录端不要选择 “此设备不再询问”，之后可以退出再重来。 如果不确认，多试几次就没法发提醒了。

[Liquidwork]

我现在用sing-box了，play store免费下载，支持fcm

[mengdegege]

> 把代理集的override.ipversion 改为 ipv4，ipv4_prefer 发现都能正常。

搞错了，出站配置里面的ip版本，不是代理流量的目标IP，是指连接至代理服务器的IP。

[mengdegege]

这个问题通过FCM诊断界面，发现了一点东西。CMFA客户端的网络设置里面，有一个选项叫“允许其他应用绕过”，之前一直以为这个选项是跟下面的分应用代理是同一个意思或者说是联合使用的，结果发现不是。这是一个独立的选项，它的作用是启用了之后，会给这个VPN连接一个“允许绕过”的属性，在FCM诊断里面显示为 bypassable 。当VPN连接有这个属性的时候，应用是可以主动绕过VPN的，除FCM之外，在一些其他的场景也观察到了这种主动绕过的行为，比如有某个需要侦听内网IP的应用，启用允许绕过后，无论是否有开启绕过局域网的选项，它都能自动绕过去，但当关闭允许绕过之后，就一定要启用绕过局域网的规则，不然就会连不进来了。
目前在持续尝试了各种调试都无法恢复FCM连接的情况下，关闭这个选项，重新连接VPN后，让FCM立即恢复了。日志里面也没有再显示 VPN bypassed=true，猜测是FCM会在某些情况下（比如网络不稳定？导致VPN网络无法连接服务时？），服务会自动启用绕过VPN，而且一旦它进入这个状态之后，不知道怎么才能主动触发它恢复回来，结果就可能会一直处于断联状态。