请教：如何使用 wireguard 作为链式代理的出口节点

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 634 天前的主题，其中的信息可能已经有所发展或是发生改变。

前一段时间看到 Project X 的通过 Cloudflare Warp 增强代理安全性一文，今天没有别的事，感觉可以浪费一点生命，但是最终还是失败了。遇到了一些疑惑，想请教一下各位大佬。

我想要配置链式代理的最大原因是担心机场的安全性。Project X 的原文也提到了这一点：

保护用户私密性的一个方法，就是在客户端使用链式代理。Warp 使用的 WireGuard 轻量级 VPN 协议会在代理层内增加一层加密。对于机场而言，用户所有流量的目标都是 Warp ，从而最大程度保护自己的隐私。

问题 1: 原文的说明中提到“在服务端分流回国流量至 warp”。请问这一步是必须的吗？

如果是必须的，即要求能够控制服务端的出站配置，那完全无助于提升安全性：因为显然普通用户不可能控制机场的配置。而如果需要用户再利用自己的 VPS 创建一个节点，控制这个节点的配置来将流量导向 warp ，那也是无意义的：因为流量流向用户自己的 VPS 以后，已经达成了防止泄露流量信息给机场这一目的
如果非必须，那才会有问题 2：

问题 2: 要如何配置，才能完成使用 wireguard 作为链式代理的出口节点这一要求呢？

我已经（略为艰难地）获得了一个能够在 Clash Verge (内核选用 Clash meta) 中成功连接的 wireguard 类型的代理，同时还拥有机场提供的可用节点，并创建了如下结构的 clash 配置文件

proxies:
  - {name: 机场节点 1, server: server.xyz, port: 21584, type: vmess, uuid: xxx, alterId: 1, cipher: auto, tls: true, skip-cert-verify: false}
  # (此处省略若干机场节点)
  - {name: warp-github, type: wireguard, server: 162.159.193.10, port: 2408, ip: 172.16.0.2, ipv6: ipv6-addr, public-key: bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=, private-key: xxx-private-key, mtu: 1280, udp: true, reserved: [219,212,139] }
proxy-groups:
  - name: 🔰 选择节点
    type: select
    proxies:
      - 机场节点 1
      - warp-github
      - relay
      - DIRECT
  - name: relay
    type: relay
    proxies:
      - 机场节点 1
      - warp-github
rules:
 - MATCH,🔰 选择节点

在使用这个配置时，如果我单独选择“机场节点 1”或者“warp-github”，代理都能正常工作。但是当为选择“relay”时，代理就不工作了。relay规则的配置我是参考的文档，配置并不复杂，不理解为什么它不能工作。以下是我在写这个主题的时候暂时想到的一些方向和疑问：

链式代理对代理链中的节点协议是否有要求？
clash meta 支持链式代理，也支持 wireguard ，但也许它不支持将 wireguard 作为链式代理使用？

问题 3: 有没有已经验证可行性的 wireguard 链式代理实践工具链或者博文推荐？

恳请各位大佬不吝赐教

第 1 条附言 · 2023-04-03 21:53:35 +08:00

感谢各位的解答。昨天到后面睡觉了没有继续，今天打灰回来继续尝试。简单总结一下，也许对有类似需要的同学有帮助：

1. 按照我原本的目标：使用wireguard作为链式代理的出口节点，可以参考 popzuk 大佬提供的两个文档：

https://lancellc.gitbook.io/clash/clash-config-file/proxies/config-wireguard https://lancellc.gitbook.io/clash/clash-config-file/tunnels

我在之前的基础上，成功按照这两个文档实现了我的需求。虽然由于clash不支持在链式代理中使用wireguard，但是使用tunnel也实现了我期望的将机场的出站流量导向warp的需求。缺点是延迟很高，我这边显示大约900ms。

2. 受到评论的启发，我准备后面再试试将WARP官方客户端配置为代理模式，然后通过分流规则让一些常规的流量（比如YouTube视频）走机场，DNS请求和其他站点走WARP。

对我个人来说，YouTube这类网站的SNI记录暴露给机场也是OK的。

3. 准备后续看看廉价VPS，走 misaka00001 大佬提到的建轻量协议走relay的方案

wireguard

节点

代理

warp

37 条回复 • 2024-01-11 15:06:08 +08:00

popzuk

2023-04-02 20:25:43 +08:00 via iPhone

简洁地说，clash meta 虽然支持 relay udp ，但 relay 不支持 wireguard ，需要使用 clash tunnel 功能转发；另外 HK 、TW 、US 需要配置 client ID 连接。

此外 clash 的 wireguard 不支持远程 dns 解析，也就是 fakeip 对 wireguard 无效，需要再配 fallback dns 或者用 nameserver policy 分流 dns 走代理，不然 dns 污染就没有办法访问了。

然而机场普遍对 udp 支持不佳，建议买一个廉价 vps 套 warp ，用 vmess 连接就好。

zbinlin

2023-04-02 21:38:24 +08:00

你这是想 proxy over wireguard(warp)，还是 wireguard(warp) over proxy.
如果是 proxy over wiregaurd(warp)，应该是的链接中的那种配置，那这样还有必要用 proxy 吗？
如果是 wireguard(warp) over proxy ，这个需要 proxy 支持 wireguard 才行。

lightcreater

2023-04-02 22:15:59 +08:00

你用 xray-core ，写配置文件试试
具体说就是写多个 outbound ，然后第一个 outbound 是机场节点，第二个 outbound 是 wireguard 。（ ProxySettingsObject 节，tag 要对应好）

Nile20

2023-04-02 22:21:52 +08:00

@popzuk 感谢您的解答。我搜索了您回答中的一些关键词，还是有些疑惑没有搞清楚，再请教一下：
1. 能否进一步描述一下如何使用 clash tunnel 转发呢？我有用过 clash 的 TUN 模式，知道它会创建一个网卡来路由流量，但是不明白如何把 clash 的 TUN 模式和 wireguard 一起结合使用
2. 您提到的“需要配置 client ID”是指 wireguard 连接的时候是吗？但是我在 WireGuard 官方 PC 客户端、clash meta 中都没有找到配置此项的位置
(wireguard 不支持远程 DNS 解析这一项我应该理解了)
3. VPS 套 warp 的方案的话还需要机场吗？我之前一直是自建，但是自建的经常被封锁而不得不换服务器 /换 IP ，后来就转向机场了

Nile20

2023-04-02 22:25:54 +08:00

@zbinlin 我对 over 的理解可能不是很到位。总的来说，我期望的流量路径是这样
去：本机→机场→WARP→被墙站点
回：被墙站点→WARP→机场→本机
我希望同时实现机场有较多节点可选以便过墙以及 WARP 隐藏目的站点两个需求

czwstc

2023-04-02 22:26:39 +08:00

对于 Surge ，目前无论是 wireguard 做 relay 的目的地还是 relay 的原始地都是没有问题的

popzuk

2023-04-02 22:40:54 +08:00 via iPhone

@Nile20 1.tunnel 是个功能，不是 tun ，见 wiki
2.client ID 就是 reserved ，你已经配置了。
3.因为 vmess 是 tcp （ udp over tcp ），所以你可以机场节点 relay 自建 vmess （廉价的 vps 套 warp ）。机场直连 warp 好处是不需要自建，但是 wireguard 是 udp ，机场的 udp 有时候会炸。
相比于 clash meta ，iOS/macOS 的 surge 和 stash 对 wireguard 代理链支持比较完善有明确示例。

popzuk

2023-04-02 22:45:37 +08:00 via iPhone

https://lancellc.gitbook.io/clash/clash-config-file/proxies/config-wireguard
https://lancellc.gitbook.io/clash/clash-config-file/tunnels
@Nile20

popzuk

2023-04-02 22:57:12 +08:00 via iPhone

@Nile20 机场 relay 自建 vmess ，vps 再套 warp 确实意义不是特别大了。有点意义的，比如想要更进一步的隐私，单 IPv4 套 warp 实现双栈…

taresky

2023-04-02 23:08:22 +08:00 via iPhone

有在用，surge 可以

https://twitter.com/taresky/status/1630812393768128512?s=20

zbinlin

2023-04-02 23:18:02 +08:00

@Nile20 你这个期望就是我说的第一种情况，这个需要机场支持才可以。如果你把机场换成 VPS 才话，这就很容易实现了。

christin

2023-04-02 23:54:32 +08:00 via iPhone

这不是巧了么，昨晚刚搞好，surge 上。

https://github.com/getsomecat/GetSomeCats/blob/Surge/Zero%20Trust%20%E4%BB%8E%E5%85%A5%E9%97%A8%E5%88%B0%E6%94%BE%E5%BC%83.md

7RTDKSAK

2023-04-03 00:12:50 +08:00

自用了很久地方案:

1.买机场,可以同时买几家

2.翻墙客户端随便选择,反正连通机场节点后,在本地暴露出一个 SOCKS5 代理

3.自己买 VPS

4.BROOK OVER CHISEL OVER SOCKS5

缺点:性能损耗很大,毕竟多加密了俩次

优点:在机场看来,你有且只有一个访问目标,也就是你的 VPS IP,而且如果是双栈 VPS,你本地设备还能获得访问 IPV6 的能力

7RTDKSAK

2023-04-03 00:16:17 +08:00

哦,还有一个好处,可以固定出口 IP,这对于 PAYPAL 之类服务有益

misaka00001

2023-04-03 00:39:16 +08:00

1. wireguard 运行在本地,目标是链接到 cloudflare 的 warp
本地 xray 配置如下,利用 xray 的 dokodemo-door 协议将 162.159.192.1:2408 即 engage.cloudflareclient.com:2408 映射到 127.0.0.1:2408
```json
{
"log": {
"loglevel": "debug"
},
"inbounds": [
{
"listen": "127.0.0.1",
"port": 2408,
"protocol": "dokodemo-door",
"settings": {
"address": "162.159.192.1",
"port": 2408,
"network": "udp"
},
"tag": "warp"
}
],
"outbounds": [
{
"protocol": "socks",
"settings": {
"servers": [
{
"address": "127.0.0.1",
"port": 7890
}
]
},
"streamSettings": {
"network": "tcp"
},
"tag": "clash"
}
],
"routing": {
"rules": [
{
"type": "field",
"inboundTag": ["warp"],
"outboundTag": "clash"
}
]
}
}
```

本地 wireguard 配置如下,用 https://github.com/ViRb3/wgcf 生成配置

```
[Interface]
PrivateKey = xx
Address = 172.16.0.2/32, 2606:4700:110:8adb:2a:bdd6:4df:282e/128
MTU = 1280

[Peer]
PublicKey = xx
AllowedIPs = 173.245.48.0/20, 103.21.244.0/22, 103.22.200.0/22, 103.31.4.0/22, 141.101.64.0/18, 108.162.192.0/18, 190.93.240.0/20, 188.114.96.0/20, 197.234.240.0/22, 198.41.128.0/17, 162.158.0.0/15, 104.16.0.0/13, 104.24.0.0/14, 172.64.0.0/13, 131.0.72.0/22, 2400:cb00::/32, 2606:4700::/32, 2803:f800::/32, 2405:b500::/32, 2405:8100::/32, 2a06:98c0::/29, 2c0f:f248::/32
Endpoint = 127.0.0.1:2408
```

本地 clash 添加一个名为 UDP 的代理策略组,组中的代理需要支持 UDP 转发,在路由规则中增加下面这条规则
```
- DST-PORT,2408,UDP
```
依次运行 clash,xray,wireguard 即可

icaolei

2023-04-03 00:41:28 +08:00

说实话，用了 relay 后发现，延迟确实大，非常影响使用体验，还是自建垃圾节点套个优质 CDN 好些。

misaka00001

2023-04-03 00:43:12 +08:00

2. wireguard 运行在远程服务器上
如果服务器的 IP 没有被 CF 屏蔽,那么直接 kizzx2/wireguard-socks-proxy 生成一个本地 socks5 端口
docker-compose.yml 如下

```
version: '3'
services:
proton-jp-wg:
image: kizzx2/wireguard-socks-proxy
container_name: proton-jp-wg
volumes:
- .:/etc/wireguard/:ro
ports:
- "1080:1080"
cap_add:
- NET_ADMIN
```

如果服务器的 IP 被 CF 屏蔽,那么只能通过 CF 的官方客户端进行链接,将客户端设置成代理模式,默认监听在 40000 端口

服务器上启动一个 xray,将流入的流量转发的上述的端口即可

misaka00001

2023-04-03 00:49:40 +08:00

@icaolei clash 的 relay 后的节点可以用轻量一点的协议比如 ss-aes-128-gcm 这种,不需要继续用 vmess+tls+ws+cdn 这种高消耗的协议

docx

2023-04-03 10:22:25 +08:00 via iPhone

低延迟的节点可以尝试链式代理，延迟太高了叠加起来会很感人的

kaddusabagei38

2023-04-03 14:19:22 +08:00

https://github.com/pufferffish/wireproxy 性能可能不行

wwqgtxx

2023-04-10 09:23:27 +08:00

clash.meta 最新的 alpha 版本已为 wireguard 增加 dialer-proxy 设置，可直接设置设置链式代理（不需要使用 relay ，relay 目前仍然不支持 wireguard ），写法即在 wireguard 的配置中增加`dialer-proxy: "其他节点名"`
https://github.com/MetaCubeX/Clash.Meta/commit/87b9e3d977c4ae3dc8368e3a81908fd995ca5ba4
@popzuk

GrayXu

2023-04-28 20:22:49 +08:00

试着参照 op 的配置可以用 wireguard 来连接。但不知道为什么 clash 没办法直接连接本地代理模式下的 warp🤔。但其他应用是可以正常连这个 socks 入口的
```
- {name: "socks", type: socks5, server: "127.0.0.1", port: 40000}
```

shwomen1234fs

2023-04-30 09:04:28 +08:00

@wwqgtxx 昨天最新的 meta 内核 1.4.4 ，已经支持了，nice
proxy-provider can set dialer-proxy too it will apply dialer-proxy to all proxy in this provider by @wwqgtxx

shwomen1234fs

2023-04-30 09:04:43 +08:00

https://github.com/MetaCubeX/Clash.Meta/releases/tag/v1.14.4

20210610204811

2023-05-30 20:24:50 +08:00

你好，我最近也在折腾这件事情，主要就是为了干掉频繁的 Google 验证码跟 ChatGPT 限制，我期望的流量路径跟你的一样。

我现在要解决的是 PC 平台上的问题，使用了 WARP 的 WireGuard ，用的工具是 Clash For Windows ，由于不支持 WireGuard Relay ，所以采用的方案是 tunnel ，现在单纯使用 WirdGuard 是可以的，但是转发不行，看到你上面提到 [使用 tunnel 也实现了我期望的将机场的出站流量导向 warp 的需求] ，我想请求下你是如何配置的，可以把密钥啥的去掉发出来供我参考一下吗？多谢。

Nile20

2023-05-30 20:57:12 +08:00

@20210610204811 你可以先参考一下这两个文档，里面有例子，我当时是参考它配置的。看能不能解决
https://lancellc.gitbook.io/clash/clash-config-file/proxies/config-wireguard
https://lancellc.gitbook.io/clash/clash-config-file/tunnels
我现在在外面出差，带的办公电脑，没有 clash 配置。要是没解决的话我回去以后找一下配置

我当时虽然用 tunnel 走通了，但是延迟感人，使用还是很不便，最后还是没有用 tunnel ，改用的廉价 VPS 自建一个代理。你的两个痛点，Google 验证码的问题可以考虑换个机场； ChatGPT 的问题，如果不介意可能的风险的话，可以看看这个项目
https://github.com/pengzhile/pandora
（这个项目虽然是开源的，但是它的核心是所有请求要走作者的后端站点，这部分是没有开源的）

20210610204811

2023-05-30 22:03:00 +08:00

@Nile20 #26 感谢回复，你给的这两个文档我都看过了，基本上能 Google 到的内容都找过了，GitHub 仓库也都搜过了，我参照上面提到的文档上的示例进行了配置，但是最终的 IP 还是过不了 OpenAI 的验证，明确提示不支持的国家，但我实际上配置的跳板是日本，并且 SpeedTest 的信息也不对，所以跳板这块是肯定存在问题，你如果有空了的话，还是麻烦帮我找一下具体配置我参考下吧。

Nile20

2023-06-02 20:26:36 +08:00

@20210610204811 我回来看了一下配置，看起来我之前以为 tunnel 生效了是错觉：配置了 tunnel 之后，落地 IP 显示 cloudflare ，是因为我仍然是直接连接到 warp 服务，并没有通过机场节点（通过 wireshark 看到我仍然是直接连接的 warp 的 IP ）。并且可能最近连接被劣化，连 warp 就要 1100ms 。

20210610204811

2023-06-04 12:47:44 +08:00

@Nile20 #28 是的，后面我也在想，如果你也是按照教程实现的，那应该跟我是同样的结果，没说错的话，你现在去看日志应该会提示 invalid context 啥的，这个转发实际上并没有生效，教程上转发的不是本地地址，那既然没有转发就更不用说会走代理了。

看来通过 Replay 来洗 IP 是没啥希望了，我在 Surge 上使用虽然可以跳板，但是网速太慢了，这个方案估计是不太行了。

YGHMXFAL

2023-06-18 23:23:41 +08:00

更新:

brook 新版本已经更新了前置代理功能,客户端和服务端都可以经由 socks5 连接下一跳,楼主去试试,一条命令就行了,不用这么复杂还写配置文件

molezznet

2023-06-23 02:00:49 +08:00

最近有个帖子关于 tunnel 的也还是没有测试成功

wwxwlw

2023-07-01 17:43:43 +08:00

请问一下, 我在 clash 配置中添加了一个 wireguard 节点, 只能获取到 CN 的 IP, 我该怎样给它配置一个前置节点让 warp 可以拿到前置代理地区的 IP 呢? 按照贴中的教程试了 tunnel 和 dial-proxy 还是 cn, relay 是 timeout

Nile20

2023-07-01 20:15:18 +08:00

@wwxwlw 你可以试一下这个帖子里 https://www.v2ex.com/t/948499?p=1 的 20210610204811 发布的回答，他给了参考配置。我也有试过这个配置，能工作，但是不知道为什么我这边只有少量机场节点能够使用这个配置。由于我后面有自建的节点，就没有深入探究

exiaduck

2023-07-02 11:31:35 +08:00

问题 1. 服务端分流回国流量到 warp ，是为了避免有时客户端这边出站的时候分流规则没生效，导致访问国内网站流量经过了 vps ，然后 vps 直接返回应答的话，就会暴露 vps ；客户端出站分流不生效有几个原因，比如手滑开了全局、客户端 geoip 更新不及时没过滤掉一些漏网之鱼，或者没有分流规则的新设备直连了节点。

问题 2. wg 要作为链式代理出口，那么通道节点要支持 udp ，常见的 vmess 、trojan 好像都是不支持的，ss 可以，但是也要看服务端设置了如何处理 udp ，设置了不转发 udp 或者 uot 的好像都不行，所以免费机场节点要支持 wg 就要看运气要试。

问题 3. 自己搞廉价 vps 开 ss 是最稳定可靠的方案了，但也脱离了放心用不可信机场通道，或完全白嫖的初衷。但，反过来自己先套 warp 再用机场做出口，大部分情况是可以的，主要用来保护自己的同时利用机场节点切换落地的地区，但并不能远端套 warp 解锁一些网站。

wwxwlw

2023-07-03 09:38:25 +08:00

@Nile20 #33 非常感谢

ksdd521lr

2023-07-04 13:05:30 +08:00

@Nile20 我参考你讲的另一贴是配置出来和你一样的效果，即 warp 出口，但是不明白为什么连上几分钟就会断开，不碰它过一会又连上了，然后又断开这样循环，应该不是前置节点的问题，换了几个都是这样，同样的 wg 配置放到 wireguard 客户端就能正常使用不断开。

playboy0

351 天前

有作业可以抄吗😋