SS：作者是clowwindy，大约两年前，他自己为了翻墙写了shadowsocks，简称ss或者叫影梭，后来他觉得这个东西非常好用，速度快，而且不会被封锁，他就把源码共享在了github上，然后就火了，但是后来作者被请去喝茶，删了代码，并且保证不再参与维护更新。现在这个好像是一个国外的大兄弟在维护。

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

ss和ssr它的原理都是一样的，就是socks5代理，。socks代理只是简单的传递数据包，而不必关心是何种协议，所以socks代理比其他应用层代理要快的多。socks5代理是把你的网络数据请求通过一条连接你和代理服务器之间的通道，由服务器转发到目的地，这个过程中你是没有通过一条专用通道的，只是数据包的发出，然后被代理服务器收到，整个过程并没有额外的处理。通俗的说，现在你有一个代理服务器在香港，比如你现在想要访问google，你的电脑发出请求，流量通过socks5连接发到你在香港的服务器上，然后再由你在香港的服务器去访问google，再把访问结果传回你的电脑，这样就实现了翻墙。

我最早的socks5应用应该是15年前运用扫描到的IP用socks5代理做跳板，爆破密码，很多场合下，同一个IP不断尝试破解一个目标时，该目标会做出防御措施，封锁该源IP，在爆破场合下，必须用socks5代理不断变更源IP来进行暴力破解，当然socks5的具体应用远不止这些。

SS&SSR的安装

我用了秋水逸冰的一键安装脚本在VPS上成功部署，简单快捷，过程略。测试速度一个字：快，两个字：很快，三个字：非常快。就算不做加速处理，其速度也比收费VPN快很多倍，如果需要做加速处理，可以安装锐速补丁或者Google的BBR，我在banwagon的vps上安装了bbr，速度并没有感觉提升多少，感觉更多的是bbr优化的更多的是TCP的丢包，也可能是因为原本就很快，再快也感觉不出来，可是有一点，youtube上观看4K，我安装BBR加速的SSR（banwagon）会略卡，而linode原生SSR确一点也不卡，这也是为什么我在最适合国人的VPS上推荐linode的主要原因之一。

SS/酸酸

加密请使用 AEAD 加密，包括以下几个：

1. aes-128-gcm
2. aes-192-gcm
3. aes-256-gcm
4. chacha20-ietf-poly1305
5. xchacha20-ietf-poly1305

1. 对于移动设备来说，ARM v8 以后的 CPU 使用aes-gcm的效率要高于chacha20，因此更推荐使用aes-256-gcm
2. 混淆请使用plain，即不使用混淆插件，或者使用http_simple

SSR/酸酸乳

1. 加密请使用none
2. 协议请使用chain_a
3. 混淆请使用plain或者http_simple

有很多萌新同学直接拿一键脚本搭建的，脚本要求设置参数的时候也许萌新们就直接一路回车默认过去或者随便选了，殊不知这可能就正是VPS被Q的原因

混淆为什么不选tls
这是有可能导致被Q的一个首要原因，因此我也放到第一位来讲，也许细心的同学们也发现了上述推荐配置中的混淆这一行都加粗了，是的，这非常重要

前段时间我与其他人讨论的时候，就发现了一个共同点，那就是被Q的人大多数都使用了tls1.2_ticket_auth混淆；而一些混淆plain的人，即使还在使用老旧甚至过时的协议，却安然无恙

很有理由猜测 GFW 已经掌握了 tls 混淆的特征

让我更确信了我的猜测的是，后来询问我被Q相关问题的人，大多数都用的是搬瓦工后台自带酸酸乳，因为我从没有用过搬瓦工，我询问了他们后才知道，搬瓦工的酸酸乳是强制tls1.2_ticket_auth混淆，嗯，真不愧是 GFW 最佳合作伙伴（而且搬瓦工自带酸酸居然没有 AEAD 加密）

后来，推特上也有人指出

“酸酸乳的tls凭据复用已经成为安全问题 不要用了”

而且，就 tls 混淆原本的用途来说，tls 混淆只是为了突破部分地区的网络环境才有的 QoS 限制，一般情况下根本不需要使用
破娃酱也在文档里说的很明白，一切因使用混淆而产生的看似是网络加速了的效果都是因为绕过了限制，混淆实际上会减慢你的网络速度

并且，如果你并不明白http(s)协议的具体细节，没有这方面的计算机网络知识，那么也不要轻易使用http_simple之类的混淆；如果没有必要，也不要使用80和443端口；这些在 GFW 眼里很可能会成为一种明显的特征，会成为“为什么我的VPS好好的就被Q了”的直接原因

加密这块到底是怎么回事
简单的来说，我们若干年前使用的非 AEAD 加密，都存在被主动探测到的风险（这一块如果感兴趣想了解，可以自行谷歌 AEAD 加密的相关科普博文）

因此，如果是酸酸，强烈推荐使用之前提到的那5种 AEAD 加密，为了防止今后（可能的）来自 GFW 的主动探测

而酸酸乳，虽然目前并没有使用到 AEAD 加密，但是破娃酱在设计协议的时候已经考虑到了主动探测问题并且针对这块进行了设计，因此目前来说还是相对安全的，前提是你使用的是chain_a或auth_aes128_md5或auth_aes128_sha1协议

对于酸酸乳，chain_a是目前最佳的协议；chain_b虽然说更难以被识别，但是仍是一个测试版协议，并且实际使用发现丢包现象莫名十分严重，并不能用；至于酸酸乳乳那些chain_c/d/e/f，可以看看这里

之前提到的推荐配置中，酸酸乳的加密为none的原因是，auth_chain系列协议已经自带了RC4加密，针对 UDP 部分也有加密及长度混淆，因此一般情况下不需要再进行额外的加密；如果你觉得RC4加密有安全隐患，再套一层其他加密也可。

总结：结合Shadowssock客户端，PC、cellphone都可以很愉快的在互联网上翱翔，多种模式，配置灵活。