背景
Tor的Meek混淆插件最近比较好用， 由于Amazon、GAE和Azure上都有现成的中继装置， 直接让Tor启用Meek连接即可。
不过博主喜欢折腾， 用现成的东西感觉不是那么爽， 因此多方尝试折腾出一个自用的Meek反射器， 不用每次走Amazon的渠道了。
Meek基本原理介绍
首先启用了Meek的Tor链路是这样的状态：
本地Tor客户端->本地Meek客户端->服务器端Meek->服务器端Tor网桥
由本地的Meek客户端将Tor的数据包封装并发送到服务器端的Meek， 服务器端解析并将数据塞给服务器端的Tor， 由服务器端的Tor处理数据。
从本地Meek到服务器端的Meek连接便是Meek技术的核心所在， 即所谓的“Domain Fronting”技术。
本地Meek客户端->Google云服务器->GAE上的Meek服务器
现有Meek网桥的简单分析
(以下内容为博主个人猜想，可能有重大谬误...)
博主研究了Meek-Server的代码后发现， 需要在服务器搭建Tor并配置为网桥之后， 再让Meek-Server在Tor的前端接入Tor的流量。
那么就奇怪了， 难道所有的云服务器端都是部署了Tor的中继服务器？
查看Meek-client的Git仓库， 可以看到有多个版本的Server端部署代码， 包括AppEngine、php甚至是nginx的配置。
博主懂得一点php， 所以斗胆观摩了一下php的代码， 发现内容上其实只是把接收到的数据包转发给一个特定的地址。
再继续观摩AppEngine和nginx的配置， 发现它们的思路都是一样的， 转发到下面这个地址：
http://meek.XXXX.com:1234
于是博主猜测真正的情况是这样的： 其实GAE、Azure和AWS上现有的Meek中继都不是真正处理数据的服务器， 它们只是起到一个反射器(reflector)的作用， 将收到的数据包转发到真正的Meek服务器上， 上述的地址就是真正的Meek服务器。
个人反射器的搭建
搞定了原理之后， 就可以着手打造自己的Meek中继反射器了。
其实方法很简单， 照着仓库里的README把东西部署上去即可。
例如php版本需要一个能执行CURL的php空间， 把代码上传到空间上， 记录下URL， 就可以配置本地的torrc进行使用了。
这里假设配置好之后Internet上访问的URL是这个：
http://foo.com/bar.php
那么在torrc里的配置应该是这样的东西：
Bridge meek 0.0.2.0:1 url=http://foo.com/bar.php
这里的更改让Meek把数据包发送到以上的地址， 由服务器端的php代码（或者是nginx的反向代理）转发请求到真正的Meek服务器上。
没有front是因为这里不需要Meek的“domain fronting”技术， 本来这个地址就没有被干掉， 此外， 如果这个域名被干掉的话， 那么用这个域名搭建的任何东西也都没什么意义。
收益分析
基于自定义URL的Meek反射器可以提供比较稳定的连接， 毕竟不是大量使用的话不会受到干扰或者封禁。
另外就是树大招风， 像Google这种整个玉米被搞死的情况Meek也是无能为力的。 对于自定义URL则风险比较小。
当然这么做的一个坏处是把Meek用歪了， 废掉了Domain Fronting技术， 只是纯粹的做一个数据包的转发。
管它呢， 技术还是要能够实现功能最重要～
