tech/protocol · 集群 A · 主流协议原理 · 5/6

Shadowsocks 原理详解：AEAD 加密、SS2022 改进与轻量代理的取舍

Shadowsocks 的设计哲学

Shadowsocks 的设计哲学是「足够简单」：双方事先共享一个密钥，客户端把目标地址和数据一起加密发出，服务端解密后代为访问。没有证书、没有协商、没有多余的协议字段，这使它成为实现最广泛、开销最低的代理协议之一。

与 TLS 类协议相比，它最大的结构差异在于没有握手阶段。TLS 需要先交换 ClientHello、ServerHello、证书，再开始传输应用数据；Shadowsocks 发出的第一个包里就已经是密文。

TLS 类协议                     Shadowsocks
客户端 ── ClientHello ──▶      客户端 ── [盐 | 加密的地址头 + 数据] ──▶
      ◀── ServerHello ──             ◀── [盐 | 加密的响应数据] ──
      ── 握手完成 ──▶
      ══ 加密应用数据 ══

数据包里有什么

一个 Shadowsocks（AEAD 版本）TCP 连接的起始部分，由随机盐、加密的地址头和加密的数据块组成。地址头沿用了 SOCKS5 的风格：一个字节的地址类型，后接 IPv4、IPv6 或域名，再加端口。

这种结构保证了每条连接使用不同的会话密钥，即使主密钥相同，两条连接的密文也不会相同。每个数据块附带的认证标签，确保被篡改的数据会被直接丢弃。UDP 的处理方式类似，只是每个数据报独立加密。

从流加密到 AEAD

Shadowsocks 的加密方式经历过一次重要演进：从早期的流加密（stream cipher）转向 AEAD（带认证的加密）。这次演进的原因很直接：流加密只提供机密性，不提供完整性校验，数据被篡改时服务端无法识别，理论上存在被利用的空间。

AEAD 同时提供加密与认证，被篡改的密文在解密时会校验失败。现行推荐的套件包括：

如果你在订阅里看到旧式流加密方式，可以向服务商询问是否有 AEAD 或 SS2022 节点可选。

SS2022 改进了什么

SS2022（Shadowsocks 2022 版本）是在 AEAD 版本基础上的一次较大改进，重点解决重放与密钥强度问题。它的主要变化包括：

• 头部加入时间戳，服务端拒绝时间偏差过大的请求，配合盐值记录实现重放保护；
• 密钥必须是固定长度、Base64 编码的随机字节，不再接受任意口令字符串，避免弱口令；
• 头部结构调整，响应中包含请求盐的信息，使请求与响应能互相绑定。

时间戳的引入意味着 SS2022 与 VMess 一样，对设备时间有一定要求，时间偏差过大时可能连接失败，排查时应先确认系统时间是否开启自动同步，参考 故障排查。SS2022 与旧版不能直接互通，客户端需要支持 SS2022 的较新版本，mihomo、sing-box 等内核已支持，原版 Clash 内核的支持情况以其版本说明为准。

插件机制与传输扩展

Shadowsocks 本身只定义了加密与地址格式，传输层的扩展通过 SIP003 插件接口实现。插件运行在 Shadowsocks 与网络之间，可以把流量封装成其他形态，例如基于 WebSocket、基于 TLS 或简单的 HTTP 外观封装。

应用 → Shadowsocks 客户端 → 插件（封装）→ 网络 → 插件（解封装）→ SS 服务端

插件需要客户端与服务端成对使用，订阅中通常以 plugin 和 plugin-opts 字段出现。客户端对插件的支持差异较大，导入后无法连接时，应先确认客户端是否支持该插件。插件是部署层面的选择，本站不讨论针对任何网络管理系统的使用方法。

优势、局限与适用场景

Shadowsocks 的优势在于简单与兼容：几乎所有代理客户端都支持，资源占用低，在路由器等性能有限的设备上也能运行，适合作为通用兜底协议，相关场景可参考 路由器方案。

它的局限在于缺少证书体系：客户端无法像 TLS 那样通过证书确认服务端身份，安全前提完全依赖预共享密钥不泄露。此外，没有握手阶段的「全密文」流量，本身也是一种特征，协议识别领域对此有专门研究，可参考 协议识别的原理。

本站品牌库中，没有品牌资料标注 Shadowsocks；资料标注协议的品牌均为 VLESS，微风网络、飞猫云、星岛梦、灵猫网络、极连云五个品牌协议待核实，本站不推测其协议。实际节点协议以订阅内容为准。

订阅中的 Shadowsocks 字段怎么读

在机场订阅里，一个 Shadowsocks 节点通常只包含寥寥几个字段：服务器地址、端口、加密方式（cipher 或 method）、密码（password），以及可选的插件字段。字段少是它的优点，但也意味着任何一项不一致都会直接导致连接失败，而且失败时几乎没有可读的错误提示。

排查 Shadowsocks 节点问题时，可以按以下顺序核对：加密方式是否为客户端支持的套件，尤其是 SS2022 系列需要较新版本；密码是否完整，SS2022 的 Base64 密钥对长度有严格要求，复制时少一个字符就会失败；是否带有插件字段而客户端未安装对应插件；最后才考虑线路与节点状态。

如果是通过 ss:// 分享链接导入，链接内的加密方式与密码通常经过 Base64 编码，手动编辑容易出错，建议直接通过订阅更新获取配置，相关格式差异见 订阅管理 专题。

小结

Shadowsocks 用预共享密钥换来了没有握手的简洁结构，AEAD 解决了完整性问题，SS2022 进一步补上了重放保护与密钥强度。理解它，有助于理解为什么后来的协议会转向「借用 TLS」的思路：两种路线各有取舍，而不是简单的新旧替代。

想对比其他协议的设计思路，可以回到 代理协议 专题总览；查看品牌协议资料，可前往 机场品牌库 或 对比工具。