VPN 协议

Shadowsocks

shadowsocks 可以说是继 VPN 被墙能准确识别并封锁后，后面的一切代理服务器中转的方式的祖师爷。

shadowsocks 开发之初就是为了过墙，实现原理简单粗暴，直捣黄龙，写程序的角度看就是直接奔着解决问题去的。

有不少人都说 shadowsocks 已经能被墙准确识别，毕竟就连 ss 的作者也都被请去喝茶了，而作为第一代的代理程序，很多漏洞没有得到较好的修复，导致墙已经能准确的识别出 ss 的流量特征。

但是目前就我所知道的来说，除开一开始有一定非 AEAD 加密数据被准确识别的 BUG 外（已修复），我并没有确切的得到 ss 已被确切封锁的实质性证据，大多数人跟着锤 shadowsocks 都是因为自己的服务器太过猖狂然后被封了，实际上墙的封锁机制极其复杂，检测机制包括但不限于 IP 段，判断流量头，端口，数据量大小，还有人工干预等等，这口锅并不能完全推到 ss 上。

shadowsocks 引出了一个把代理服务器拆分成本地和远程两个的概念，实现了经过墙的流量全部加密，完美的规避了之前 VPN 仍保留一部分明文通讯的特征缺点。

和 VPN 最大的不同就是，VPN 是先发送一个建立加密通道的明文数据包，套路固定，特征明显，而 shadowsocks 则是在本地先加密完成后，再发送至代理服务区，过墙期间数据完全加密，特征不明显。

另外，shadowsocks 拥有着目前 socks5 代理类型里的最快的通讯延迟（RTT），因为数据包握手的时间最短。

就目前来说，shadowsocks 还是目前体验最好，最简单快速，最极度体现暴力美学的中转代理方式。

ShadowsocksR

SSR 是 shadowsocks 的优化版，但是作者不是同一个。

在 ss 作者被喝茶之后，github 上出现了一个叫 breakwa11 (破娃) 的帐号，声称 ss 容易被防火墙检测到，所以在混淆和协议方面做了改进，更加不容易被检测到，而且兼容 ss，改进后的项目叫 shadowsocks-R，简称 ssr，然后 ss 用户和 ssr 用户自然分成了两个派别，互相撕逼，直到有一段时间，破娃被人肉出来，（一说是破娃的朋友被人肉出来 —— 退而结网注）无奈之下删除了 ssr 的代码，并且解散了所有相关群组。

我个人认为没有必要纠结是用 ss 还是 ssr。如果你是机场用户，ss 无疑是最优选，毕竟体验最好，封了也跟你没关系。

VMess

Vmess 是基于 V2Ray 内核自研的协议。

先来介绍一下 V2Ray 这个极具弹性平台吧。和之前的 VPN 和 Shadowsock 类型不同的一点就是，V2Ray 是一个内核，他不是单独运行的，这是一个框架，对开发者来说更加自由。

自 2020 年 6 月以来，V2Ray 平台就爆出了一些很不安全的 BUG，建议大家尽快更换到 Xray 内核，或者更换协议！

V2Ray 就像叠积木，一笔一划的慢慢逐步把梯子叠出来，对于技术力十分入门的小白来说可能不是太友好，而且 V2Ray 平台上的套娃严重，V2Ray 可以下面这样用：

vmess vmess + tls vmess + websocket + tls vmess + websocket + tls + Nginx vmess + websocket + tls + Nginx + cloudfare（CDN）

上至下，一层层套娃，套的越多越安全，当然速度也就越慢。如果真的从头搭建起来，那就真是令人头都大了，还好有大神开发一键脚本，有兴趣的朋友自行搜索。

VLess

可以理解为 VLess 是 VMess 轻量版，VLESS 是一个无状态的轻量传输协议，它分为入站和出站两部分，可以作为 V2Ray 客户端和服务器之间的桥梁。

与 VMess 不同，VLESS 不依赖于系统时间，认证方式同样为 UUID，但不需要 alterId。

同样的，和 VMess 一样，即支持 V2Ray，也支持最新的 XRay。一样可以套娃

vless vless + tls vless + websocket + tls vless + websocket + tls + web vless + websocket + tls + web + cloudfare（CDN）

Trojan

根据官网给出的解释，Trojan 的设计理念与传统协议的设计理念相反，Trojan 不使用强加密和随机模糊，而是直接模仿互联网最常见的协议 HTTPS，以此来达到设计的目的。

当然，这显然是瞎扯淡。HTTPS 协议本身就含有加密，而且 TLS 1.3 更是强加密，现今无法通过简单方式破解。Trojan 本身使用了 HTTPS 的特性，自带了加密属性，只不过这种加密大家都在用而已，因此官网描述是不准确的。

不难发现，若 V2Ray 使用了 WS + TLS 方式，其协议与 Trojan 本身差异并不大。两者建立连接的过程有区别，但是从流量本身，或者说第三者看流量是难以发现区别的。也就是说，对于第三者的监听，这两类协议与普通流量表现均一致，这是两者的共性。

因此，仅从真正使用的流量的传输速度看，Trojan 在原理上是一定快于 V2Ray 的，倒不是 Trojan 有什么黑科技，而是 Trojan 比 V2Ray 更简单，我们可以认为 Trojan 就是一个只有 WS+TLS 协议的 V2Ray 的简化版本（不能简单等同）。这也许就是 Trojan 的设计理念吧，我认为把 Trojan 介绍成：以简单的方法利用互联网最常见、最安全的形式完成连接的一种协议，这样的介绍或许会更好。

Trojan-go

Trojan-go 可以看作是 Trojan 的加强版，最重要是支持了 websocket 和多路复用！同时目前也是笔主本人主要使用的科学上网方式，不仅很稳定，而且体验很好。

支持了 websocket 的 Trojan-go，可以说基本上就是不会死的存在，毕竟支持了 websocket 后，就可以套用 CDN 了，隐藏了真实的 IP（梦回 V2Ray 终极套娃版），而且支持了多路复用，显著提升了网页的打开速度。

Trojan 最大的缺点其实也是优点之一，就是用 443 端口进行输出，这点不管是 Trojan 还是 Trojan-go 都是一样的。

用 443 端口本来是没有什么问题的，但是很多朋友的服务器不仅仅是用来搭建梯子的，可能还会装个宝塔面板，搭个小网站，或者干些别的事，但是如果用的是 Trojan 服务，把 443 端口占了，那别的服务就没有办法运行。

这里贴上一位大佬的解决思路：如何实现 Trojan 共用 443 端口方案

如果能成功将 Trojan 和自己的网站或者其他服务绑起来，使 Trojan 服务器 有一定的日活 IP，那么这将是伪装科学上网的终极形态！

NaiveProxy

Naiveproxy 从 2019 年年末初出江湖，到现在也差不多经过 10 个月的发展了，只是在爆出 V2RAY-VMESS 的漏洞新闻之后，Naiveproxy 才进入了更多人的眼球，并迅速蔓延。

其实作者的开发思路很清晰，因为我们使用科学上网协议的混淆、加密的时代已经过去了，很多例子已经证明，混淆本身就会成为一个被攻击或是被审查对象，自己弄的一些加密协议，终归还是敌不过专门研究加密的一些学者所做出的东西。

所以作者的思路是采用最常用的浏览器的网络堆栈，来躲避墙的审查。因为审查常用的浏览器的网络堆栈代价还是很高很高的，所以这样也就大大降低了我们的节点或是 VPS，被阻断或是和被墙的风险。

对于 Naiveproxy 的使用，我个人推荐使用 Naiveproxy + TLS + Caddy 来自行搭建，也可以使用 ProxuSU 进行搭建。