ss:// 有两种写法，解析失败通常是混了

一句话结论：ss:// 有新旧两种写法。旧的是整段 Base64，新的（SIP002）只把「加密方式:密码」那一小段编码、服务器地址留在明文。解析失败通常是因为链接被截断，或者两种格式被人为拼接过。

两种格式长什么样

旧格式：ss:// 后面整段都是 Base64。

ss://YWVzLTI1Ni1nY206cGFzc3dvcmRAZXhhbXBsZS5jb206ODM4OA

解开之后是：aes-256-gcm:password@example.com:8388

SIP002（新格式）：只有「加密方式:密码」被编码，@ 后面的服务器和端口是明文，还可以带查询参数和 # 备注。

ss://YWVzLTI1Ni1nY206cGFzc3dvcmQ=@example.com:8388#香港01

一眼分辨的方法：链接里能直接看到服务器地址和 @，就是新格式；整段都是看不懂的字符，就是旧格式。

两条报错分别指向什么

ss:// 后面既不是 base64，也不是 userinfo@host:port 结构

两种格式都套不上。最常见的原因是链接被截断——尤其是旧格式，少几个字符就既解不开 Base64、又不符合明文结构。

userinfo 里没有找到「加密方式:密码」的分隔冒号

结构对上了（识别为新格式），但 @ 前面那段解开后没有冒号。说明 userinfo 部分本身有问题：可能只编码了密码而漏了加密方式，也可能那段根本没有编码。

三个具体成因

# 后面的备注含中文，被 URL 编码了一半。 备注是给人看的，不影响连接，但有些工具会把它编码成 %E9%A6%99%E6%B8%AF，另一些不会。中途经过多个工具转手时，可能出现只编码了一部分的情况，导致解析器在错误的位置断开。

旧格式的 Base64 尾部 = 被吃掉了。 有些聊天软件或论坛会把链接末尾的 = 当成标点截掉。旧格式对这个特别敏感，因为整条信息都在那段 Base64 里。

两种格式被手工拼过。 比如把新格式的服务器地址部分，接到了旧格式的 Base64 后面。这通常发生在有人「参考着改」而不是重新导出的时候。

怎么处理

首选是重新获取，而不是修复。 ss 链接里含有密码，手工拼接改错一个字符就连不上，而且错误信息不会告诉你「密码错了」——表现出来是连接超时或握手失败，排查成本远高于重新复制一次。

如果一定要自己看清结构，把链接粘进节点链接解析器。它对 ss:// 的两种历史写法都做了兼容，会把加密方式、密码、服务器、端口拆成表格显示，也会指出卡在哪一步。

顺带：加密方式必须两端一致

Shadowsocks 的 cipher（加密方式）不是可以随便改的偏好设置，它是协议参数，客户端和服务端必须完全一致。链接里写的是什么，配置里就得填什么。

常见的现代取值是 aes-256-gcm、chacha20-ietf-poly1305、2022-blake3-aes-256-gcm。如果链接里的加密方式你的客户端不支持，那是客户端版本问题，改成别的值不会让它连上，只会连不上得更彻底。

→ UUID 和密码是一回事吗？各协议的凭证有什么不同

相关

• vmess:// 链接解析失败的两种情况
• 粘进去报「不认识的协议」——这几种链接都不是节点链接