小U上次分享自建VPN/代理翻墙已经是2017年（连WhatsApp都要翻墙？路由器刷固件架设SoftEther VPN Server翻墙的图文攻略），生活在墙外的我没有翻墙的“刚需”，但是祖国的春风在香港吹啊吹，又吹生了我对VPN翻墙的热情。昨晚花了一晚时间学习了Cloudflare Worker部署VLESS翻墙代理的代码 ，今早顺利根据网上的教程顺利来跑起了VLESS转发代理。如果你对VPN是否安全会有批判性思考，不是免费就9冲，那麽本文和大家分享几个技术细节你很可能感兴趣。
阅读全文: 真的安全？Cloudflare Worker部署VLESS翻墙代理的原理和proxyIP细节研究
摘要节点
Cloudflare Worker + VLESS的原理
Cloudflare Worker上可以运行javascript，作爲一个serverless function，每天有十万个10ms CPU time 的requests可以免费用。z大写的edgetunnel代码可以部署在Cloudflare Worker，爲数据包加添vlessheader信息，达到vless代理转发的目的。
由於Cloudflare在GFW国内某个程度能访问，而CF Worker又能访问GFW以外的信息，所以透过CF Worker来转发的数据理论上就达到了翻墙的效果。
详细的部署方法可以参考：
最关键的是下图在Cloudflare上设置的Worker的代码：
最值得深究的小U认爲是proxyIP的这个设定，爲什麽呢？
爲什麽还要proxyIP？安全吗？
代码中有一行神秘的proxyIP设定触动小U Cybersecurity 的神经，网上教程建议设置爲：103.200.112.108。这IP到底是谁？有什麽用？爲什麽需要？既然叫proxy，应该流量就应该是经过这些IP，教程中还要我们关闭加密设置？！这。。。第一反应是用WHOIS查找这些IP的拥有者：
感觉不安。既然是利用Cloudflare的Infrastructure进行转发的VLESS代理，爲什麽还要绕道去第三方的IP做代理？？会不会只是GFW墙内的情况所以要设定这个proxyIP？
小U把proxyIP 设置爲空白，果然Cloudflare Worker的页面就死了。唯有按图索骥研究这个proxyIP到底干什麽用的。
关於proxyIP的代码分析
细读z大的代码，发现proxyIP并不是每次转发都会用到，反而是“例外”的情况才会在retry() 函数中调用。那到底是什麽情况呢？z大在代码中其实有备注解释：
// if the cf connect tcp socket have no incoming data, we retry to redirect ip很抱歉小U的英文能力没能理解，按照上下文，z大把本地socket叫websocket，远端的叫remotesocket或者tcp socket，那可能是远端的tcp socket没有返回数据，就重定向到ip？看代码，ip指的就是proxyIP，那到底是把什麽重定向，那个proxyIP又爲什麽能解决问题？
唯有按图索骥寻找这个proxyIP的资料，功夫不废有心人，小U找到了 cloudflare worker搭建vless | Masheep (piig.top) 作者也有探究这个proxyIP到底是什麽，他说：
一些神奇的ip，可以无条件的转发所有cf流量
如果上面的proxyip用不了了，可以替换成下面这些域名
cdn-all.xn–b6gac.eu.org
cdn.xn–b6gac.eu.org
cdn-b100.xn–b6gac.eu.org
edgetunnel.anycast.eu.org
cdn.anycast.eu.org
另外可以参考这个issues进行proxyip查找
issues：https://github.com/zizifn/edgetunnel/issues/162
这个#162issue帮我指引我到了正确的答案，z大在自己的repo issue中解释到：
由于cf bug，现在cf worker 不能直接访问cf 托管的网站。。所以需要配置一个中转ip。。。而有一些神奇的 ip，可以无条件转发所有 cf 的流量。
z大口中的“神奇的ip”，就是proxyIP。而这个“cf bug”其实是Cloudflare的“有意爲之”，Cloudflare已在网志上说：
Outbound TCP sockets to Cloudflare IP ranges are temporarily blocked, but will be re-enabled shortly.
也就是说CF Worker是不能访问CF自家的IP，是不是很不可思议？而z大的代码就考虑到这一点，如果出现远端TCP不返回数据（例如远端的IP是CF自家的IP），就会触发 retry() 函数，把TCP包再发给proxyIP retry，让proxyIP丢回给CF的目的IP。
验证proxyIP的工作原理
如果proxyIP只是在访问Cloudflare IP时候触发的failsafe，那麽如果一个网站不是Cloudflare host/proxy/edge-caching/namesever等等的话，应该能够正常的访问才对。那什麽网站不会用Cloudflare？自然是Cloudflare的竞争者，例如AWS的Cloudfront。所以上AWS应该不会有任何问题，把proxyIP去掉上AWS果然正常：
Google也有自己一套CDN，不需要经过proxy转发，所以也解释了爲什麽YouTuber测试CF Worker+Vless的看YouTube速度这麽快的原因。
ProxyIP的问题
由於有大量网站都是利用CLOUDFLARE CDN的，导致z大的这套组合拳会经常调用proxyIP。引申的问题有：
安全性问题
z大的vless转发script似乎只有帮数据包套vlessHeader，并不是传统VPN那样上加密。这样的情况把数据转发不知道背後是谁运营的proxyIP放心吗？
速度问题
这些proxyIP能提供的转发速度不是无限的，单个IP也不知道有没有地域优化，导致ping值和速度都受限制。
能用多久？
我在网上搜到能用的这种“神奇的ip”就那麽几个，就算撇开安全性，如果没有了这种“神奇的ip”，Cloudflare又不重开Worker访问自家IP的权限的话，那麽这整套所谓“不需VPS 永久免费的Cloudflare VPN“就瞬间崩塌。
瑕不掩瑜：CloudFlare VLESS方案评价
虽然说道了现时的CF VLESS因爲proxyIP有各种问题，但是小U认爲CloudFlare+VLESS依然是现时最容易上手、性能首屈一指的免费翻墙方案。即使proxyIP出了问题，还是能用他能上到一些非Cloudflare的大型的外部网站和APP，进行下一步的翻墙部署，不能不说是极佳的“翻墙起手式”。
关於VLESS on Cloudflare，小U还有几个问题想研究/分享的：
如有任何问题或想讨论的，欢迎留言~
