20210602更新
形象来说：其他翻墙软件都是用代理这个“梯子”看外面，西厢则是在利用墙的缝隙直接穿过去 ！
根据相关论文，墙的裂缝不会少，而且有的缝还不好改，所以了解过后，感觉西厢的思路还是可行的，现在没法继续挺可惜的，如果可以以国外的大神为主国内为辅继续这个计划就太好了，不仅是多了一种翻墙方式，更是对墙的一种正面挑战和嘲讽。不过，基本这项工作就是用爱发电，如果没有国外机构大学或者政府的赞助，根本就无法长久维持，这也是原小组解散的一个原因吧。
以下原帖：
搜过本版块，没有找到相关帖子，如有违规，请版主删除！！
首先，需要说的是西厢计划因为开发小组解散没有更新已经不能使用了，就是刚开发出来时，也算是试验性质的。不过虽然是试验性的，当时已经可以让用户以普通浏览器无障碍地直连Youtube，而且提供了另一种翻墙方式，或者说穿墙方式。目前主流翻墙软件，差不多都是借助代理服务器的方式翻墙，而西厢计划则是针对墙本身，利用墙的漏洞（是软件就会有漏洞）欺骗墙，从而可以直连外网。西厢计划不是代理，不是VPN，无需加密，使用时不需要第三方支援，不需要绕道，速度相比代理要快的许多。
引用开发小组自己的话：
作为个搞技术的人，我们要干点疯狂的事。如果我们不动手，我们就要被比我们差的远的坏技术人员欺负。这太丢人了。眼前就是，GFW这个东西，之前是我们不抱团，让它猖狂了。现在咱们得凑一起，想出来一个办法让它郁闷一下，不能老被欺负吧。要不，等到未来，后代会嘲笑我们这些没用的家伙，就象我们说别人“你怎么不反抗？
虽然他们已经解散，但是他们为我们指明了另一种可能性。不知道有没有高手们愿意继续下去
以下是大概原理解释，想要了解更多细节google一下，原文分了多章 ，就不分开水帖了。
先说大方向。大家都知道，连接被重置的本质，是因为收到了破坏连接的一个 TCP Reset 包。以前剑桥大学有人实验过，客户端和服务器都忽略 Reset, 则通信可以不受影响。但是这个方法其实只有理论价值，因为绝大多数服务器都不可能忽略 Reset 的 (比如 Linux, 需要 root 权限配置iptables, 而且这本身也把正常的 Reset 给忽略了)。只要服务器不忽略 Reset, 客户端再怎么弄都没用，因为服务器会停止发送数据，Reset 这条连接。所以，很多报道说西厢计划是忽略 Reset, 我从源代码来看应该不是这样。在我看来，西厢计划是利用了墙的一个可能的弱点–墙只在连接发起的时候把一个 TCP 连接加入监听序列，如果墙认为这个连接终止了，就会从监听序列中去掉这条记录，这样，这条连接上后续的包就不会被监听。西厢计划就是让墙“认为”这个连接终止的一个绝妙的方法。只要墙认为这个连接两端都是死老虎，墙就不会触发关键词检测，其后所有的数据，都不存在连接被重置的问题了。
如何让一个连接置之死地而后生，就是西厢计划那帮黑客神奇的地方了。这也不是一日之功。 首先，这帮牛人发现，墙的是一个入侵检测系统，把含有关键字的包当成一种“入侵”来对待。采取这种设计有很多好处，但缺点是入侵检测系统可能具有的问题，墙都可能有。西厢计划主页上那篇著名的论文就是讲这些七七八八的漏洞的。可以说处理这些七七八八的漏洞是非常困难的，迫使墙的设计者“拆东墙，补西墙”。这样补来补去，外表看起来好像很牛逼的墙，其实有很多本质上无法简单修补的漏洞，其中有一个致命的，就是 TCP 连接状态的判定问题。 出于入侵检测系统这种设计的局限，墙没有，也没办法准确判定一条 TCP 连接的状态，而只是根据两边收到的数据来“推测”连接的状态。而所有的关键词检测功能，都是基于“连接还活着”的这个推测的结果的。因为墙的规则是在连接发起的时候开始对这条连接的检测，在连接终止的时候停止对这条连接的检测，所以，一旦对连接的状态推测错误，把还活着的连接当成已经关闭的连接，墙就会放弃对这条连接上随后所有的包的检测，他们都会都透明的穿过墙的入侵检测。
上面只是想法，具体到 TCP 协议实现这一层，就要只迷惑墙，还不能触及我要通信的服务器。最理想的情况下，在任何有效通信之前，就能让墙出现错误判断，这些，就需要对 TCP 协议有深刻理解了。西厢计划的那帮黑客，居然真的去读 TCP 几百页的 RFC，还居然就发现了方法（这里我假设读者都知道 TCP 的三次握手过程和序列号每次加一的规则）。 我们都知道，三次握手的时候，在收到服务器的 SYN/ACK 的时候，客户端如果发送 ACK 并且序列号+1 就算建立连接了，但是客户端如果发送一个序列号没 +1 的 FIN （表示连接终止，但是服务器知道，这时候连接还没建立呢， FIN 这个包状态是错的，加上序列号也是错的，服务器自己一判断，就知道这个包是坏包，按照标准协议，服务器随手丢弃了这个包）, 但这个包，过墙的时候，在墙看来，是表示连接终止的(墙是 ma de in china, 是比较山寨的，不维护连接状态，并且，墙并没有记下刚才服务器出去的 SYN/ACK 的序列号，所以墙不知道序列号错了）。所以，墙很高兴的理解为连接终止，舒了一口气去重置其他连接了， 而这个连接，就成了僵尸，墙不管你客户端了，而这时候，好戏才刚刚开始。
事实上，墙是双向检测的（或者说对每个包都检测的），因此，对服务器和客户端实现相同的对待方法，所以，墙不管客户端还不行，假如服务端有关键词传给客户端，墙还是有可能要发飙的（这里说有可能，因为我也不知道）。所以，最好的办法就是，让服务端也给墙一个终止连接的标志就好了。可是这个说起来简单，做起来难，怎么能让不受自己控制的服务器发一个自己想要的包呢？ 西厢计划的那帮黑客，再次去读几百页的 RFC, 令人惊讶的发现，他们居然在 RFC 上发现了一个可以用的特性。我们上面说了，三次握手的时候，在收到 SYN/ACK 后，客户端要给服务器发送一个序列号+1 的ACK，可是，假如我不+1呢，直接发 ACK 包给服务器。 墙已经认为你客户端是死老虎了，不理你了，不知道你搞什么飞机，让这个 ACK 过了。可是服务器一看，不对啊，你给我的不是我期待的那个序列号， RFC 上说了，TCP 包如果序列号错了的话，就回复一个 Reset. 所以，服务器就回复了一个 Reset。这个 Reset 过墙的时候，墙一看乐了，服务器也终止连接了，好吧，两边都是死老虎了，我就不监听这条连接了。而至于客户端，这个服务器过来的 Reset 非常好识别，忽略就是。随后，客户端开始正确的发送 ACK, 至此，三次握手成功，真正的好戏开始，而墙则认为客户端和服务器都是死老虎，直接放过。所以，张生就这样透明的过了墙。 至于过墙以后所有的事情，《西厢记》里面都有记载，各位读者自行买书学习。
西厢提出的是一种技术而不是一种资源，因此没有西厢客户端一说，也不存在被封。西厢所做的只是指出了墙上本来存在的裂缝，而且这个裂缝是可以利用的
西厢的开发有多难？有人拿毕设来与之相比，这有点不可思议。事实上，西厢的原理部分一年前就完成了，主要依据就是T. Ptacek的那篇论文，实验结果也很好。而最终的netfilter实现者说他花了一周时间看内核代码netfilter那部分，然后就着现成的代码直接改成现在这个样子了。难吗？为什么西厢压了一年没有发出来？在这一年中，
这样一些系列从零到有的文章，是要展示一种对GFW进行全面理解的学习过程和方法，表达一种对GFW进行逆向工程的趣味。读者不应该仅仅作为一个信息的接收者，而是应该有自己积极的思考。如果读者中有百分之一开始自己思考关于GFW的问题，千分之一开始自己动手研究GFW，如果有万分之一开始将原理付诸实践，那就是很好的结果。如果所有人都只是伸手而没有动力去自行了解GFW，那么就只会让GFW越来越强大，而自己被动挨打被GFW追得到处跑。GFW在背后技术力量的推动下变动不居，不断地被更新、不断地发生变化，对GFW永远正确的认知或者一劳永逸的翻墙方法并不存在，只有与之对抗的方法和学习动力能留存下来。……
西厢的提出就是为了说明，GFW也远没有你们想象得那样强大，而是充满了漏洞。只要你敢于动手，就一定有所收获。请记住，西厢是个tech demo，发布出来不是给你用的，而是给你研究的。如果你认为你的能力不比哈工大、北邮那些筑墙的学生差，那么请你体现你的存在。
[ 此貼被我的世界w在2021-06-02 20:35重新編輯 ]
赞(15)