继续白嫖 CloudFlare ——给 Xray 服务端回国流量套上 WARP+

背景

之前搭建的 Xray 服务端把 geoip:cn, geosite:cn 全导进 blackhole 了，这次来白嫖 CloudFlare 的 WARP+ ，把回国的流量套上 WARP+ 。

安全方面的考虑

正常访问境外网络时大概是这样的：

flowchart LR; c(Xray 客户端); f[璃月的防火墙]; s(Xray 服务端); w(境外网站); y(你); subgraph 璃月境内; y --- c --- f; end; f --- s --- w; linkStyle default stroke:green

璃月的防火墙只能知道你在访问一台境外服务器；而经过 Xray 服务端访问国内的网站时，大概是这样的：

flowchart LR; c(Xray 客户端); f["璃\n月\n的\n防\n火\n墙"]; s(Xray 服务端); cn(国内网站); y(你); subgraph 璃月境内; y --- c -- "😋" --- f; cn -- "😭" --- f; end; f -- "😋" --- s -- "😭" --- f; linkStyle 0,1,3 stroke:blue; linkStyle 2,4 stroke:red

经过璃月的墙与 Xray 服务端建立连接后， Xray 服务端马上又经过璃月的墙与璃月境内的网站建立连接，理论上可以判断 Xray 服务端所在的这台服务器是代理服务器。为了解决这种特征问题，给回国流量套上 WARP+ ，可以变成这样：

flowchart LR; c(Xray 客户端); f["璃\n月\n的\n防\n火\n墙"]; s(Xray 服务端); cn(国内网站); y(你); w(CloudFlare WARP+); subgraph 璃月境内; y --- c -- "😋" --- f; cn -- "😁" --- f; end; f -- "😋" --- s; f -- "😁" --- w -- "😎" --- s; linkStyle 0,1,3 stroke:blue; linkStyle 2,4,5 stroke:red

这台服务器理论上不能像上面那样被判断为代理服务器了，而且璃月的防火墙不能一刀切 CloudFlare ，所以这种方案理论上是完美的。

实用性的考虑

有的时候国内的 IP 在网上对线时是劣势，总有人喜欢地域黑，一般发生在道理讲不过别人的时候，这个时候一个外国的 IP 能极大程度避免这种劣势，这种手段在某蓝色知识平台尤为重要。
一些地方会屏蔽数据中心的 IP ，比如 ExHentai 的 s.exhentai.org 把我的某一台机器的 IP 屏蔽了，主站功能都正常，但 Gallery 的封面刷不出来，套上 WARP+ 有概率解决这种问题。~~或者配额不够了的情况可以白嫖 WARP+ 的 IP 暂时缓解配额的问题。~~

01. 关于 CloudFlare WARP+

一般来说 WARP 是免费的， WARP+ 是要收费的，但网络上的一些地方总能找到能白嫖的地方，我就在某个蓝色的通信软件上拿到了一个已经应用了 WARP+ 的 key 的 WARP 配置，我拿到的是这种格式的：

[Interface]
PrivateKey = <Base64 编码的二进制数据>
Address = <IPv4 和 IPv6 两个 CIDR >
DNS = 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, 2606:4700:4700::1001
MTU = 1280
[Peer]
PublicKey = <Base64 编码的二进制数据>
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:2408

如果搞不到 WARP+ 的 Key 可以用 wgcf 搞一个免费的 WARP 的 Key ，格式跟上面类似。

02. Xray 服务端配置

CloudFlare WARP+ 走的是 WireGuard 协议，是一个很常见的代理协议，墙可以精确的识别阻断这种流量，所以 WARP+ 只能套给 Xray 服务端，在墙内的客户端是不能用的。我的配置如下：

{
  // ...
  "routing": {
    // ...
    "rules": [
      {
        "outboundTag": "warp",
        "ip": [
          "geoip:cn" // 常见璃月 IP 走 WARP+
        ]
      },
      {
        "outboundTag": "warp",
        "domain": [
          "geosite:cn",           // 常见璃月域名走 WARP+
          "domain:s.exhentai.org" // ExHentai 的封面，套上 WARP+ 实测可用
        ]
      }
    ]
  },

  "outbounds": [
    // ...
    {
      "protocol": "wireguard",
      "settings": {
        "secretKey": "<刚刚拿到的 PrivateKey 的内容>",
        "address": [
          "<刚刚拿到的 Address 的内容，一个 IPv4 CIDR>",
          "<一个 IPv6 CIDR>"
        ],
        "mtu": 1280,
        "peers": [
          {
            "publicKey": "<刚刚拿到的 PublicKey 的内容>",
            "endpoint": "engage.cloudflareclient.com:2408"
          }
        ]
      },
      "tag": "warp"
    }
  ]
}

需要注意的是 WARP+ 有连接设备数量限制，我白嫖到的 Key 只能一个设备连接。

03. Xray 客户端配置

其实就是把需要走 WARP+ 的东西导进上面配置好的 Xray 服务端。假如我想让知乎走 WARP+ ，在 Routing 里加上一条：

{
  "outboundTag": "proxy",
  "domain": [
    "domain:zhihu.com"
  ]
}

这里没有用 geosite:zhihu ，因为里面有 zhimg.com 负责知乎的图片，也套 WARP+ 会拖慢加载速度，而且我个人认为没必要。

总结

CloudFlare 真是赛博活菩萨，祝 CloudFlare 永远不死、活着。
为啥 Domain List 项目没有专门为国内各平台用于的 IP 属地检测的域名单独设立一项呢？
其实这波属于是落后时代的龙鸣了，前几年 IP 属地显示 CLOUDFLARE 的一抓一大把，可惜现在已经不能装这个逼了。

关于 CloudFlare CDN

逼乎有假装正义的懂哥来讨伐我了，在那边澄清之后感觉这边也应该同步一下，不能白白多写这几百字。

这篇文章介绍的是 CloudFlare 官方推出的、专门用于代理的服务—— WARP ，与 CloudFlare CDN 无关，因此并没有滥用 CloudFlare CDN 的情节。

为啥会有 CloudFlare CDN 用于科学上网的言论

个人搭建科学上网（不用鸡场）一般需要购买没有被璃月的防火墙封锁的璃月境外 IP ，但因为众所周知的原因，这个 IP 有概率会在买来用一段时间之后被璃月的防火墙封锁，这时这个 IP 基本不能再用于科学上网了（毕竟璃月境内访问不了）。但一些科学上网的协议是伪装成 HTTPS/WSS 的， CDN 恰好能充当一个反向代理，左手牵住璃月境内的用户，右手拉上已经被璃月的防火墙封锁的 IP ，就可以救活这个 IP 了。

如果 IP 没有被封锁，还非要套上 CDN ，只会拖慢网速，对整体的体验没有任何正向提升。

我的看法

我永远不会为了救活一个被封锁的 IP 去套 CDN ，因为换一个 IP 也只要几刀。同时我反对这种滥用 CDN 的行为。

这篇文章介绍的 WARP 不是 CDN 吗

不是， WARP 是 CloudFlare 官方推出的、专门用于代理的一项服务，也就是说这篇文章介绍的用法，就是 WARP 的正确用途。

RayAlto's Blog