ShadowsocksR (SSR)

项目状态: ❌ 已淘汰 | 推荐度: ❌ | 世代: 第三代 | 警告: 不推荐使用

⚠️ 重要警告

ShadowsocksR 已经完全过时且存在安全争议，强烈不建议使用。

本文档仅供历史研究和技术学习参考。

快速概览

ShadowsocksR（简称 SSR）是 Shadowsocks 的一个分支，由 breakwa11 于 2015 年创建。它在 Shadowsocks 基础上增加了协议混淆和插件功能，曾在 2015-2018 年间流行，但最终因技术争议、安全问题和 GFW 识别而被淘汰。

核心特性

🔄 协议插件: auth_chain_a/b 等认证链
🎭 混淆插件: http_simple, tls1.2_ticket_auth 等
📝 兼容 SS: 可使用 SS 的配置
⚠️ 安全争议: 代码质量受质疑

关键指标

指标	评分	说明
性能	⭐⭐⭐⭐	性能尚可
安全性	⭐⭐	存在安全争议
稳定性	⭐⭐	维护混乱
隐蔽性	⭐⭐	已被 GFW 识别
易用性	⭐⭐⭐⭐	配置简单
文档	⭐⭐⭐	文档不完善
社区	⭐⭐	社区分裂

历史背景

诞生（2015 年）

背景:

Shadowsocks 作者 clowwindy 被约谈
Shadowsocks 已有被识别的迹象
需要更强的混淆能力

创建者: breakwa11

目标: 增强 Shadowsocks 的抗检测能力

争议（2015-2017）

技术争议

代码质量
- 原 SS 社区认为 SSR 代码质量差
- 混淆实现被指不专业
- 缺乏严格的安全审计
协议设计
- 协议复杂度增加
- 向后兼容性问题
- 性能开销
维护问题
- breakwa11 与社区关系紧张
- 文档不完善
- 缺乏测试

社区分裂

Shadowsocks 社区
      ↓
  （2015 年分裂）
      ↓
  ├─→ Shadowsocks (原版社区)
  └─→ ShadowsocksR (breakwa11)

影响:

用户困惑，不知道选哪个
开发力量分散
相互攻击和指责

衰落（2017-2018）

2017 年 7 月: breakwa11 宣布停止开发

删除 GitHub 仓库
停止维护
留下多个社区分叉版本

2018 年: GFW 开始识别 SSR

协议混淆被破解
大量服务器被封
用户转向 V2Ray、Trojan

当前: 完全过时

不推荐任何场景使用
仅作历史研究

技术原理

SSR vs SS 的区别

特性	Shadowsocks	ShadowsocksR
协议	原版协议	增加协议插件
混淆	无	增加混淆插件
复杂度	简单	复杂
性能	优秀	稍差
安全性	相对可靠	存在争议

协议插件（Protocol）

作用: 在原 SS 协议外再套一层认证

常用协议:

origin: 原版协议，与 SS 兼容
verify_sha1: 简单校验
auth_sha1_v4: SHA1 认证
auth_aes128_md5: AES128 认证
auth_aes128_sha1: AES128 + SHA1
auth_chain_a: 认证链 A
auth_chain_b: 认证链 B（最复杂）

auth_chain 特点:

动态密钥
可变长度数据包
模拟随机流量
抗重放攻击

混淆插件（Obfuscator）

作用: 将流量伪装成其他协议

常用混淆:

plain: 无混淆
http_simple: 伪装成 HTTP GET 请求
http_post: 伪装成 HTTP POST 请求
random_head: 随机头部
tls1.2_ticket_auth: 伪装成 TLS 1.2 握手

tls1.2_ticket_auth 原理:

客户端:
  构造假的 TLS ClientHello
      ↓
  包含 Session Ticket
      ↓
  看起来像正常 TLS 握手

服务端:
  验证 Ticket（实际是密码）
      ↓
  验证通过才建立连接

为什么被淘汰

1. 安全问题

代码质量争议:

未经充分安全审计
存在潜在漏洞
加密实现不规范

具体问题:

部分混淆可被识别
协议设计有缺陷
重放攻击防护不完善

2. 技术被破解

GFW 的识别方法:

1. 流量特征分析
   - SSR 的混淆模式固定
   - 可通过机器学习识别

2. 主动探测
   - 发送畸形数据包
   - 观察服务器响应
   - SSR 响应模式特殊

3. 协议指纹
   - auth_chain 的特征
   - tls 混淆的瑕疵

3. 维护混乱

原作者停止维护
多个分叉版本，质量参差不齐
没有统一的开发方向
文档和支持缺失

4. 更好的替代方案

2017-2018 年新工具出现:

V2Ray:
  - 更完善的协议设计
  - 活跃的开发
  - 强大的功能

Trojan:
  - 更彻底的伪装
  - 简洁的设计
  - 稳定的维护

配置示例（仅供参考）

服务端配置

json

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "password": "password",
  "timeout": 300,
  "method": "chacha20-ietf",
  "protocol": "auth_chain_a",
  "protocol_param": "",
  "obfs": "tls1.2_ticket_auth",
  "obfs_param": ""
}

客户端配置

json

{
  "server": "server-ip",
  "server_port": 8388,
  "local_address": "127.0.0.1",
  "local_port": 1080,
  "password": "password",
  "timeout": 300,
  "method": "chacha20-ietf",
  "protocol": "auth_chain_a",
  "protocol_param": "",
  "obfs": "tls1.2_ticket_auth",
  "obfs_param": ""
}

参数说明

参数	说明	推荐值
method	加密方法	chacha20-ietf
protocol	协议插件	auth_chain_a/b
obfs	混淆插件	tls1.2_ticket_auth

技术争议回顾

SSR 支持者的观点

✅ 优点:

混淆能力确实更强
在一段时间内有效
填补了 SS 被识别的空白

SSR 反对者的观点

❌ 缺点:

代码质量堪忧
过度设计，复杂度不必要
安全性未经验证
分裂社区

客观评价

历史意义:

证明了混淆的重要性
推动了代理工具的发展
但实现方式有问题

技术价值:

协议混淆的思路是对的
但具体实现不够专业
最终被更好的方案取代

为什么不应该使用 SSR

1. 安全风险

已知问题:
  - 代码未经严格审计
  - 可能存在后门（争议）
  - 协议漏洞

2. 无法绕过 GFW

2024 年现状:
  - SSR 已被 GFW 完全识别
  - 使用 SSR = 暴露自己
  - 基本无法连接

3. 维护停滞

风险:
  - 无安全更新
  - 无 bug 修复
  - 兼容性问题

4. 有更好选择

推荐替代:
  - Xray (Reality)
  - Trojan
  - Hysteria 2
  - NaiveProxy

迁移建议

如果你还在使用 SSR，立即迁移到现代工具：

迁移路径

SSR 用户
    ↓
第一选择: Xray Reality
    - 性能更好
    - 完全兼容
    - 活跃维护

第二选择: Trojan
    - 配置简单
    - 稳定可靠
    - 隐蔽性强

第三选择: Hysteria 2
    - 移动网络优秀
    - 现代协议

迁移步骤

选择新工具（推荐 Xray）
部署新服务器（不要复用旧 IP）
配置客户端
测试连接
关闭 SSR 服务

历史教训

1. 代码质量的重要性

SSR 的问题:
  - 缺乏代码审查
  - 没有测试覆盖
  - 安全性未验证

教训:
  - 安全工具必须经过严格审计
  - 开源不等于安全
  - 需要专业的密码学知识

2. 社区协作的重要性

SSR 的问题:
  - 一人开发，缺乏监督
  - 与社区对立
  - 最终孤立无援

教训:
  - 开源项目需要社区协作
  - 技术争议应理性讨论
  - 分裂对所有人不利

3. 技术演进的必然性

SSR 的局限:
  - 混淆终会被破解
  - 协议需要持续演进
  - 一劳永逸不存在

教训:
  - 代理工具是攻防对抗
  - 需要不断创新
  - 及时淘汰旧技术

与现代工具对比

SSR vs Xray Reality

维度	SSR	Xray Reality
隐蔽性	⭐⭐ 已识别	⭐⭐⭐⭐⭐ 极强
安全性	⭐⭐ 争议	⭐⭐⭐⭐⭐ 可靠
性能	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
维护	❌ 停止	✅ 活跃
推荐	❌	✅

SSR vs Trojan

维度	SSR	Trojan
伪装方式	协议混淆	完美 HTTPS
可用性	❌	✅
配置难度	⭐⭐⭐⭐	⭐⭐⭐⭐
稳定性	⭐⭐	⭐⭐⭐⭐⭐

技术遗产

虽然 SSR 本身已过时，但它的一些思想影响了后续工具：

1. 混淆的重要性

SSR 证明了流量混淆的价值，后续工具都加入了混淆功能。

2. 协议插件化

插件架构被 V2Ray、Xray 等框架采用和改进。

3. 多层防护

协议 + 混淆的双层防护思路被继承。

常见问题

Q: SSR 还能用吗？ A: 不能。已被 GFW 完全识别，强烈不推荐。

Q: SSR 比 SS 更好吗？ A: 历史上曾经是，现在都过时了。

Q: 如何迁移？ A: 部署 Xray、Trojan 等现代工具，不要复用旧 IP。

Q: SSR 的代码安全吗？ A: 存在争议，未经严格审计，有潜在风险。

Q: 为什么还有人用 SSR？ A: 可能是信息滞后，不了解现代工具。

参考资源

历史资料

迁移指南

总结

ShadowsocksR 是翻墙工具历史上的重要一页：

历史地位: ⭐⭐⭐

填补了 SS 被识别后的空白
证明了混淆的重要性
推动了技术发展

技术评价: ⭐⭐

代码质量有争议
安全性未经验证
最终被更好方案取代

当前价值: ❌

完全过时
已被识别
强烈不推荐使用

学习价值: ⭐⭐⭐⭐

了解代理工具演进
认识技术对抗本质
理解社区协作重要性

⚠️ 最后警告: 请不要使用 ShadowsocksR。如果你还在用，请立即迁移到 Xray、Trojan 等现代工具！

ShadowsocksR (SSR) ​

⚠️ 重要警告 ​

快速概览 ​

核心特性 ​

关键指标 ​

历史背景 ​

诞生（2015 年） ​

争议（2015-2017） ​

技术争议 ​

社区分裂 ​

衰落（2017-2018） ​

技术原理 ​

SSR vs SS 的区别 ​

协议插件（Protocol） ​

混淆插件（Obfuscator） ​

为什么被淘汰 ​

1. 安全问题 ​

2. 技术被破解 ​

3. 维护混乱 ​

4. 更好的替代方案 ​

配置示例（仅供参考） ​

服务端配置 ​

客户端配置 ​

参数说明 ​

技术争议回顾 ​

SSR 支持者的观点 ​

SSR 反对者的观点 ​

客观评价 ​

为什么不应该使用 SSR ​

1. 安全风险 ​

2. 无法绕过 GFW ​

3. 维护停滞 ​

4. 有更好选择 ​

迁移建议 ​

迁移路径 ​

迁移步骤 ​

历史教训 ​

1. 代码质量的重要性 ​

2. 社区协作的重要性 ​

3. 技术演进的必然性 ​

与现代工具对比 ​

SSR vs Xray Reality ​

SSR vs Trojan ​

技术遗产 ​

1. 混淆的重要性 ​

2. 协议插件化 ​

3. 多层防护 ​

常见问题 ​

参考资源 ​

历史资料 ​

迁移指南 ​

总结 ​