自从2022年底大陆GFW能识别TLS in TLS之後，翻墙工具的军备竞赛又再掀起升级换代潮。现在写个翻墙的文章就像写新闻稿那样有时效性。本文分享我认爲现时最有效而且容易操作的3个新翻墙协议工具。
阅读全文: 【再不看就失效了】2023年8月三个可用的翻墙协议介绍和使用教程
摘要节点
什麽翻墙工具失效了？
先别急揭晓现时什麽翻墙工具可行，我们先了解一下GFW现在有什麽新技术，有哪些以前常用的翻墙已经失效，避免浪费时间。
各位在和GFW玩捉迷藏之前，要知道国内的地缘广阔，不同地区、不同ISP的捉迷藏游戏是不同规则的。所以出现“你行我不行”的情况不足爲奇。本文只能从“大环境”来入手分析。 基本确认已失效：大机率已失效：
2022年及之前主流的翻墙技术是爲SOCK5代理的数据包再套上TLS加密，用@yuhan6665的话说是“把GFW按在地上摩擦”。但是如同文章一开头所说，2022年底 GFW开始能识别TLS in TLS的特徵，导致一批主流的翻墙工具被破，包括：
爲什麽说大概率？因爲侦测TLS in TLS要花费不少GFW算力资源，按照现时的反馈并不是全网全IP都有执行。尤其在IPv6网段比较松，如果你”有幸“外网IP是IPv6，不妨试试这些可能还存活的。还有「中国的防火长城是如何检测和封锁完全加密流量的」论文提到到修改数据包特徵的改善，所以不能一刀切说所有TLS加密的方法（甚至没有套TLS的原始方法）都100%已失效。
但是如果你是从零开始翻墙，setup一次 “旧翻墙技术” 也要花费时间不少，还不如直接用2023最新的翻墙技术。
下文就立刻分享我认爲是2023年8月三大热门的翻墙新技术。要说下文的三个翻墙是“新技术”其实有点不准确，例如Cloudflare Worker 的Zizifn在2020年12月就已经开始开源，Naive Proxy项目更是2018年就开始。只是经过了多年的琢磨进化，适逢GFW发功，让这些技术更多被大家看到。
史上最简单：Cloudflare Worker + VLess
小U前文已经详细介绍了利用Cloudflare Worder打造VLESS翻墙代理，这可谓小U有史以来见过最轻量级、最简单的翻墙代理设置方法。最需要技术含量的地方就是复制粘贴Cloudflare Workers的运行代码：
简单概括 Cloudflare Worker + VLess 翻墙方法的优点和缺点：
无需自备VPS主机完全免费不需要命令行操作加密和隐匿性差依赖Proxy IP转发部署了CF CDN的网站workers.dev域名受污染UDP转发待考究Cloudflare Workers + VLess 服用建议
由於 Cloudflare Worker + VLess代理设置太简单了，小U建议所有翻墙新手，尤其是现在还在香港、台湾等墙外的网友，先尝试设定这种方式。比起买VPS、装Linux、开端口、改防火墙的一系列自建翻墙server步骤，实在是简单了一万倍。具体架设方法可以参考这个YouTube：
但这麽简单的翻墙方法，如果能100%成功，就不存在其他翻墙工具了。Cloudflare Workers + VLess 的弱点十分明显，免费版的Cloudflare Worker只能处理有限的代码，也不能套用加密，导致如果被主动嗅探是比较脆弱的。
爲什麽小U还这麽建议大家从这个起手？第一，文章一开始说到，GFW的规则不是唯一的，Cloudflare Worker + VLess 在某些网络环境依然能用。第二，新手最怕是新手村打BOSS，入门太难导致劝退。CF Workers的这招能用最直观、最易懂的方式让新手获得成功的快感，快速了解爲什麽要一台伺服器，什麽是Proxy 转发，V2Ray软件怎麽用，手机上怎麽设置等等的基础。
ProjectX的 XRay Reality加密和Vision”流控“
ProjectX (XRay) 是 ProjectV(V2Ray)的分支。小U一直喜欢用ProjectV的多一些因爲觉得他们更“正宗”，但是在对抗GFW TIT探测上，更爲“年轻”的ProjectX (XRay) 展现出让人赞叹的创造力。从网上各路留言看，现时ProjectX开发的最新的Reality加密和Vision流控对抗GFW探测的成功率非常高。截取官方的介绍：
Reality 是 Xray 的原创黑科技。 Reality 比 TLS 的安全性更高, 配置方式也和 TLS 一致.Reality 是目前最安全的传输加密方案, 且外部看来流量类型和正常上网具有一致性。 启用 Reality 并且配置合适的 XTLS Vision 流控模式, 可以 达到数倍甚至十几倍的性能提升。
传输方式 | Project X (xtls.github.io)
而且Reality+Vision的部署十分简单，利用一键安装脚本可以快速安装X-UI，然後在X-UI网页版点几下翻墙代理就ready了。无需自有域名、无需搞SSL证书，把易用性推上了新高度。
总结一下Reality加密和Vision”流控“的优缺点：
有效减少TLS in TLS和TLS指纹的特徵，新GFW的抗性强一键安装脚本和网页操作容易架设无需自有域名和申请SSL证书项目开源由ProjectX主导，圈内知名团队需要自己的VPS主机Reality配置不当会被”偷流量“脚本有各路人士修改，需要认准可信的来用
有兴趣尝试的可参考这几个YouTube教程：
Reality和Vision技术介绍
到底Reality和Vision是什麽呢？小U还没时间把RPRX的源代码过一次，从网上资料来看，两者的用途和区别如下：
参考文章/讨论：
站在Chrome的肩膀上？ Naive Proxy
Naive Proxy和传统的SOCKS Proxy设计理念不一样，Naive对数据包的重打包和发送并不是通过”人手写“的代码实现（例如：你也能写个 Shadowsocks ），而是基於修改chromium 的内核，再配合Caddy服务器（Caddy – The Ultimate Server with Automatic HTTPS），让翻墙流量看上去和用Chrome浏览器访问Caddy上的HTTPS网站十分相似。
但是Naive需要有自有的域名，安装方法也没有网页图形界面，V2Ray客户端的使用还有特别的步骤，爲什麽小U还是十分推荐Naive呢？因爲Naive的隐藏性实在很好，尤其是对於小U这种有网站在运营的站长来说，
还有，越是多人用的”一键脚本“，就越容易被人多搭沉船、枪打出头鸟。例如上一版X-UI配置Reality的”一键脚本“是僞造Microsoft.com的证书，没过两周Microsoft.com就出措施把这个“漏洞”堵上了。小U对Reality的僞造证书还有一个大胆的猜想：GFW总有一天能拿着你的僞造证书，交给真实的拥有者验证真僞，一招识别。
所以，网上已经有分享怎麽让Naive和Reality共存在443端口。当然这就属於进阶高手级别，不在本文范围了。
Naive安装重点
最後分享一下Naive安装过程中的技巧，由於Caddy是用Go写的，安装Caddy的时候需要用到Go来编译，而Ubutun不知道爲什麽用apt get / upgrade都只能升级到1.17还是1.18的Go，而最新的Go已经是1.21，编译Naive所需的Caddy需要起码1.19。小U是安装1.21的Go就能正常完成Caddy的安装。参考这两个帖子：
#删除已安装的golangsudo apt-get purge golang* #下载1.21版的Gowget https://go.dev/dl/go1.21.0.linux-amd64.tar.gz #解压缩到/usr/localtar -C /usr/local -xzf go1.11.4.linux-amd64.tar.gz #设置PATHmkdir ~/.goGOROOT=/usr/local/goGOPATH=~/.goPATH=$PATH:$GOROOT/bin:$GOPATH/bin#检查Go版本go version志愿者和开源的力量
借用@yuhan6665的话来做总结：
作为开发圈成员，可以毫不夸张的说，我们这群”破铜烂铁“的志愿者队伍，Shadowsocks，*ray，Trojan，Naive，Hystaria，Tuic，Sing，在此之前一直把审查者按在地上摩擦，还是花式的。TLS 代理战争才刚刚开始，审查者之所以要动用 AI 手段，恰恰从侧面证明了以前的审查方式，包括主动检测对于 TLS 代理都是无效的。而我们面对 AI 对手，必须要在细节层面做的更好。
XTLS Vision, fixes TLS in TLS, to the star and beyond · XTLS/Xray-core · Discussion #1295 (github.com)
本次介绍的三个项目都是在Github开源（怪不得GFW把Github都要封了），每个repo里面的讨论都感受到国内人士对翻墙的热情、专业和付出。「这群”破铜烂铁“的志愿者队伍」 撑起了对抗GFW的历史任务，一方面他们的成果让小U感叹敬佩，但另一方面，可悲这些出色的人才精力要浪费在对抗GFW上。
最後就如同文章一开始说的，现在写”翻墙“文章就像写新闻稿，一天不同一天。如果你有任何新的发现、报告、反馈，欢迎留言一起讨论分享。谢谢！
次分享1FacebookTweetPinLinkedIn
标签：翻墙
