XIU2

国内这些安卓系统上传安装应用的包名早就被实锤了呀，你可以装个 XPosed 模块来屏蔽：
MinaMichita/AntiAntiDefraud

@coolmint 收短信、接电话 这种被动不保活，只有 发短信、打电话 这种主动行为才会保活。

上述结论，是我当初不断尝试，并通过系统自带的 资源监视器、Wireshark 抓包来查看 浏览器、Warp 、Curl 进程访问了哪些 IP 地址，也是在这里面看到 Warp 在不断尝试 1.1.1.1 1.0.0.1 来 DNS 解析域名，如果一直失败就会换成 IPv6 的再去尝试），有兴趣你也可以自己看看，不过我这个研究是好几个月前的了，或许已经过时。

另外，Warp 的 Warp+ 模式其实就是让所有流量都走远程服务器，包括 DNS 解析流量也是在远程服务器上进行的，所以才不会出现 Warp 的 Proxy 模式的该问题。

另外，wgcf 等工具生成的 WireGuard 配置文件也可以用于其他设备，比如 Android 直接装 WireGuard 官方客户端，然后导入这个配置文件就能直接用 Warp 节点了。

不用费劲了，该问题前段时间我试用 Warp 时也遇到了，顺便研究了下，结论如下：

该问题在于 Warp 的 Proxy 模式（ SOCKS5 代理），会接受 DNS 解析请求，但并不是远程 DNS 解析，而是在本地解析，当然用的不是你本地的 DNS ，而是 Cloudflare 的 1.1.1.1 DoH 。

而问题就出在这里了，Cloudflare 的 DNS 在国内很多地区都是被干扰的，因此导致 Warp 在解析域名 DNS 环节卡住，Warp 会一直重试 IPv4 DoH ，重试次数多了，就会尝试改为 IPv6 DoH （而因为 IPv6 可能干扰没那么普遍、严重，因此一些人可能会遇到浏览器一直加载加载，过段时间就突然加载出来的情况，实际上就是 IPv6 DoH 解析成功了）。


这时候你会想到：“那为什么我用 curl 可以正常访问呢？”

这其实是因为 Curl 的 SOCKS5 代理方式分为两种：

curl --socks5 127.0.0.1:40000 xxxxx
curl --socks5-hostname 127.0.0.1:40000 xxxxx

前者是先本地 DNS 解析域名获得 IP 后，再去通过 SOCKS5 代理访问该 IP （也就是该网站）。
后者是全程走 SOCKS5 代理，即把 DNS 解析环节交给 SOCKS5 代理处理，然后访问网站。

因此你使用前者来走 Warp 代理时，其实是本地 DNS 解析域名后，再通过代理访问网站，所以可以正常访问。
你使用后者时，则是 Warp 来 DNS 解析域名，然后超时并不断循环尝试。。。


总之，对于 Warp 官方客户端的该问题，我没什么好的解决方法（总不能专门整个代理让 Warp 的 DNS 走吧，这岂不是多此一举？）。
但是你可以用 wgcf 等工具生成一个 WireGuard 配置文件，然后自选一个 Warp 的节点 IP+端口 填进去，再去装个 WireProxy （一个把 WireGuard 转为 SOCKS5 代理的命令行工具）来使用该配置文件（配置文件里有个 dns 项，这个是远程 DNS ，即指定 Warp 服务器上用这个 DNS 去解析域名），这样的话就完美解决该问题了。

还有其他问题你也可以问我。

这也是我习惯用 百分浏览器（ Cent Browser ）的原因之一吧，作者直接在设置里加了个选项，可控制书签打开方式为：当前标签、新建前台标签、新建后台标签。你想要的就是其中的 "新建前台标签"。

Cent Browser 唯一的缺点就是更新较慢（因为就一个人业余制作），现在最新内核才 102.0.5005.167 。

不用热门 IDC 会省心很多，毕竟那些 IP AS 都是被重点关注的。