Shadowsocks 2022

Shadowsocks 2022 是对经典 Shadowsocks 协议的一次彻底重构。它于 2022 年 5 月由 Shadowsocks-NET 组织提出，针对原版协议在安全设计上的已知缺陷进行了系统性修复，同时引入了更现代的加密标准和更严格的协议规范。

为什么需要 2022 版本

原版 Shadowsocks（即使使用 AEAD 加密）在协议设计层面存在若干问题：

无连接时间戳校验：服务端无法判断收到的数据包是否为重放攻击
无请求盐值（salt）唯一性验证：理论上可以通过重放已捕获的握手数据欺骗服务端
协议头部可被主动探测：攻击者可以构造特定数据包探测端口是否为 SS 服务
流量特征相对固定：AEAD 版本的握手头部长度固定，有利于 DPI 设备建立特征库

Shadowsocks 2022 在协议层面逐一解决了上述问题，使其成为目前安全性最高的 Shadowsocks 变体。

核心改进

固定长度的请求头加密

2022 版本的请求头使用固定大小的密文块，长度不再泄露目标地址信息的长度特征，提升了流量分析的难度。

时间戳校验

协议头部包含一个时间戳字段，服务端会拒绝时间偏差超过 30 秒的请求。这一设计有效防止了重放攻击——即使攻击者捕获了完整的握手数据，也无法在 30 秒后重新利用。

服务端盐值过滤（Replay Filter）

服务端会维护一个近期使用过的请求盐值列表，拒绝重复使用同一个盐值的请求。结合时间戳校验，使重放攻击在理论上极难实施。

更严格的头部验证

协议头部的验证逻辑更加严格，非法或格式错误的数据包会被直接丢弃，不会有任何明确的错误响应，这使得主动探测更加困难。

新的加密方式

2022 版本引入了专为该协议设计的加密方式：

加密方式	密钥长度	说明
`2022-blake3-aes-128-gcm`	128 位	性能最优，推荐在性能受限设备上使用
`2022-blake3-aes-256-gcm`	256 位	安全性更高，推荐作为首选
`2022-blake3-chacha20-poly1305`	256 位	适合无 AES 硬件加速的设备（移动端、低端路由器）

这三种方式均使用 BLAKE3 作为密钥派生函数（KDF），BLAKE3 是目前速度最快的密码学哈希函数之一，在性能和安全性上均优于原版 AEAD 方式所使用的 HKDF-SHA1。

BLAKE3 的优势

BLAKE3 相比 SHA-1（原版 SS 的 HKDF 基础）具有更强的抗碰撞性和更快的计算速度。在现代硬件上，BLAKE3 的吞吐量可以达到 SHA-1 的数倍。

工作原理

请求流程

客户端
  |
  | 1. 生成随机 salt（每次连接唯一）
  | 2. 使用 BLAKE3 从预共享密钥派生会话密钥
  | 3. 加密固定长度的请求头（含时间戳、目标地址）
  | 4. 加密请求体
  v
服务端
  |
  | 5. 验证 salt 唯一性
  | 6. 验证时间戳合法性（±30 秒）
  | 7. 解密请求头，获取目标地址
  | 8. 建立到目标的连接
  v
目标服务器

多用户支持（服务端多用户）

2022 版本支持在单个端口上配置多个用户，每个用户拥有独立的密钥。服务端通过对接收到的密文尝试不同密钥来判断请求归属，整个过程对连接者完全透明。

这一特性使得 Shadowsocks 2022 在多用户场景下无需部署多个实例，简化了运维复杂度。

与原版 Shadowsocks 的对比

对比维度	Shadowsocks（AEAD）	Shadowsocks 2022
加密方式	AEAD（HKDF-SHA1）	AEAD（BLAKE3）
时间戳校验	无	有（±30 秒）
重放攻击防护	无	有（盐值过滤）
主动探测抵抗	弱	较强
多用户支持	需多端口或插件	原生支持
协议头部长度	可变（泄露地址长度信息）	固定大小块
性能	高	高（与原版相当）
客户端支持	极广	较广（主流客户端均已支持）

优缺点

优点	缺点
修复了原版协议的所有已知安全漏洞	需要客户端和服务端均支持 2022 规范
抗重放攻击能力强	要求客户端和服务端时间同步（误差 ≤30 秒）
主动探测抵抗能力更好	协议生态相比原版 SS 尚不够广泛
原生多用户支持	不支持旧式混淆插件（obfs 等）
性能与原版相当	—
无需域名和 TLS 证书	—

适用场景

推荐使用 Shadowsocks 2022 的场景：

自建代理节点，需要兼顾安全性与客户端兼容性
需要在单端口上为多个用户提供服务
对原版 SS 的安全缺陷有顾虑，但又不需要 VLESS + Reality 级别的抗检测能力
机场服务商希望提供一个安全性更高的 SS 选项

不推荐单独依赖的场景：

网络审查极为严格的环境（此时应选择 VLESS + Reality 或 AnyTLS）
需要兼容不支持 2022 规范的老旧客户端

服务端部署参考

以下以 shadowsocks-rust 为例展示 Shadowsocks 2022 的配置。

安装 shadowsocks-rust

# 从 GitHub Releases 页面下载预编译二进制文件
# https://github.com/shadowsocks/shadowsocks-rust/releases

wget https://github.com/shadowsocks/shadowsocks-rust/releases/latest/download/shadowsocks-v1.x.x.x86_64-unknown-linux-musl.tar.gz
tar -xzf shadowsocks-*.tar.gz
mv ssserver sslocal /usr/local/bin/

生成密钥

Shadowsocks 2022 使用 Base64 编码的随机密钥，而不是普通的密码字符串。密钥长度必须与所选加密方式匹配：

# 生成 2022-blake3-aes-256-gcm 所需的 32 字节密钥（Base64 编码）
openssl rand -base64 32

# 生成 2022-blake3-aes-128-gcm 所需的 16 字节密钥（Base64 编码）
openssl rand -base64 16

关于密钥格式

Shadowsocks 2022 的密钥必须是通过上述命令生成的 Base64 随机字节，不能使用普通的文本密码。密钥长度也必须严格匹配加密方式的要求，否则服务端会拒绝启动。

单用户服务端配置

{
    "server": "0.0.0.0",
    "server_port": 8388,
    "method": "2022-blake3-aes-256-gcm",
    "password": "base64-encoded-32-byte-key-here",
    "mode": "tcp_and_udp",
    "fast_open": true
}

多用户服务端配置

{
    "server": "0.0.0.0",
    "server_port": 8388,
    "method": "2022-blake3-aes-256-gcm",
    "password": "server-key-base64",
    "mode": "tcp_and_udp",
    "users": [
        {
            "name": "user1",
            "password": "user1-key-base64"
        },
        {
            "name": "user2",
            "password": "user2-key-base64"
        }
    ]
}

多用户模式下，password 字段为服务端主密钥，users 中每个用户各自拥有独立密钥。客户端连接时只需提供对应的用户密钥。

启动服务

ssserver -c /etc/shadowsocks/config.json

Systemd 服务单元示例

[Unit]
Description=Shadowsocks-Rust Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/ssserver -c /etc/shadowsocks/config.json
Restart=on-failure

[Install]
WantedBy=multi-user.target

客户端支持

平台	客户端	支持状态
Windows / macOS / Linux	Mihomo、sing-box、Xray、v2rayN	支持
iOS	Shadowrocket、Stash、Surge、Loon	支持
iOS	Quantumult X	支持
macOS	Stash、Surge	支持
Android	NekoBox、Husi、Exclave	支持
Linux	dae	不支持（dae 不支持 SS-2022）

版本要求

由于 Shadowsocks 2022 规范相对较新，请确保你的客户端版本足够新。如果客户端连接失败并提示加密方式不支持，通常是版本过旧导致的。

常见问题

Q：连接时提示"时间不同步"怎么办？

服务端和客户端的系统时间偏差必须在 30 秒以内。在 Linux 服务器上，可以运行以下命令同步时间：

timedatectl set-ntp true

Q：多用户模式下，用户密钥和服务端主密钥有什么区别？

服务端主密钥用于验证多用户数据包的外层包装，每个用户的独立密钥用于验证用户自身的数据。客户端只需要知道用户密钥，不需要知道服务端主密钥。

Q：Shadowsocks 2022 可以使用 obfs 等混淆插件吗？

不可以。Shadowsocks 2022 的协议规范与旧式混淆插件不兼容。如果需要进一步的流量混淆，应考虑 v2ray-plugin（使用 WebSocket + TLS 模式），但这会引入额外的复杂度，通常不如直接选用 VLESS + Reality 划算。

为什么需要 2022 版本​

核心改进​

固定长度的请求头加密​

时间戳校验​

服务端盐值过滤（Replay Filter）​

更严格的头部验证​

新的加密方式​

工作原理​

请求流程​

多用户支持（服务端多用户）​

与原版 Shadowsocks 的对比​

优缺点​

适用场景​

服务端部署参考​

安装 shadowsocks-rust​

生成密钥​

单用户服务端配置​

多用户服务端配置​

启动服务​

Systemd 服务单元示例​

客户端支持​

常见问题​

延伸阅读​