vmess:// 链接解析失败的两种情况，报错不一样
vmess 链接是 Base64 编码的一段 JSON，所以解析可能在两个不同的阶段失败：Base64 本身解不开，或者解开了但内容不是合法 JSON。两种报错指向的原因完全不同，本文说明各自的成因与排查顺序。
本文目录（6 节 · 约 2 分钟） +
- 01 两条报错分别是什么意思
- 02 第一种：Base64 解不开
- 03 第二种：解开了但不是 JSON
- 04 排查顺序
- 05 一个提醒
- 06 相关
一句话结论：vmess:// 后面是「Base64 编码的一段 JSON」，所以有两道关卡。第一道过不去说明链接被截断或混入了杂字符，第二道过不去说明这条链接根本不是标准的 vmess 分享格式。
两条报错分别是什么意思
vmess://后面不是合法的 Base64
第一道关卡失败。 连解码这一步都没走完，通常是链接不完整或掺了别的字符。
Base64 能解开，但里面不是合法 JSON（vmess 分享链接应为 Base64 编码的 JSON）
第二道关卡失败。 解码成功了，但解出来的东西不是 JSON。这说明链接的编码方式或格式与标准不同。
第一种：Base64 解不开
按可能性排序：
链接被截断了。 从聊天软件复制时最常见——消息气泡把长链接折行显示，选中时漏掉了尾巴。vmess 链接通常上百个字符，少几个就解不开。判断方法：看链接结尾，标准 Base64 的长度是 4 的倍数，不足时用 = 补齐，所以正常的 vmess 链接末尾常常是 = 或 ==。当然没有 = 也可能正好对齐，这只是一个参考信号。
混进了空格或换行。 复制时带进了行首缩进、或者链接中间被插入了换行符。多数解析器会先清理空白，但如果空白出现在中间且原链接本身有问题，就可能失败。
带上了多余的前后缀。 比如把整句话都复制了：我的节点：vmess://eyJ2Ijoi...，前面那几个字会让解析从错误的位置开始。
用的是 URL-safe 变体。 少数生成器输出的 Base64 用 - 和 _ 替代了标准的 + 和 /。规范的解析器会同时接受两种，但不是所有工具都会。
第二种：解开了但不是 JSON
这种情况说明链接结构本身不同：
它其实是别的协议。 有些工具会把非 vmess 的内容也套上 vmess:// 前缀。解开之后如果看到的是 auto:密码@服务器:端口 这种形状，那更像 Shadowsocks 的写法。
它是「v2rayN 早期格式」。 极老的版本用过 安全类型:UUID@服务器:端口 这种非 JSON 的紧凑写法。现在基本绝迹，但从很旧的备份里翻出来的链接可能是这种。
内容被二次编码了。 有的分享工具会把整条链接再 Base64 一次。这种情况下解开第一层看到的还是一串 Base64 字符，不是 JSON。
排查顺序
- 先确认是不是截断：回到来源重新完整复制一次。这一步能解决大多数情况，而且成本最低。
- 再看有没有杂字符：确保复制的内容以
vmess://开头，且后面没有空格、换行、中文。 - 仍然失败就换来源：让对方重新导出一次，或者从机场后台重新取。
把链接粘进节点链接解析器可以直接看到卡在哪一关——两种失败给的是不同的提示，不用自己判断。它支持一次粘多条，每条单独出结果，所以可以把一批链接一起丢进去，快速找出坏掉的那几条。
一个提醒
排查过程中不要把链接发给别人帮忙看。vmess 链接里含有完整的 UUID，那是连接凭证——拿到它的人可以直接使用你的节点。
相关
相关文章
ss:// 有两种写法，解析失败通常是混了
Shadowsocks 分享链接历史上有两种写法：整段 Base64 的旧格式，和把服务器地址留在明文的 SIP002 新格式。解析器报「既不是 base64 也不是 userinfo@host:port 结构」时，多半是两种格式被拼在了一起或复制不全。
解码后节点数对不上？重复条目是怎么回事
机场页面写着 60 个节点，解码出来却只有 52 个能用。差额通常来自三处：服务器加端口完全相同的重复条目、解析失败的坏行，以及非节点的公告行。本文说明怎么逐项对上账。
粘进去报「不认识的协议」——这几种链接都不是节点链接
解析器只认节点分享链接。报「不认识的协议」时，粘进去的往往是订阅地址、一键导入链接或网页地址——它们长得像链接，作用却完全不同。本文列出几种常被混淆的链接，并说明各自该怎么处理。