SSR 是什么？ShadowsocksR 的来历与现状

梯子岛编辑部 · 更新于 2026-10-09

协议经典协议难度：进阶约 8 分钟读完

先说结论

SSR 协议即 ShadowsocksR，在 Shadowsocks 的加密方式之外多了 protocol 与 obfs 两项设置。它的原作者说明和规范文档在公开页面上找不到，是否可用先看你的内核文档。

ShadowsocksR 资料卡核验于 2026-10-09

来历: 能打开的资料是 GitHub 仓库 shadowsocksr-backup/shadowsocksr（描述为 Python port of ShadowsocksR，Apache-2.0）。其 README 沿用 Shadowsocks 的项目说明，版权行署名 clowwindy（2015），Wiki 链接指向 breakwa11/shadowsocks-rss；manyuser 分支提交记录中有作者 breakwa11 的提交，最晚为 2017-07-27。同组织还有 shadowsocksr-libev、shadowsocksr-csharp、shadowsocksr-android、ShadowsocksX-NG 等仓库。
传输与加密: 不使用 TLS。配置含 cipher、protocol（如 auth_aes128_md5）、obfs（如 tls1.2_ticket_auth），另有 protocol-param、obfs-param；规范文档未能打开。
官方文档写明支持的内核: Mihomo、shadowsocksr（Python）、shadowsocksr-libev、shadowsocksr-csharp、shadowsocksr-android、ShadowsocksX-NG

站内收录的客户端里，文档写明支持 SSR 的

完整对照见协议 × 客户端支持矩阵。

shadowsocksr-backup/shadowsocksr 仓库 shadowsocksr-backup 组织页 shadowsocksrr/shadowsocksr 仓库 Mihomo 文档：ShadowsocksR

这张卡片的资料来源（9 条）

仓库描述为 Python port of ShadowsocksR；README 含 -m/-O/-o 示例命令、Copyright 2015 clowwindy、Apache-2.0、Wiki 链接指向 breakwa11/shadowsocks-rss、客户端列表（raw.githubusercontent.com）
manyuser 分支提交记录：作者 breakwa11 的提交最晚 2017-07-27，之后 2017-08-18 有 KeJunMao 的 PR 与备份账号的合并提交（github.com）
master 分支最近一次提交为 2015-11-02（github.com）
shadowsocksr-backup 组织下的仓库：shadowsocksr、shadowsocksr-libev、shadowsocksr-csharp、shadowsocksr-android、shadowsocks-rss、ShadowsocksX-NG（github.com）
shadowsocksrr/shadowsocksr 页面标注 fork 自 shadowsocksr-rm/shadowsocksr，默认分支 manyuser（github.com）
shadowsocksrr/shadowsocksr 的 manyuser 分支最近一次提交为 2017-07-27（github.com）
Mihomo 文档列有 ShadowsocksR 代理类型及 cipher/obfs/protocol 等字段（wiki.metacubex.one）
sing-box 出站类型列表中没有 ShadowsocksR（sing-box.sagernet.org）
Xray 出站协议列表中没有 ShadowsocksR（xtls.github.io）

本文要点

SSR 协议是什么：在 Shadowsocks 之外多了两项设置
能核实的来历：仓库、署名和提交记录
读仓库页的方法：最近提交说明了什么，没说明什么
现在的内核还认不认 SSR：先看文档里有没有这个类型
旧教程里 SSR 的说法，哪些容易过时
拿到 ShadowsocksR 节点后，怎么自己核对
下一步该去哪

SSR 协议指的是 ShadowsocksR，一个在 Shadowsocks 的加密方式之外，又增加了协议（protocol）和混淆（obfs）两项设置的分支。旧教程里关于 SSR 的说法，需要拿现在还能打开的资料重新核对。梯子岛能核实的只有 GitHub 仓库和第三方内核文档，所以本文只讲这些资料能支撑的来历与现状，不评价任何使用 SSR 的具体服务，没有查到的部分会直接写“资料待核实”。

SSR 协议是什么：在 Shadowsocks 之外多了两项设置

能打开的主要资料是 GitHub 上的 shadowsocksr-backup/shadowsocksr 仓库，仓库描述是 Python port of ShadowsocksR，许可证为 Apache-2.0。它的 README 沿用了 Shadowsocks 的项目说明和版权署名，在此基础上，服务端示例命令里同时出现了三类参数：加密方式、协议、混淆。Shadowsocks 本身的原理见 Shadowsocks 是什么，下面只讲 SSR 多出来的部分。

设置项	含义或资料里的例子	在资料里怎么出现
cipher	加密方式	README 示例命令的 -m 参数；Mihomo 文档的 cipher 字段
protocol	auth_aes128_md5	README 示例命令的 -O 参数；Mihomo 文档的 protocol、protocol-param 字段
obfs	tls1.2_ticket_auth	README 示例命令的 -o 参数；Mihomo 文档的 obfs、obfs-param 字段
udp	可选	Mihomo 文档里的可选字段

SSR 不使用 TLS。protocol 和 obfs 内部分别做了什么，梯子岛没有找到可以引用的规范文档，这部分资料待核实，所以不在这里解释机制，也不对它们的效果做任何判断。你只需要知道：看到 ssr节点里带着这两项和它们的参数，就说明这是 ShadowsocksR，不是 Shadowsocks，导入时必须选对类型。

能核实的来历：仓库、署名和提交记录

下表只列公开页面上看得到的内容，查看日期是 2026 年 10 月 9 日：

资料	能看到什么
shadowsocksr-backup 组织	下面有 shadowsocksr、shadowsocksr-libev、shadowsocksr-csharp、shadowsocksr-android、ShadowsocksX-NG 等仓库，见组织页
shadowsocksr-backup/shadowsocksr	manyuser 分支里署名 breakwa11 的提交，最晚在 2017 年；之后还有一次合并请求和备份账号的合并提交；默认分支 master 的最近提交在 2015 年；页面未见归档标记
shadowsocksrr/shadowsocksr	页面标注 fork 自 shadowsocksr-rm/shadowsocksr，默认分支 manyuser，最近一次提交在 2017 年，见仓库页

README 里的 Wiki 链接指向 breakwa11 名下的 shadowsocks-rss，README 的克隆地址指向另一个 shadowsocksr 仓库，梯子岛查看时这几个地址都打不开，所以本文没有引用它们。原作者的官方说明、协议规范文档和首发时间，同样没有找到官方页面，资料待核实。

读仓库页的方法：最近提交说明了什么，没说明什么

上面这些提交时间只是仓库状态，不是“能不能用”的结论。自己看一个仓库是否还有人维护，可以按下面几步：

先看默认分支是哪一个，再看它的最近提交，而不是只看首页顶部的数字。
看页面有没有“Archived”之类的归档标记。没有归档标记，不等于仍在维护。
看 README 里的链接还能不能打开，打不开说明原始说明已经丢失。
看同一名字下是否有多个仓库、哪个是 fork，因为你下载到的可能不是你以为的那一个。
看发布页是否提供构建好的安装包，没有的话要自己编译，门槛会高很多。

按这几步看，SSR 协议相关的仓库给出的信息是：有多个同名仓库，最近提交都停在多年前，原始说明页打不开。这些事实该怎么权衡，由你自己决定，梯子岛不替你判断。

现在的内核还认不认 SSR：先看文档里有没有这个类型

内核	文档里的情况	说明
Mihomo	文档列有 ShadowsocksR 代理类型	字段有 cipher、password、obfs、protocol、obfs-param、protocol-param，可选 udp
sing-box	出站类型列表中没有 ShadowsocksR	以官方文档的出站列表为准
Xray-core	出站协议列表中没有 ShadowsocksR	以官方文档的出站协议列表为准

Mihomo 的字段写法可以在 Mihomo 文档：ShadowsocksR 里查到。这张表只说明“内核文档里有没有”，不等于“用这个内核的客户端有没有界面入口”。具体某款客户端能不能处理 SSR，去协议支持矩阵查；客户端和内核的关系，看各自的档案页。

旧教程里 SSR 的说法，哪些容易过时

旧教程里常见的说法	为什么要重新核对	怎么核对
附带的 Wiki 或仓库链接	梯子岛查看时，几个关键地址已经打不开	点开链接，看是否还能访问
“用哪个客户端都支持 SSR”	内核文档的情况不一：Mihomo 有，sing-box 与 Xray 的出站列表没有	查矩阵和内核文档
“SS 和 SSR 差不多，随便选”	配置项不同，SSR 多了 protocol 与 obfs 及其参数	看节点类型和字段
“某仓库就是官方”	同名仓库不止一个，资料里没有官方声明指定哪一个	看仓库页的 fork 标注与提交记录

这几行并不意味着“SSR 协议不能用”，只说明旧教程不能直接照搬。如果你想先从整体上理解各个协议的位置，读代理协议怎么选，以及协议总览页代理协议资料里的其他条目。

拿到 ShadowsocksR 节点后，怎么自己核对

看节点类型：是 ShadowsocksR 还是 Shadowsocks。拿到一串链接想拆开看，可以用节点解析，每段含义见节点链接怎么读。
看字段：有没有 protocol、obfs 以及它们的参数，缺任何一项都先别急着导入。
查你客户端所用内核的文档里有没有对应类型，结合上一节的表。
客户端不支持时，不要去找来路不明的“修改版”，风险见破解版梯子软件能用吗；可以回到节点提供方确认是否有别的协议可选。
能连上之后，用 IP 与 DNS 检测里的工具核对出口和 DNS 走向。梯子岛只教方法，不提供检测结果。

下一步该去哪

想先弄清 Shadowsocks 本身：读 Shadowsocks 是什么。
想知道某个客户端能不能处理 SSR：查协议支持矩阵。
想按场景重新选协议：读代理协议怎么选。
想亲自看仓库状态：在 GitHub 仓库导航里找到入口，按上文那几步检查。

SSR 的资料有缺口，这不是缺点也不是优点，只是事实。有缺口的地方，就用你自己的核对补上。

这篇没有覆盖的

本文不提供任何测速或解锁测试结果，也不评价任何使用 SSR 的具体服务。
协议规范、原作者的官方说明和首发时间没有找到官方页面，这些资料待核实，本文不下结论。
仓库状态会变化，文中提到的提交时间只到年份，请以仓库页面实际显示为准。

本文引用的官方来源

shadowsocksr-backup/shadowsocksr 仓库（github.com）
shadowsocksr-backup 组织页（github.com）
shadowsocksrr/shadowsocksr 仓库（github.com）
Mihomo 文档：ShadowsocksR（wiki.metacubex.one）

以上链接均为官方页面，梯子岛在 2026-10-09 核对过；个别网站会拦截自动化访问，用浏览器直接打开即可。平台规则可能随时调整，以官方页面当前内容为准。

SSR 协议常见问题

SSR 是什么？

SSR 是 ShadowsocksR 的简称。从公开仓库看，它的 README 沿用了 Shadowsocks 的项目说明，并在加密方式之外增加了 protocol（协议）和 obfs（混淆）两项设置，有 Python、libev、C#、Android 等多种实现。

SSR 和 Shadowsocks 有什么区别？

配置上最直观的区别是多了两项：protocol 和 obfs，各自还有 protocol-param、obfs-param 两个参数。Shadowsocks 本身的资料见官方站点，SSR 的协议规范文档梯子岛没有找到官方页面，机制细节资料待核实，所以不在此解释内部原理。

SSR 现在还能用吗？

要分两层看。内核层面，Mihomo 的文档仍然列有 ShadowsocksR 类型，而 sing-box 与 Xray 的出站文档列表里没有它。仓库层面，最近的提交停在多年前，页面未见归档标记。能不能用取决于你的客户端用的内核，请先查协议支持矩阵。

为什么旧教程里的 SSR 链接打不开？

梯子岛查看时发现，仓库 README 的 Wiki 链接所指向的 breakwa11 名下仓库，以及 README 里写的克隆地址，打开都是 404。引用这些地址的旧教程，读者无法回到原始说明，所以文中的参数写法建议对照现在仍能打开的文档再确认。

ssr节点导入失败怎么办？

先确认节点类型确实是 ShadowsocksR 而不是 Shadowsocks，再看字段里是否有 protocol 和 obfs，最后查你的客户端所用内核是否支持 ssr 类型。如果内核不支持，不要去找来路不明的修改版客户端，可以回到节点提供方确认有没有其他协议可选。

接着读

文中出现的术语

接下来去哪儿？

找官方入口去网址导航，想核对仓库和版本看GitHub 项目导航；需要现成的机场，机场目录收了 28 家的价格与线路资料，性价比机场、便宜机场、VPN 机场分别有专项页。