在 v2rayN 里手动添加一个 Shadowsocks 节点，表单上要填的只有四样，地址、端口、密码和加密方式。点开加密方式的下拉框，除了 aes-256-gcm、chacha20-ietf-poly1305 这些老名字，还能看到三个以 2022-blake3 开头的选项。选了它们，这个节点就是 Shadowsocks 2022。
Shadowsocks 官方文档把协议定义成一个基于 SOCKS5 思路的加密分体代理，本地一端加密，远端一端解密后再去连目标网站。这个骨架一直没变，变的是中间那层加密怎么做。2022 版由一份叫 SIP022 的规范定义，规范开头就写明，它要解决前几版的已知问题，并换掉过时的密码学函数。
密码一栏为什么是一串 Base64
老版本的 Shadowsocks 让你随便设一个密码，程序用 OpenSSL 的 EVP_BytesToKey 把它推成密钥。密码设成 123456 也能用，强度全看用户自觉。
SIP022 把这条路堵死了。规范要求用户直接提供一段密码学安全的固定长度密钥，实现方不得再用 EVP_BytesToKey 或任何别的办法从密码生成密钥，规范里还提了一句，这个改动是受 WireGuard 启发。密钥用 Base64 写出来，长度跟着加密方式走。
| 加密方式 | 密钥长度 | 是否必须实现 |
|---|---|---|
2022-blake3-aes-128-gcm |
16 字节 | 必须 |
2022-blake3-aes-256-gcm |
32 字节 | 必须 |
2022-blake3-chacha20-poly1305 |
32 字节 | 可选 |
规范给的生成办法是一条命令。
# 128 位方法用 16，256 位方法用 32
openssl rand -base64 16所以订阅里 SS2022 节点的 password 长得像 AAAAAAAAAAAAAAAAAAAAAA==。它是机场面板替你生成的，你只管更新订阅。要是自己手填，得留意长度。sing-box 用的那个 Shadowsocks 库里，密钥比要求的短会直接返回 bad key 错误。
会话密钥的推导也换了。2017 年的 AEAD 版用 HKDF-SHA1，信息串固定为 ss-subkey。到了 2022 版，子密钥交给 BLAKE3 的 derive_key 去算，上下文字符串是 shadowsocks 2022 session subkey，盐的长度和密钥一样。加密方式名字里的 blake3 就是这么来的。
时间差半分钟，节点就连不上
这是 2022 版在使用上最容易踩到的一处。每个请求头里多了一个 8 字节的 Unix 时间戳，规范写的是，时间差超过 30 秒的消息必须当作重放处理。服务器还要把收到的盐保存 60 秒，同一个盐第二次出现就拒绝，并且不许用布隆过滤器这类可能误报的结构来存。
重放是什么意思呢。有人在线路上录下你发过的一段加密数据，原样再发给服务器，看服务器有什么反应，靠反应来判断这台机器是不是代理。2017 年的 AEAD 文档里没有写任何防重放的机制。Xray 的文档列过旧协议的几条毛病，其中有 TCP 重放过滤器的误报率会随时间增加，UDP 完全没有重放保护，还有可用于主动探测的 TCP 行为。
落到用户这边就是一件事，设备的时钟要准。电脑和手机开着自动对时一般没问题。哪天 SS2022 节点整组超时，而同一份订阅里别的协议还能用，先去校一下时间。VMess 也依赖时间，容差是 90 到 120 秒，VMess 和 VLESS 的区别那篇里有细说，SS2022 比它严得多。
规范对服务器被探测时的表现也有要求。解密失败或者请求头校验不过，服务器不能立刻关连接，因为带着未读数据关闭会发出 RST，探测的人能据此算出服务器读了几个字节。规范给了三种处理办法，目的都是让外面看不出这个数字。请求头里还必须带初始数据或者随机填充，填充最长 900 字节，两样都没有的请求服务器要拒绝。
从流加密一路换到 2022 版
Shadowsocks 的加密方式换过三轮，订阅里偶尔还能看到老的。
最早是流加密，名字像 aes-256-cfb、rc4-md5、chacha20-ietf。官方文档在这一页顶上挂着一句警告，说流加密已经完全被攻破，很快会被移除，新用户必须用 AEAD。这类加密只管保密，不校验数据有没有被改过。
2017 年标准化的 AEAD 版补上了完整性校验，常见的是 aes-128-gcm、aes-256-gcm 和 chacha20-ietf-poly1305。数据被切成一块一块，每块带长度和校验标签，单块载荷上限是 0x3FFF 字节。
2022 版沿用了 AEAD 版分块传输的办法，在请求和响应两头各加了一个独立的头部块，时间戳、类型和填充都放在里面。
订阅和链接里另外两处变化
分享链接的写法变了。SIP002 规定，老方法的 ss:// 链接可以把加密方式和密码一起做 Base64URL 编码。到了 2022 系列，规范明确不许这么编，加密方式和密钥要用百分号编码直接写在链接里，所以 SS2022 的链接里能直接读到 2022-blake3-aes-256-gcm 这几个词。
密码里可能出现冒号。SIP023 给 2022 版加了一套身份头，用来在一个端口上区分多个用户，做法是把几段密钥用冒号连起来，前面是标识层级的 iPSK，最后一段是用户自己的 uPSK。看到 password 里有两段 Base64 中间夹一个冒号，那是正常写法，整串原样保留就行。
在 Mihomo（Clash Verge Rev 这类客户端用的内核）里，一个 SS2022 节点这样写。
proxies:
- name: "日本 SS2022"
type: ss
server: jp01.example.com
port: 8388
cipher: 2022-blake3-aes-128-gcm
password: "AAAAAAAAAAAAAAAAAAAAAA=="
udp: truesing-box 的字段名不同，加密方式叫 method。
{
"type": "shadowsocks",
"tag": "jp-ss2022",
"server": "jp01.example.com",
"server_port": 8388,
"method": "2022-blake3-aes-128-gcm",
"password": "AAAAAAAAAAAAAAAAAAAAAA=="
}两家文档列出的 2022 方法都是上表那三个。插件的支持范围差得远，Mihomo 文档列了 obfs、v2ray-plugin、shadow-tls 等七种，sing-box 只认 obfs-local 和 v2ray-plugin。机场节点如果套了插件，换内核时要留意这一点。
UDP 也重做了。每个 UDP 会话有自己的会话 ID 和递增的包 ID，两头用滑动窗口过滤重复的包，服务器要把每个会话至少记住 60 秒。老版本每个 UDP 包各自独立加密，既没有会话的概念，也防不了重放。
规范自己写明没做的事
SIP022 的概述里有一句很坦白的话，2022 版和前几版一样不提供前向保密，作者认为预共享密钥加免握手的做法最适合它的用途。前向保密的意思是，就算长期密钥哪天泄露了，以前录下的流量也解不开。SS2022 做不到这一点，密钥泄露后，被录下的旧流量理论上可以解密。靠 TLS 的协议（比如 Trojan）在这一点上有 TLS 1.3 兜底，RFC 8446 写明它的公钥密钥交换全部提供前向保密。
它也没有伪装成任何别的协议。规范的说法是代理流量与随机字节流无法区分，这和 Trojan、REALITY 那种装成 HTTPS 的思路是两条路。哪条路在你的网络里更好走，本站没有测过，不下结论。
本站收录的 28 家机场里，没有一家在资料中标注 Shadowsocks，写了协议的 8 家标的都是 VLESS、Trojan 或 AnyTLS（机场自述与站长资料，核对日 2026-08-09）。这不代表它们的订阅里没有 SS 节点，导进客户端看一眼类型标签才算数。