cloudflare warp 客户端的 proxy 模式无法上网

2023-06-22 10:30:20 +08:00
 exiaduck

我在不同的系统上都试过 warp 的 proxy 模式,都是无法上网。 本地 win/mac/linux , 国外 vps 上都试过,proxy 模式都不通外网。

以 macos 为例,warp 全局模式上网是正常,但是转为 proxy 模式,连接 cf 网络能成功,socks 端口在本机 40000 ,使用浏览器插件 SwitchyOmega 走 socks5 连接这个端口,无法上网; warp+ 还是团队账号都一样的情况。

在终端输入 system_profiler SPNetworkDataType | grep "SOCKS Proxy", 显示: SOCKS Proxy Enabled: Yes SOCKS Proxy Port: 40000 SOCKS Proxy Server: 127.0.0.1 SOCKS Proxy Enabled: No SOCKS Proxy Port: 1081 SOCKS Proxy Server: 127.0.0.1 SOCKS Proxy Enabled: No SOCKS Proxy Port: 1081 SOCKS Proxy Server: 127.0.0.1

根据这个输出,说明 warp 的 socks5 服务是正常开启了的; 然后终端 curl --proxy socks5://127.0.0.1:40000 https://www.cloudflare.com/cdn-cgi/trace/, 获得输出信息 warp=plus ,说明 warp 是开启了且连接到了 cf 网络的。

再尝试 curl --proxy socks5://127.0.0.1:40000 其他网站,例如 google.com bing.com 返回了一些奇怪的东西,但看起来不是正常主页的 html ; ifconfig.me ip.sb 这些会返回 ip 地址;

翻了很久 google 都没找到类似的情况,cf 官方也是说 proxy 模式用 socks 工具连接就 ok ,没提及有什么其他的设置。 大家用 proxy mode 都正常吗?

9752 次点击
所在节点    Cloudflare
32 条回复
hymzhek
2023-06-22 10:42:27 +08:00
看看 curl -v --proxy socks5://127.0.0.1:40000 https://1.1.1.1 呢
hymzhek
2023-06-22 10:43:05 +08:00
因为它不给你解析 dns
exiaduck
2023-06-22 11:01:30 +08:00
@hymzhek curl 1.1.1.1 倒是看起来是个正常的访问。

curl -v --proxy socks5://127.0.0.1:40000 https://1.1.1.1

* Trying 127.0.0.1:40000...
* SOCKS5 connect to IPv4 1.1.1.1:443 (locally resolved)
* SOCKS5 request granted.
* Connected to (nil) (127.0.0.1) port 40000 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted h2
。。。。

请教一下,要怎么解决这个 dns 的问题?
Andim
2023-06-22 11:10:28 +08:00
windows 上可以, 不过我是本地 DNS


hymzhek
2023-06-22 11:10:32 +08:00
因为它在设置的时候 提示了 仅加密发送到本地代理的流量。不处理 DNS 流量。
iamwho
2023-06-22 11:26:43 +08:00
用 firefox ,开启 DOH 就可以了,代理设置关闭代理 DNS via socks5

但是 chrome 设置 DOH 之后用 SwitchyOmega 也不行
exiaduck
2023-06-22 13:42:09 +08:00
@iamwho 感谢提供信息!
刚刚测试了,确实 firefox 浏览器本身设置 doh + foxyproxy 插件禁止 dns 经过 socks5 ,就能通网,就是卡卡的,性能不如直接 mode=warp 模式;但是,这个做法貌似不能跨设备分享,比如在一台 win 上 mode=proxy ,即使用工具将 40000 暴露到局域网 2333 ,其他用 firefox 去访问 2333 依然不通。

看来还是原生客户端 warp 模式体验最好,客户端应该在 wg 协议基础上还有别的优化机制。
exiaduck
2023-06-22 13:43:03 +08:00
@hymzhek 感谢提供信息! DNS 还是不太会处理,一脸懵逼。
XIU2
2023-06-22 13:47:54 +08:00
不用费劲了,该问题前段时间我试用 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 去解析域名),这样的话就完美解决该问题了。

还有其他问题你也可以问我。
XIU2
2023-06-22 13:55:53 +08:00
上述结论,是我当初不断尝试,并通过系统自带的 资源监视器、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 节点了。
exiaduck
2023-06-22 14:19:00 +08:00
@XIU2 大神解析非常清晰,廓然开朗了,十分感谢!🙏

wireproxy 我有用在服务器上,只是对原理不太明白;虽然现在 warp+等于无限免费送,24*7 挂着也不心疼,但这样被滥用会不会很快又回到解放前,昨晚想着 warp 全局有时不太方便,就想着进一步研究一下。

wgcf 提取配置然后用 wireguard 的方式也很棒,但相比 warp 客户端,对端 ip 还是偶尔要手动换,虽然 warp 也不见得次次都分到合适的对端,但他点点开关就 ok 的麻瓜方式也不错。

刚刚还看了一眼团队账户相关的,cloudflare tunnel 这个组网好像有点厉害,设置合适直接将 wg 或者 tailscale 组网能力都集成起来了,还有群控、分流等等也很厉害。
IDAEngine
2023-06-22 15:09:11 +08:00
@exiaduck 有境外 VPS ,直接转发 warp socks 代理就行了
Dxer
2023-06-22 19:02:09 +08:00
wireguard 试试,PC 和移动端都是用 wireguard
exiaduck
2023-06-22 20:51:09 +08:00
@IDAEngine 海外 vps 套 warp 主要只是用来解锁一些限制网站,能连到海外服务器了本身就已经解决魔法问题了。。。

关注的重点是本地 warp 客户端的设置,现在随便白嫖 warp+流量,设置 warp 比管理自建节点简单,作为备用和分流用是很爽的;本地 mode=warp 在应用层跟其他常用代理工具会冲突的,所以同一台机器上套娃分流好像不太好搞(菜+懒);两台机器就比较容易,一台 mode=warp 全局,分一个端口出来给其他机器的代理工具接就很好分流。
exiaduck
2023-06-22 20:53:10 +08:00
@Dxer 提取配置接 wg 没毛病的,我关注的重点是本地分流玩法。
IDAEngine
2023-06-22 21:18:16 +08:00
@exiaduck 国内直连 wrap 并不稳定,速度也比较慢,还是中转一下比较舒服
exiaduck
2023-06-22 21:41:39 +08:00
@IDAEngine #16 南方的电信用户裸连 warp 体验非常好! 现在 warp+的体验分流 80%需求问题不大,如果自己管理 chatgpt 这类应用的连接的话还是需要有海外节点的,两者互补。
IDAEngine
2023-06-22 23:54:32 +08:00
@exiaduck 我这里 裸连容易被 Reset ,我都是转发
exiaduck
2023-06-28 18:17:03 +08:00
跟进一下这个 case:

国内网络下,本地使用 warp 客户端的 proxy 模式的简易优雅办法是:
1. 物理网卡的 DNS 服务指向本机 ip:127.0.0.1
2. Firefox 使用 foxyproxy 插件,创建 socks5 出口,指向 warp 的端口,默认 127.0.0.1:40000 ;重点:“通过 socks5 代理发送 dns 请求”的选项关闭。chrome 系的 switchomega 没有这个功能。
3. firefox 隐私与安全 - 安全 dns - 选择增强保护 - 选 cloudflare 或者其他 doh/dot
3. v2ray 或者 sing-box 带有 dns 处理模块:sing-box 为例,创建一个监听本机 53 端口的入站点,开启流量嗅探,协议选 direct ,创建一个 sock5 指向 warp 的端口为出站点,随便设置一个 tag ,开启 udp_over_tcp
4. singbox 路由添加匹配 dns 协议,由 dns 规则处理 dns 请求。
"route": {
"rules": [
{
"protocol": "dns",
"outbound": "dns-out"
}
]
}

5. 设置 singbox 的 dns 处理模块,参考以下:
"dns": {
"disable_cache": true,
"rules": [
{
"geosite": "cn",
"server": "local"
}
],
"servers": [
{
"tag": "cf",
"address": "tls://1.1.1.1",
"detour": "warp" #warp 出站点的 tag
},
{
"tag": "local",
"address": "1.12.12.12",
"address_resolver":"dns-local",
"detour": "direct"
}
]
}


大致的原理就是,在本地先将请求解析成 ip 再传给 warp ,warp 前端就认为不需要 dns 解析了,然后就通过后端隧道发出去了。浏览器的话,第 2 步就是不让 warp 前端做 dns 解析的关键,暂时只有 ff 的插件能比较简单的解决。

v2ray 或者 singbox 虽然能处理 dns ,但是一般来说代理工具内部处理 dns 只是做路由匹配,用来决定浏览器的请求包应该发去哪个节点,而不会将 https 请求包的地址从域名形式替换成 ip 形式,所以无法单纯用一层代理套娃来解决。ff 插件拆分出 dns 请求和 https 请求,浏览器就会自己先发出 dns 请求,用代理工具捕获解析好返回 ip 给浏览器,浏览器知道目的地 ip 了,将 https 的域名替换成 ip ,最后再发给 warp 。

其他的办法是,代理软件的透明代理模式或者 tun 模式可以捕获 warp 前端发送的 dns 请求,这样浏览器就无需插件了,但同样要设置好代理工具的 dns 模块规则; 透明代理要改 iptables ,如无必要最好还是选择 tun 模式,但我不确定 tun 模式会不会有回环的问题。

总结:
1. warp 的 proxy 模式性能很拉胯,大概最多能看个 1080p ;
2. 原生 wg 可以用 sing-box 做完美分流,或者用 sing-box 实现的轻量级 wg 也可以有接近原生 wg 的性能;
3. dns 分流做好了才能安全冲浪,大家要重视哦,借助 cf 实现起来很简单。peace 。
eoo
2023-07-12 10:48:22 +08:00
@XIU2 大佬 可以给个联系方式吗? 我用的是 v2rayaA

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/950811

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX