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

[Nile20]

前一段时间看到 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 链式代理实践工具链或者博文推荐？

恳请各位大佬不吝赐教

[popzuk]

简洁地说，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]

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

[lightcreater]

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

[Nile20]

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

[Nile20]

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

[czwstc]

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

[popzuk]

@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]

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

[popzuk]

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

[taresky]

有在用，surge 可以

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

[zbinlin]

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

[christin]

这不是巧了么，昨晚刚搞好，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]

自用了很久地方案:

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

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

3.自己买 VPS

4.BROOK OVER CHISEL OVER SOCKS5

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

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

[7RTDKSAK]

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

[misaka00001]

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]

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

[misaka00001]

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]

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

[docx]

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

[kaddusabagei38]

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