换个角度解释 解决 workers.dev 被墙的各种方案
对于
我之前写了一篇 在自己的域名下 设置路由 指向 Cloudflare worker
在网上你可以看到添加
很多人不理解这些方案中的一些"骚操作".
希望此文能从另一个角度向你解释这些方案的原理.
前提条件
需要你了解 连接 V2Ray Websocket + TLS 模式的过程
不清楚的话, 请仔细阅读上面的链接
我把
(箭头指向的是同一个参数, 以下行文过程中会带上编号方便读者明白我说的是哪个参数)
workers.dev 被墙的原理
你的翻墙客户端发出的数据包, 需要经过
GFW
如果
解决 workers.dev 被墙的原理
解决问题的原理, 就是要想办法让我们发出的数据包里的
你会发现不管用什么方案, 最终让你修改
具体实现
以借路
1. 你的翻墙客户端要将数据包发送到 CDN 网络
可以采用以下实现之一:
* 这也正是各种解决方案千奇百怪的地方。
a. V2Ray 客户端的节点参数 地址 Address(1) 填 CF 优选 IP
b. 地址 Address(1) 填某域名,在你本地的 hosts 文件里设置解析为 CF 优选 IP
c. 在 Cloudflare 的 DNS 设置里,将某域名设置解析为 CF 优选 IP
d. '第三方'提供的可以当优选 IP 用的某个域名
如:icook.hk* 实质上是'第三方'设置了将这个域名解析为
e. 在 Cloudflare 的 DNS 设置里,将某域名设置打开 CDN
* 此时,该域名的
2. CDN 网络根据收到的数据包的 SNI 参数决定如何处理
以 域名
CDN
3. worker 收到了数据包,根据配置好的脚本处理
以如下脚本为例:
意思是说把数据包转发给 ball-speed.herokuapp.com
4. 目标域名 (你的梯子) 收到了数据包
整条数据流成功走通了。
如果是用 Cloud Pages 的解决方案
第
2. CDN 网络根据收到的数据包的 SNI 参数决定如何处理
域名
CDN
后面的步骤也差不多一样的
================
后记
为什么添加的路由是 wkr.ciys.cf/* 而不是 wkr.ciys.cf ?
因为配置了
wkr.ciys.cf/somepath 这个目的地可以匹配 wkr.ciys.cf/* 而不能匹配 wkr.ciys.cf。也就是说如果你没有配置路由为
评论
发表评论