SSR：事实上的废案，废案上的事实
酸酸乳是什么
答：
国际机场提供的清凉饮料,具有某种神奇力量的道具
使用后的114秒内，滑翔时的移动速度提高514%
前言
在2023年写这篇博文似乎还是有些为时过晚了，毕竟如果你问『翻墙娱乐圈』的人，目前什么协议比较好，清一色回答几乎都是『不要用SS/SSR，用最新的VLESS+gRPC+Reality......』什么的，似乎使用SS和SSR在目前已经成为了某种怪异的事情一样
但是问题是，SS倒好说，毕竟一直都还在开发，有热心开发者持续跟进改进，以及我现在能更新这篇博文也是靠了SS的力量。
但是SSR呢？SSR在至少四五年之前就已经不是自建协议的主流选择，在两三年之前也基本很少在自建中使用了。但是，如果你购买成品节点，你会发现相当一部分（尤其是连续做了几年）的机场依然选择使用SSR来提供服务。难道正如网上的人所说，是鸡场老板不知道安全的重要性，亦或者是他手头的IP多到可以随便拿来挥霍吗？
笔者感觉，应该都不是
SSR之殇
SSR的诞生，出现在SS的作者被迫放弃开发之后，另一位开发者主导起来的项目。至于SSR和SS之间的爱恨情仇，以及SSR作者的人品问题，以及到最后的被开盒事件，在这里就不多谈了，因为我们主要是谈技术，不想陷入到纠纷中。
和前端娱乐圈一样，这个娱乐圈里面同样充满了撕逼。就笔者记得的有：
- SS作者被请喝茶
- SSR作者违反开源协议
- SSR作者『被』开盒
- RixCloud等『高端机场』也跑路
- XTLS原因导致V2Ray分家（分成了现在的V2Fly和Xray）
- RPRX的Trojan-Killer的发布
- CFW删库，Clash删库，ClashVerge停止开发，TUIC删库
混淆和协议
SSR采用在原版SS上添加混淆和协议层的方式来实现，各个混淆协议都有其特点，但是其基本思路和目前的V2Ray传输协议什么的没有太大差别：都是利用分层的方法，让外层的协议消除掉里面的主协议的特征。当然，虽然说V2支持最基本的HTTP混淆，但是也不推荐使用（唯一一个用途可能大家已经想到了：免流）。
这个外加的混淆和协议层，具体能不能实现抗封锁，其实有待商榷。一方面，他致力于把SS数据流伪装为HTTP和TLS握手包等互联网上常见的协议，这个做法在某些地方已经观察到了欺骗运营商QoS设备的情况（说人话就是，直观感受到加了混淆之后『快了』）；但是另一方面，不论是最开始的http_simple等混淆，还是说后期的auth_chain_*系列协议，他们的重点都在于模仿，但是模仿总会有模仿地不像的地方，有可能成为一个强特征，导致流量可以被精确切断。
到了相对后期的一段时间内，很多SSR教程都推荐把混淆设置为plain，把协议设置为auth_chain_a/b/c，或者干脆设置为Origin。但是笔者不确定这些文章是不是都是抄来抄去的，因为plain+origin就已经是原版的SS了，此时还称呼为SSR已经意义不大了。
说到这个，这就不得不提到SSR的另一个问题：无校验的流加密
无校验的流加密
就目前而言，不管是以前已经停止开发的SSR各客户端，还是说后期的Clash（似乎sing－box是个例外），他们在SSR选项中实现的加密方式依然是无校验的那几个，比如RC4(-MD5)，AES系的CFB/CTR，纯Chacha20等，因此这就给针对SS的主动探测等留下了空间。
虽然说，正确配置的混淆协议可能可以规避这个问题，但是当时有多少人懂得什么是正确配置呢？大多数都是跟着网上的教程，或者直接用一键脚本，乱配一通，通了就通了，别的安全措施就视若无物。
事实的另一方面
SSR到目前来看，缺点很多，似乎应该消失了才对。但是近来的软件（包括V2系，Clash系等）的issues区里面，总会有人询问能不能提供SSR协议。问起她们原因来，基本上都能得到一个回答：机场还在用SSR。
老实说，这是事实。当然近两年来似乎少很多了，更多的机场转向VMess等协议。但是为什么会有这么奇怪的情况，按道理，机场不应该是用的人更多，更应该选择那些抗封锁能力强的协议上嘛？
这就是事情变得有趣的地方：上面SSR之殇中提到的缺点，反而成为了优点
外加的协议层
先来看主流的协议有什么：SS, SSR, VMess, VLESS, Trojan
再来看机场的需求是什么：通过服务器给多人提供服务，并实现权限控制和计费
现在就可以分析各个协议的情况了。
- SS：SS一开始是作者开发来自己用的，因此并没有考虑到多用户区分和鉴权的问题，只要知道了密码谁都可以连接上。后来为了分销的需要，通常的一个做法是一个用户一个端口一个密码，用端口号作为账号。但是如果防火墙看到几千几万个TCP同时访问这个机器，而且端口还不一样的话.....我感觉不太妙
- SS单端口多用户：用是可以用的，但是毕竟这玩意是在原协议的基础上凑合出来的方法，它的基本原理是通过数据包提供的IV和服务器端本来存着的密码，轮流尝试对数据包进行验证，如果验证通过，那就是有效用户。很显然，这个方法相对来说比较吃资源，因此大机场使用的并不算多
- VMess：在数据包中插入了UUID，但是其协议（尤其是早期版本的协议）也非常吃资源，甚至当时还有鸡场老板宣称自己的机器被V2Ray吃光了资源
- Trojan、VLESS等：比较新，前两年也还没有
这个比较下来，SSR就成为了一个很合适的选择：有明文或别的字段，能够实现单端口多用户下快速判断用户身份，而且对资源的消耗量也不大（以混淆单端口为例，有些会采用外面混淆头的Host字段改成比较特殊的，能够关联到用户ID的字符串，就可以在不解密内部数据包的情况下快速判断用户身份）
无验证流加密：谁在乎呢
鸡场老板一般来说都是下了不少小聪明的，最基本的基本上都是全中转机场了。因为中转机是老板的，因此他可以上各种『更适合』过墙的协议，比如TLS隧道（而且此时单端口也比原版SS的多端口要方便得多），甚至有些能直接搞到专线（包括但不限于阿里云经典内网的Bug），接起来之后，里面跑什么协议都无伤大雅了，毕竟全都不过墙
有一些小机场的端口号乱七八糟，大概率是因为使用了NAT VPS或者租用别的端口转发服务商的线路
卖这些玩意的商家是怎么搞到机器的，具体谁也不会说。但是笔者和一位业内朋友交谈过，大概有一种方式是：机房内鬼。
比如，机房是正规机房，拉了1G的专线（一般是移动，便宜量大，广州移动拉香港CMI，被称为穷人版CN2），但是正常业务用不完的，剩下的一般是冗余什么的。某个内鬼偷偷匀出来100-200M，然后搞台机器卖小鸡或者端口转发，每个用户分20个端口....然后，又有一个NAT VPS商家出现在了网络上。就这样。
写在最后
本文很水，真的很水
但是笔者有时候就是想写点什么，即使是自娱自乐也好，也算是一个乐趣了
（完）
致 2025-06-29 14:08 您的评论的回复：
基于文章“Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes”（中文， 基于嵌套的TLS握手指纹识别混淆代理流量 ），握手包随机填充混淆对tls in tls检测的真阳性率影响有一些效果，而多路复用对tls in tls检测的准确性干扰效果最佳。
不过至今为止，还不确定22年底那次大规模封杀到底是tls in tls检测为主还是那个内鬼所说的AES指纹检测（移动端AES指纹）。
Reality这样的代理协议一方面是借用或者说透支了GFW对境外大厂白名单域名的信任，另一方面从悲观的角度，所有协议最终的结果都是被识别封锁，那么今朝有酒今朝醉，类似IPV6+wireguard协议的预期。
23年初Reality刚出来的时间点，弱点已经很明确，一家无名的VPS托管境外大厂的白名单域名，不管怎么说都是不合理，大厂域名本该7*24被来自全国各地的分布式流量访问而不是只在一部分时间被个别IP集中访问，引用V2EX.COM某个流量分析帖的回复，“境外节点，无名小站，莫名其妙的主页，多到吓人的加密流量”。即使是最粗略的ASN匹配+动态流量分析，很大一部分Reality节点在GFW的面前会暴露无疑。但GFW至今为止仍未行动，可能是人的因素是主导。
我有几个观点，提出来讨论一下：
1. 多路复用必然是个趋势，因为不论是以前的Shadowsocks还是Vmess还是后来的各种叠buff，其本质上还是『一条请求流对应一条加密流』，在远端看来你是在快速与某一个IP，某一个端口建立并断开连接（与之相反的是VPN/SSH，一条加密流内传输多条请求流），这就已经和正常上网（虽然同样是快速建立断开连接，但是目的IP是不同的）产生了非常大的差别
2. 关于22-10-3的事情，我倾向于认为是都有，甚至可能还包括某些需要『长时间去搜集流量，慢慢分析，减少误报』的方法在内，然后才做统一切断措施
3. 对于REALITY，我也在担心类似的问题，而且本质上我认为这个几年前流行的『WS+TLS+CDN』方案非常类似，都是依附的自由，套壳白名单去弄，很显然不是长久之计，审查者必然被迫研究更加精准的刀法，相当于目前就是双方都在烧血，看谁血条长——但问题是我作为一个旁观者，我不知道xray等作者内部在讨论什么（其实我也不想加入），我并不知道下一步在哪，或者说还有什么神奇的协议我不知道的能够从另一个角度去出发来缓解这个问题。此外，rprx在某个issues还是discussion里面提及，大致的意思是，『如果以后墙得只剩下白名单，对于这种借用信任的方式，你用还是不用。目前这个领域很多东西不能用常理来解释』。所以目前来看，我也不好妄下定论。
4. 关于v6+WireGuard，不确定您的意思是？因为我尝试过这个方案，似乎会比v4好一丁点，但是后来也没有继续实验下去（估计是传闻中说的v6墙低，但是怎么低，低多少，低多久，甚至到底低不低，都还是未知数）
5. 人为因素：可以说我是过分乐观，但是我目前还是在一定程度上认为，审查者的做法是『养肥了再割韭菜』，而不是刚出苗就割，所以目前可能还能苟着过（但是也不能排除第二点的说法，审查者等很久很久，让你以为生效了，才来一刀，复现一次22-10-3）。此外，对于这一方面，很多人长期的观念是『经商的人需要翻出去，搞科研的也要』，不过我个人认为这两个说法的效力正在减弱：前者的话，目前御三家运营商（包括某些已经通过信通院认证的，所谓的SD-WAN运营商，比如橙某网络，某卷科技，为了避免打广告嫌疑我在这里就不写全名了）都在推出白名单海外专线，开通了Office365，亚马逊，eBay等，供客户申请使用；至于后者，好一点的大学有自己的国际专线以及资源站什么的，普通一点的....可能才是上面这个长期观念的主要原因，但是我也不好说。
6. 最新补充：目前来看应付这种检测还有一个办法：MITM，自己提前卸载掉SSL再发送内层数据。通用性可能会差很多，但是万一真到这种地步也不能不这样处理了
从2025现在这个时间点看，SSR确实是一个废弃的技术。但是十年前，这是最早提供强特征伪装成HTTP流量的协议，是未来十年伪装流量的鼻祖。SS主打的是无特征流量，后来我们都知道，全加密流量的特征识别技术大规模启用后，SS无了。SSR比SS更糟糕的一点在于作者断更后并没有人接手更新，导致SSR在2017的伪装放在日后反而成为了一个强特征。TLS 1.3是2018出的，恰好。
后来的v2ray/trojan都是伪装成合法https流量，同样也有不少问题，最典型的是和SS一样的重放攻击。2022年底的TLS IN TLS检测，trojan-go 2021停止更新。
2022-2025出了shadowTLS/reality/...多个SNI伪造的协议，但实际上几乎只有xray作为社区的体量够大保持更新。Vision作为流量时序控制确实不错，一个更好的选择可能是多路复用，彻底处理掉内层流量握手包识别问题（之前的握手包填充作为临时过渡期的缓解方案）。
十多年的协议发展史总结的教训，不存在完美的协议，任何协议都会被识别，区别在于识别封杀的代价（阳性率和假阳性）和时间点。
基本上我还是比较认同那个观点：如果某个作者两天写出来的简单协议，需要对抗者花费半年时间才成功封锁，那么确实不能认为这个协议一无是处，因为投入产出比就摆在这。说到底，SSR基本上就是这个状态，目前他少人用，只是因为已经完成了自己的历史使命而已。
另外目前社区里面的想法确实和您说的差不多，用一个翻译得比较生硬的名词来说就是『依附的自由』（Collateral freedom，以前这个词语通常被用于形容域前置），但是我有点担心会不会出现一种新趋势，也就是，对抗者分析各大热门网站普遍出现的节点列表，对于不在这个列表里面的（可能是REALITY借道的）就严格检查——不过说到底，还是回到了上面提到的『两天对半个月』问题，只能看社区怎么解决了
吓得我开始尝试迁出机场并自建代理。
此外备案彩蛋挺有趣。
其实机场并不是什么要不得的东西，注意正确使用方式其实问题不大（比如，用作链式代理入口端就挺好的）
我用过的两个机场都是ss协议，一个一元机场混淆直接没开，另一个机场好歹开了混淆。
其实这种拿出来卖的代理工具，目的性很强。基本就是怎么便宜怎么来，主打能用就行，安全性和匿名性基本无。
所以我很不喜欢有人把VPN和你说的酸酸乳混为一谈，完全就是两个东西。
如果真想追求安全性的话就是自建代理或者VPN，把安全掌握在自己手中。还有一种就是用国外厂家的VPN，但后多情况被针对了，因为前面说的有可能是蜜罐或者容易被渗透，但国外是真VPN，被针对也很正常。目前方案可以前置代理再套国外的VPN，套一下娃。
因为在一定程度下，安全是会牺牲一定的成本和便利性的，没有例外，要有也是坑。
确实还是这样的，很显然的是，很多这类小代理都是国人商家开的，他们基本上就是为了能够动起来，至于什么ToS什么隐私保护，基本上是没有办法的（更何况的是这种代理协议基本上没有经过评审什么的，也不一定会保证密码学意义上的安全性）