清单先把userinfo与连接位置分开
SIP002 中的 userinfo 由 method:password 组成，主机与端口位于它后面。可选内容还有 plugin 与 tag，读取时先区分认证数据、连接目标和显示标记。
| 字段部分 | 规范里的用途 |
|---|---|
| method | 加密方法名 |
| password | 对应方法的凭据内容 |
| hostname | 服务器主机 |
| port | 连接端口 |
| plugin | 插件参数 |
| tag | 分享标签 |
- [ ] 方法名完整保留，不只记录AES或CHACHA大类。
- [ ] 服务器与端口分别核对，不用标签替服务器。
- [ ] 插件条件连同来源保存，真实凭据不公开贴出。
Shadowsocks 的本地组件接收客户端请求，再加密转给远端，由远端解密并转发目标。这个转发模型描述协议角色，不能从本地代理已存在推定远端配置正确。
编码规则按加密代际逐项读取
Stream 与 AEAD 的 userinfo 可以用 Base64URL 编码，2022 版则不得这样编码，改用百分号编码。都是 ss 前缀，不代表内部内容可按同一套编码规则随意重写。
SIP002 说明 Base64URL 用来安全转义字符，不是在尝试加密。分享字符串可读性与协议对流量采用什么加密是不同问题，不能把编码外观当作加密能力证明。
分享的字符编码与流量加密方法分开读，不能只凭外观互相替代。
- 找到完整method名，先辨认所对应代际。
- 按该代际的userinfo要求读取，不自行来回改编码。
- 再看主机端口与插件，保持原始来源可追溯。
密钥模型不能从旧口令规则直接沿用
2022 版要求固定长度、密码学安全的 PSK，采用 Base64 表达密钥，不再从口令使用 EVP_BytesToKey 派生。这里的密钥编码，与整段 userinfo 不得 Base64URL 编码并不矛盾。
方法 2022-blake3-aes-128-gcm 对应 16 字节密钥，2022-blake3-aes-256-gcm 对应 32 字节。长度条件按方法读取，不把较短或较长当成服务质量等级。
官方将 Stream 页列为历史资料，AEAD 又有自己的规范与修订。看到旧方法时保留原名与客户端支持条件，不补成当前所有核心都采用相同方法清单。
插件支持按具体核心而非前缀判断
SIP002 的插件参数对应 SIP003 插件，sing-box 记录只列 obfs-local 与 v2ray-plugin。mihomo 的插件清单更长，不能把它支持的其他名称写进 sing-box 的范围。
分享规范也不保证所有客户端全部支持 SIP002。核对时把客户端、方法和插件放在同一条记录里，前缀相同不替实际解析结果作答。
配置来源另换时可继续了解
下方收录入口可用来了解其他机场，方法和插件范围再单独阅读。
常见问题解答
2022版密钥用Base64与userinfo限制冲突吗？
两者对象不同，PSK 的表达要求与整个 userinfo 的分享编码分别规定。2022 版 userinfo 不能用 Base64URL，不能把密钥编码要求挪作整段编码办法。
ss标签可以当成服务器地址填入吗？
tag 是分享标记，hostname 才对应连接主机，端口也独立读取。保留字段所属位置，不用可读标签或节点展示名替代真实连接目标。
mihomo支持的插件能直接认定sing-box也支持吗？
按具体核心清单看，sing-box 这里列 obfs-local 与 v2ray-plugin，mihomo 另有自己的范围。分享前缀相同不能消除插件能力差别。