ShadowsocksR

ShadowsocksR(通常简写为 SSR)是 Shadowsocks 的一个社区分支,由开发者 breakwa11 于 2015 年前后发起。它在原版 Shadowsocks 的加密转发基础上,额外引入了可插拔的 协议(protocol) 与 混淆(obfs) 两层机制,目的是在加密之外进一步打乱流量的统计特征,让代理连接更难被深度包检测识别,从而在审查升级时获得更强的抗封锁能力。SSR 一度在中文社区极为流行,几乎成为某一时期翻墙的代名词,但因作者退出、代码仓库被删除以及相关争议,项目早已停止官方维护,如今更多作为历史节点与兼容性需求而被提及,新部署已很少首选。

背景与由来

SSR 诞生于 Shadowsocks 原作者停更、且网络审查手段日趋精细的时期。当时纯 Shadowsocks(尤其早期流式加密)在面对流量特征分析与主动探测时显得脆弱:固定的 IV 位置、缺乏完整性校验、可被统计的包长分布,都可能成为识别线索。breakwa11 在原版代码基础上做了较大改造,加入多种混淆与协议变换选项,试图通过改变包长、时序与首部外观等统计特征来规避识别。围绕 SSR 也发生过著名的作者突然退出、删除代码与镜像、社区分裂等事件,使其历史颇具争议性,也给后续的安全审计与可信度评估带来困难。

设计目标

• 增强抗封锁:在 SS 的加密之外再叠加协议与混淆层,打乱包长、时序、首部等可被指纹化的统计特征。
• 兼容 Shadowsocks:在特定配置(如 origin 协议 + plain 混淆)下可与原版互通,降低迁移成本。
• 灵活可选:协议与混淆均做成可切换的模块,用户可根据所处网络的封锁强度自由组合,以速度换隐蔽或反之。
• 沿用轻量内核:保留 SS 的单点自建、低开销特性,仅在外层增加可选处理。

工作原理:协议层与混淆层

SSR 的核心创新是在 Shadowsocks 的对称加密之上叠加两层可选处理,二者职责不同:

• obfs(混淆)层:负责改变流量的外观,使其在浅层观察下像常见协议。典型选项有 plain(不混淆)、http_simple(在流首部伪造一个看似普通的 HTTP GET 请求头)、http_post(伪造 POST)、tls1.2_ticket_auth(模拟 TLS 1.2 握手与会话票据的外观)等。例如 http_simple 让连接初始字节看起来像一次普通网页请求,tls1.2_ticket_auth 则让其像一次 TLS 握手。
• protocol(协议)层:负责会话认证、抗重放与包长扰动。典型选项有 origin、auth_sha1_v4、auth_aes128_md5、auth_aes128_sha1、auth_chain_a、auth_chain_b 等。auth_aes128 系列为每个连接生成基于 HMAC 的认证信息以防伪造与重放;auth_chain 系列则进一步引入随机化的数据长度变换,使每个数据包的尺寸更不规律,打散包长分布这一重要识别特征。

加密部分仍沿用 Shadowsocks 的对称密码,如 AES-128/256-CFB、ChaCha20、RC4-MD5 等流式算法(SSR 主要停留在流式加密时代,未广泛采用 SS 后来的 AEAD)。三层(加密 + 协议 + 混淆)叠加后,链路上的流量在长度、时序与首部外观上都被刻意打散,从而提高基于统计特征识别的难度。

传输特性

与 Shadowsocks 类似,SSR 支持 TCP 转发,并可对 UDP 做 relay(原生 UDP 或 UDP over TCP,视实现与配置而定),用于 DNS、游戏等。它本身不提供多路复用,也不使用真实 TLS——其 tls1.2_ticket_auth 等只是模仿 TLS 的外观,而非携带合法证书的真握手。这意味着面对能做协议一致性校验或主动探测的检测系统时,模拟式混淆存在被识破的风险:检测方可以检查这个看似 TLS 的连接是否真的能完成标准 TLS 交互,从而暴露伪装。这一根本局限,也是后来业界从模拟混淆转向真 TLS 方案的重要动因。

从抗封锁原理上看,SSR 的混淆与协议层针对的主要是被动检测——即在不干预连接的前提下,靠观察包长分布、首部字节、时序统计来判断流量类型。通过伪造 HTTP/TLS 外观与扰动包长,SSR 确实能让这类被动统计变得困难。但它对主动探测几乎没有防御:审查系统可以主动连上可疑端口,按它伪装的协议规则继续交互,观察服务器是否给出符合该协议的、自洽的响应;由于 SSR 只是模仿外观而无法真正完成一次合法的 HTTP/TLS 会话,这种探测往往能让其现形。理解这一被动可混、主动易露的特性,是把握 SSR 历史地位与其被淘汰原因的关键。

演进关系与对比

• 相对 Shadowsocks:SSR 多了协议与混淆两层,抗特征能力在当时更强,但配置更复杂、CPU 开销更大,且未跟进 AEAD。
• 相对采用真实 TLS 的方案(如 Trojan、VLESS+TLS、带 ws+tls 的 VMess):SSR 的混淆是模仿而非真握手,理论上更易被一致性检测与主动探测发现;后来主流方向逐步转向真 TLS 与 Reality 等更彻底的伪装。
• SSR 的部分思想(可插拔混淆/协议、包长扰动)对后续项目与插件设计有启发,但其整体技术路线已被认为相对过时。
• 相对 SS 的 SIP003 插件:SS 把混淆外置为独立插件,SSR 则内嵌在协议中;前者更模块化,后者更一体但耦合更紧。

实现、生态与现状

SSR 曾有 Python、libev(C) 等服务端实现,客户端覆盖 ShadowsocksR-Windows、ShadowsocksR-Android,以及部分聚合客户端(如早期 Clash 衍生版)的兼容支持。其分享链接以 ssr:// 形式存在,内含 base64 编码的服务器、端口、协议、混淆与各自参数。由于原项目停更、代码仓库历经删除与第三方镜像/分叉,其安全审计与持续更新都难以保证,部分分叉的可信度也存疑。今天新建代理已很少首选 SSR,它更多出现在老旧订阅、历史遗留服务端或需兼容旧节点的场景中。

适用与局限

SSR 适合需要与既有 SSR 服务端互通、或在特定历史时期通过协议/混淆组合规避较简单检测的场景。其局限十分明显:已停止维护、缺乏现代 AEAD 与真 TLS 支持、模拟式混淆抗主动探测能力有限、性能开销高于纯 SS,且历史上存在代码可信度与供应链争议。对新部署而言,业界普遍建议改用维护活跃、基于真实 TLS 或 Reality 的现代协议,SSR 主要作为加密代理技术演进史上的一个重要而具争议的分支被记录与了解。回望其兴衰,SSR 既体现了社区在审查压力下快速试错的活力,也暴露了模拟式混淆路线的天花板;它所留下的可插拔混淆思想、对包长扰动的重视,以及模仿不如做真的反面教训,都被后来的 Trojan、VLESS、Reality 等吸收消化,从而把整个领域推向了更稳健的真 TLS 时代。