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 划算。
延伸阅读
- Shadowsocks 原版协议 — 了解原版协议的历史和基本原理
- VLESS 协议 — 了解更强抗检测能力的现代协议
- 代理协议总览 — 回到协议总览页面
- 规范与实现参考:github.com/shadowsocks/shadowsocks-rust
- Shadowsocks 文档站点仓库:github.com/shadowsocks/shadowsocks.org