在linux vps上。首先安装go环境，然后，
cd $GOPATH
go get -u -v github.com/eaglexiang/eagle.tunnel.go/
cd src/github.com/eaglexiang/eagle.tunnel.go/
go install
which eagle.tunnel.go
显示：
$GOBIN/eagle.tunnel.go
eagle.tunnel.go -h
eagle.tunnel.go --listen 0.0.0.0:3568 --et on --http on --socks on
不过此命令是运行在前台的，我们可以利用systemd把此命令运行为service:
nano /etc/systemd/system/eagle.tunnel.go.service
cat /etc/systemd/system/eagle.tunnel.go.service
[Unit]
After=network.target
[Service]
ExecStart=/root/go1.13/go/gopath/bin/eagle.tunnel.go --listen 0.0.0.0:3568 --et on --http on --socks on
Restart=always
[Install]
WantedBy=multi-user.target
然后运行：
systemctl start eagle.tunnel.go
systemctl enable eagle.tunnel.go
服务器端搭建完成。
cd $GOPATH
go get -u -v github.com/eaglexiang/eagle.tunnel.go/
cd src/github.com/eaglexiang/eagle.tunnel.go/
go install
which eagle.tunnel.go
显示：
$GOBIN/eagle.tunnel.go
说明eagle.tunnel.go安装成功。安装时，最好挂着vpn,否则可能安装失败。
eagle.tunnel.go -h
eagle.tunnel.go --listen 127.0.0.1:5678 --http on --socks on -r vps-public-ip:3568
保持此终端开着。然后设置chrome的http proxy或socks proxy的地址为127.0.0.1 ，端口为5678，chrome即可翻墙。如果安装chrome的switchomega插件，你可各建一个情景模式，一个选择http proxy协议，另一个选择socks proxy协议。然后，任选其中一个情景模式即可。建议选择http proxy情景模式，感觉http proxy比socks proxy更抗干扰。
(https://github.com/eaglexiang/eagle.tunnel.dotnet.core)
-------------------------------------------------------
-------------------------------------------------------
什么是 Eagle Tunnel
简单来说，这就是个代理工具。起初，ET（Github Repo）是一个HTTP代理协议的简单实现。但经过结构的演变，现在它的确更符合
隧道这个名字。在生活学习工作中，我们时不时会用到各种网络代理协议，ET 想要做到的，是一个透明的隧道，Web客户端在左边，Web服务器在右边。
在计划里，ET 将可以接收各种代理协议（目前仅仅支持SOCKS5 和 HTTP(s)），过滤成统一的 ET 协议格式，再进行加密的流量转发。
ET 已经处于可用状态，虽然它还在迭代中。它的目标是，简单部署，稳定工作，轻量占用。
我为什么开发ET
由于未知的神秘力量，国内总有很多网站打不开。因此和很多人一样，我被迫开始使用代理工具。不过从去年下半年开始，常用的工具都开始变得不稳定，这当然不怪工具本身，但我不得不因为网络环境的恶化不停为工具启用各种加密协议和混淆插件。 随着一个个VPS被封掉IP，代理工具的效率却与协议的安全性成反比——安全系数越高，由于加密和混淆的存在，效率越低。
事实上，目前的绝大多数网站，本身就自带最安全的SSL加密，那么我们在外面再额外套一层加密，意义又能有多大呢？代理大致可以分为两类——使用长连接的和使用短连接的。长连接意味着复杂的协议，以及较高的带宽损失。而对于短连接类而言，我们所需要保护的，仅仅是代理协议握手时的报文而已，从尺寸上来讲，通常连1KB都不到，我们有必要为了这区区1KB搞一套复杂的加密和混淆吗？要知道这并不是没有代价的，除了更高的延迟之外，额外的SSL握手，在网络不够通畅的情况下，很可能会导致连接失败。因此我试着开发了ET，由于几乎没人使用，它的协议非常安全，我几乎没有给流量做任何有质量的额外加密，但这并不妨碍它的稳定工作，同时，这带来了CPU资源的节约（如下图）。当然，从代码结构或者通信协议上来讲，如果将来有需要，给它增添额外的加密外壳是很容易的。
如果 ET 开始有人使用
现在我们有一个新的问题，万一将来有一天，使用ET的人变多，ET的协议被更加恶化的网络环境吃掉怎么办？
ET还没资格遇到这样的挑战，不过想当然地预测一下，也许有一个更简单的解决方案——我们调整协议就行了。这并不是一件不可接受的事情，对于使用短连接的ET来说，调整协议的损失相当低。就目前的ET架构而言，ET的程序分为两个部分——提供核心功能的内核，以及提供用户界面的外壳。理想情况下，外壳与内核会保持相对解耦，也就是说，为了对抗日益恶化的网络环境，ET有可能会更新内核的通信协议，而这对用户的外在体验没有丝毫影响。换句话说，用户所要做的，就是简单地选择协议版本，只要服务端与客户端的协议版本号一致，ET就可以正常工作。网络环境的危险毕竟是有限的，而协议版本的可能性是无限的。极端一点，ET甚至可以开放协议定义的接口，由用户自定义自己的握手协议。
我也看到有人在讨论，神秘力量启用了AI，可以智能识别流量特征，因此哪怕给SS装备上RSA，仍然会被精准识别。但我的亲身体验告诉我，目前对SS的识别是相当精准的，VPS往往刚刚上线SS便被ban掉，如果不启用SS服务，启用的是自建协议的ET，却可以长期（目前已经半年）稳定使用。这说明即便AI存在，也是与SS的协议耦合的。网络上提到的论文《The Random Forest based Detection of Shadowsock's Traffic》我也大致浏览了一遍，如果理解没出偏差，其生效的前提也得是代理的客户端与服务端同时处于控制之下。不过既然都在控制里了……
以上都是我的YY，因为ET用户太少了，所以这是否真能解决问题，我也不知道。不过目前作为小众产品，它还挺好使的 : )。
-------
翻墙速度不快。
