标签： 代理

此处反代主要用于爬墙

方案一：
ip-scanner/cloudflare 的继任 cloudflare-better-ip

方案二：
用多地点 ping 工具 ping 以下域名

1. aGV4c2VuLmNvbQ==
2. YWxpLnNnLjEzMzM1MC54eXo=

对获得的 ip 验证或测速

之前用 time.cloudflare.com 作为固定 CF 加速节点，已经获得了比较稳定的连接，现在又发现了更有意思的玩法。

最近发现有个名为 ip-scanner/cloudflare 的项目，收集了许多非官方 CF IP。除非是做公益，这些节点无非就是配置不严谨的反代（或者蜜罐）

这些 IP 能用的并不多（比例上），不过通过 glider 的 check，10 秒不到即可在上千个 IP 中快速筛选出所有能用的 IP。我测试了一下能连通的比例大概是 15%。

真正有趣的地方不在这里，我很好奇这些 IP 的来源，于是翻了下 issue。有一条回复提到：有一些 ip 是对所有的域名都进行代理。

我跑了一遍所有的 IP，没想到这样的万能 IP 还不少，大约有几十个，有些甚至是整个段都可以用（包括 bot 漏扫的）。把代理的 IP 直接换掉即可加速线路，这样连 Cloudeflare 中转都省掉了。当然，443 端口 + websocket 是必须的。

具体流程是：

1. 抓取所有项目内的 IP

可以直接下载，也可以通过另一个 dogefy/CloudflareIP-AutoCollector 项目来抓取，需在同目录下自建 key.txt 并写入关键字才能顺利抓取（写 - 即可抓取全部）。

2. 测试所选的 IP

可先通过 glider 排除不可用的 IP，测试会快一些。
以下是一段批量测试 demo，这里用百度下拉关键字接口作为目标。ip_result.txt 是上一步默认生成的。

import subprocess

ip = open("ip.txt", "w")

for line in open("ip_result.txt"):
    try:
        result = subprocess.check_output('curl -m 5 "https://www.baidu.com/sugrec" --resolve www.baidu.com:443:'+line, shell=True)
        if "queryid" in str(result):
            ip.write(line)
    except:
        pass

ip.close()

3. 测速

用 CloudflareSpeedTest 测速。上一步默认生成到 ip.txt，直接运行 CloudflareST -dn 999 。

4. 安全

尽管蜜罐的可能性很低，但毕竟这些 IP 来历不明，最好不要用 Trojan-Go 和 VLESS，SS AEAD 和 VMESS 是比较好的选择。

至此，关于代理和加速已经没什么可探究了，再烂的线路都能起飞。

后话：这些 IP 还有个用途，可以写入 HOSTS 实现部分裸连。当然，这种做法不太安全，适用面窄，也容易被封。

issue 中似乎有人担心这个项目会被滥用，我觉得大可不必。这些 IP 轮换非常快，想用来建站是不可能的。作为代理加速，也必须是自建线路，同时筛选测试有一定门槛，即使知道原理，愿意用的人也不多。对于小白和白嫖用户来说，使用现成的工具订阅免费源依然最便捷的方式。

最近B站冒出来一堆“建站教程”类视频，还提供免费 CDN，不禁感叹阿猫阿狗都能做 IDC 了。

后来发现，这些 IDC 都是智简魔方 + easypanel 模板，甚至是对接的其他 IDC 做代理，自己网站连 ssl 都没有，令人惊叹。

不过这也不影响白嫖，因为之前研究过梯子套 CDN，正好就拿来试试。
这里有两个不错的上游 IDC，开设时间都很短，没跑路就先用着。

1. 小鹿云
   主机商自营一个博客也叫小鹿云，CDN 的 cname 也是这个域名的子域。
   一条美国免费线路，5 台服务器，0.1 元 / 100G / 月。
   需绑手机，不过通过代理开就不需要，而且免费，例如：景云
2. 幻话云
   美日韩港线路都有，6 台服务器，可自选 IP，0.01 元 / 10G / 月。
   CDN 服务不需要手机。

这套系统不支持域名回源，只能 IP 回源，所以需要落地机有公网 IPv4。至于域名可以随意填写，不过要打开跳过证书验证。也正因为如此，梯子协议应该选用有 AEAD 加密的方案。

速度上比 CloudFlare 快多了，希望能活得久。

设想

在《利用CDN对单条私有线路负载均衡》中提到，我试图用 Glider 作分流，但没能实现多路复用。最近又研究了一下 Glider 的配置，发现还是有解的。

最终，配出了一条自认为还算不错的方案： tls+ws+mux+ss

Glider 完整支持 TCP / UDP 且同时支持 Server / Client 的有 SOCKS5 / SS / Trojan(c) / Unix，考虑到过 CDN 的安全性，能支持 AEAD 加密的只有 SS，所以我使用 SS 作为基础协议，加密采用 AEAD_AES_128_GCM。

具体实施

Server 安装与启动，以 ubuntu 为例：

dpkg -i glider_x.x.x_linux_amd64.deb
systemctl enable glider@glider
systemctl start glider@glider
# systemctl restart glider@glider

默认配置文件 /etc/glider/glider.conf，加入 listen=ws://127.0.0.1:[port]/[path],smux://,ss://AEAD_AES_128_GCM:[pass]@。重启服务。

因为 443 端口还有其他业务，所以我把 tls 的部分交给 nginx 处理

location /[path] {
    proxy_redirect off;
    proxy_pass http://127.0.0.1:[port];
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
}

Client 配置：

直连：forward=wss://[host]/[path],smux://,ss://AEAD_AES_128_GCM:[path]@

CDN：forward=wss://[CDN_SERVER]/[path]?serverName=[YOUR_HOST]&host=[YOUR_HOST],smux://,ss://AEAD_AES_128_GCM:c2059aef-6ffb-44d1-a2ee-d9a379826cf1@

其中 CDN_SERVER 可以是 Cloudflare 自选 IP、CDN 提供的 CNAME 等，YOUR_HOST 就是回源服务器。其中，serverName 参数不是必须的，这取决于 CDN，比如：Cloudflare 要求指定，Asians.Group 可以不写。

一点技巧

如果使用 Asians.Group 的服务，host 将作为流量统计依据，这个域名无需真实存在。

例如：在后台填入自编域名 sam.ple，回源到真实的 domain.com:443，配置 Glider 客户端时将 host 指定为 sam.ple 即可。

如果流量不够，可以注册多个账户实现流量叠加，只要加入的域名不同即可，无需（也不可能）为其配置 ssl。

一点问题

以上方案并不能在手机上使用，因为手机没有 Glider，也没有客户端支持 smux 套 SS，更没有什么现成的叠速方案。

如何找到合适的线路

Cloudflare 可以用测速工具，其实就是抽签，速度只能保持一小段时间，个人感觉参考价值不大。我完整测试了全部 ip 段后得出的结论是，系统分配的基本接近最佳，建议用一批 Cloudflare 子域替代 ip，例如 h3.speed.cloudflare.com 、rpki.cloudflare.com 等。

子域挖掘工具：DNS Dumperster 和 Whois XML API剔除掉 NS 子域、固定 ip 子域后，用 Glider 批量验证：

glider 2>&1 | grep --line-buffered Elapsed | awk -F "[: ]" "{print $11}"

去重后填入配置形如：

forward=wss://migp.cloudflare.com/██?serverName=█.██.███&host=█.██.███,smux://,ss://AEAD_AES_128_GCM:████@
forward=wss://blog.cloudflare.com/██?serverName=█.██.███&host=█.██.███,smux://,ss://AEAD_AES_128_GCM:████@
forward=wss://rpki.cloudflare.com/██?serverName=█.██.███&host=█.██.███,smux://,ss://AEAD_AES_128_GCM:████@
#... 适合用 ha 策略

Asians.Group 也可以通过这个方式挖掘出 yk1.net （其 CNAME 主域）下的线路，有香港、美国、台湾、日本等，分别对应到各个 cluster-xxx 子域上。不过意义不大，因为都很快，直接用 asians.group 就行。

forward=wss://asians.group/██?host=1.██.███,smux://,ss://AEAD_AES_128_GCM:████@
forward=wss://asians.group/██?host=2.██.███,smux://,ss://AEAD_AES_128_GCM:████@
#... 适合用 rr 分流

CloudFront 等其他付费 CDN 请随意。

需求

自有线路，服务器有业务在跑，顺带做个自用机场。在特殊时期希望隐匿服务器 IP，所以考虑挂 CDN 使用。

免费的方案一般是套 CloudFlare 减速云，少部分使用 Asians.Group。瓶颈主要在单服限速（CloudFlare 的测速工具只能保证连通，很难稳定维持）。所以我希望本地可以做负载均衡。我预期的传输方式是，客户端 - 多台 CDN - 落地机。因为出口是同一台服务器，所以 url hash 不合适，最好是轮询。

寻找解决方案

v2ray 本身支持 轮询 和随机两种调度方式，问题在于 Gui 管理。v2rayN 只能通过导入 .json 文件的方式使用复杂配置，因为 ip 不稳定，配置格式使得频繁修改 ip 比较麻烦。而 Clash for Windows 默认是高可用模式，除非自己修改源码 才能支持轮询，所以也只能放弃。

最终找到 nadoo/glider，本身是代理链工具，它正好拥有以下特性：

1. 支持 vmess / vless / trojan 等协议
2. 配置结构简单，一行一条线路
3. 支持 round robin 策略

具体配置

协议方式：vm(l)ess + lts + websocket
客户端： glider + v2rayN / Clash for Windows

glider 说明中有很多示例，以下是针对 CDN 的具体配置。

以 vless 为例，服务器配置如下：

  "inbounds": [
    {
      "port": local-port,
      "listen": "127.0.0.1",
      "protocol": "vless",
      "settings": {
        "decryption": "none",
        "clients": [
          {
            "id": "put-your-uuid-here",
            "level": 0
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/ws"
        }
      }
    }
...

glider 本地配置：

code>forward=wss://{CDN_IP}/ws?serverName={YOUR-DOMAIN}&host={YOUR-DOMAIN},vless://{put-your-uuid-here}@

"inbounds": [
    {
      "port": local-port,
      "listen": "127.0.0.1",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "put-your-uuid-here",
            "alterId": 0
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
          "path": "/wss"
        }
      }
    }
...

code>forward=wss://{CDN_IP}/wss?serverName={YOUR-DOMAIN}&host={YOUR-DOMAIN},vmess://chacha20-poly1305:{put-your-uuid-here}@?alterID=0

code>forward=tls://{CDN_IP}:443?serverName={YOUR-DOMAIN},ws://@/wss?host={YOUR-DOMAIN},vmess://chacha20-poly1305:{put-your-uuid-here}@?alterID=0

将 glider 中的监听改为 code>listen=ss://aes-128-gcm:p@:8443，然后在 Clash 订阅工具中填入 code>ss://[email protected]:8443#Local。这会损失一部分性能，因为客户端不支持 ss 协议 none 加密，不过总体而言，PC 也不差这点性能。

parsers: # array
  - url: your-sub-url
    yaml:
      prepend-proxies:
        - name: "Local"
          type: socks5
          server: 127.0.0.1
          port: 8443

clash 不是一个合法地址，所以转换时会被丢弃，同时 parser 会在导入时加入一个 socks5 服务器。具体可以参考 配置文件预处理。

小结

以上方案仍然不能突破单服务器带宽限制，个人体验，打开一般网站已经很流畅，多线程下载也很顺畅，4K 视频比较吃力。另外，glider 不支持 v2ray 的 mux，算是一点遗憾。

至于如何测速和寻找稳定的 CDN IP，又是一个麻烦的问题。