TL;DR：Shadowsocks 2022 失败时，先核对
method，再核对密码层级。2022-blake3-aes-128-gcm和2022-blake3-aes-256-gcm不是同一个方法；服务端密码和用户 identity 也不能混填。
SS 2022 的配置比传统 Shadowsocks 多了几处容易写错的字段。旧版 SS 只要 server、port、method、password 大体一致就能试；SS 2022 涉及 AEAD-2022 方法、派生密钥、多用户 identity，客户端兼容性也更挑版本。
先看 method 是否完全一致
常见方法包括：
| method | 常见用途 | 排查点 |
|---|---|---|
2022-blake3-aes-128-gcm | 轻量配置 | 客户端是否支持 2022 前缀 |
2022-blake3-aes-256-gcm | 更长密钥 | 密码长度和服务端一致 |
2022-blake3-chacha20-poly1305 | 非 AES 加速设备 | 客户端实现是否完整 |
不要把传统 aes-128-gcm 当成 SS 2022。少了 2022-blake3- 前缀，含义就变了。
密码层级别混
多用户 SS 2022 常见两层信息：服务端主密码用于派生服务端密钥，用户 identity 或用户密码用于区分用户。不同客户端字段名不同，有的写 password，有的写 server_password，有的把 identity 放在插件参数或用户字段里。
排查时向服务端配置反推：
{
"method": "2022-blake3-aes-256-gcm",
"password": "server-password",
"users": [
{ "name": "user-a", "password": "user-password" }
]
}客户端如果只填了 user-password，但需要的是组合后的分享链接，就会出现认证失败。反过来，把服务端主密码当成用户密码也一样会失败。
日志关键词对应方向
| 日志关键词 | 优先排查 |
|---|---|
method not supported | 客户端版本或 method 名称 |
decrypt failed | method、密码、identity 不一致 |
invalid salt | AEAD-2022 握手字段不匹配 |
invalid user | 用户名、identity 或多用户配置 |
connection reset | 服务端拒绝、端口或中间网络问题 |
不要只看 GUI 的红色失败提示。打开核心日志，至少要拿到上面这些关键词之一。
客户端兼容性
截至 2026-05-21，sing-box、shadowsocks-rust、Mihomo 的新版本都能处理 SS 2022，但 GUI 外壳不一定同步更新。Hiddify、Karing、Clash Verge Rev、路由器插件都可能因为内置核心较旧而解析失败。
建议：
- 升级客户端到当前 release。
- 用同一链接在 sing-box 命令行或 shadowsocks-rust 测一次。
- 如果命令行可用、GUI 不可用，问题在 GUI 解析或内置核心。
- 如果全部不可用，回到服务端 method 和密码。
使用兼容 Clash / Singbox / V2Ray 的订阅时，也要确认导出端没有把 SS 2022 转成旧 Shadowsocks 方法。
分享链接也要解码看
SS URI 里 method、密码、主机、端口可能被 base64 或 URL encode 包起来。排查时把链接解码出来，确认 method 字符串没有丢字符，#备注 没有截断参数，二维码没有把 +、/、= 改坏。
最小修复流程
先让服务端输出一份明确的客户端配置，不要手抄字段。客户端升级后导入，失败再看日志。若日志指向 method，换成服务端实际方法；若指向 invalid user，核对 identity；若只有超时，才继续查端口、防火墙和网络路径。