订阅链接是供客户端读取订阅内容的网络地址。地址负责指向资源，返回的内容才交给客户端解析。理解这两个层次，就能分清“拿到了文本”和“读出了节点”为何是两回事。

一条地址怎样变成列表

这条链路可以概括为：

URL → HTTP 请求 → 返回文本 → 尝试解码 → 按行识别 → 节点列表

据 v2rayN 的订阅说明，订阅地址须能正常访问，内容则要符合客户端支持的协议格式或内部格式。地址能访问，不能单独证明内容可被解析。

URL 是资源的网络位置。按 MDN 对 URL 的解释，它可以包含协议、主机信息、路径、查询参数和片段标识。这些部分描述地址，不等于返回正文的格式。

发出请求时，客户端还会携带请求头。v2rayN 的界面说明提到，User-Agent 的默认形式为 v2rayN/版本号；返回端可以据此选择响应内容。因此，同一个地址的响应还可能与请求头有关。

返回的文本为什么有不同模样

截至 2026-11-08，按 v2rayN 7.25.6 源码，其处理会尝试 Base64 解码，也会退回原文逐行读取，仍未解析出节点时再尝试解码。拆行后会舍去空行，订阅处理还会合并重复行。每行开头的协议标识决定后续解析方式，无法识别的行会被跳过，且不因此报错。

这解释了两个现象：一段返回内容未必直接可读；文本中有多行，也未必每行都会出现在列表里。

看到的内容应怎样理解
可读的协议条目仍需由客户端判断其格式
一长串编码字符可能需要解码后再读取
解析后没有条目不能只凭地址能打开就判断成功

v2rayN 与 v2rayNG 的源码都会尝试明文和 Base64 内容。不能据此把“整份内容必须经过 Base64 编码”当作统一规范。要继续操作，可看订阅地址的导入方法。

地址、协议标识与编码分属不同层

订阅地址用来取回内容；内容里的协议标识用于选择解析方式。它们承担不同任务。

截至 2026-11-08，v2rayN 7.25.6 源码识别的行首包括 vmess://、vless://、trojan:// 等。其中，vmess:// 后面的内容是经过 Base64 编码的 JSON；vless:// 与 trojan:// 则采用标准 URL 形式。

因此，解开外层编码后，单条内容仍可能包含编码。看到 :// 也不能直接认定它就是供客户端请求的订阅地址。相关名词可查URL、协议与配置术语解释。

Base64 标准还区分普通 Base64 与使用 URL 安全字母表的 base64url。两者不能混称为完全相同的格式。

分享前要看地址里有什么

RFC 3986提醒，URI 可能显示在浏览器中，也可能进入书签、访问历史或中间程序的日志。需要保密的用户名、密码不适合放进 URI。

RFC 9110也指出，服务器、代理与客户端可能记录或展示目标 URI，使其中的信息被第三方看到。因此，公开粘贴完整地址前，应检查其中是否含有敏感信息或个人标识。

具体订阅地址怎样识别用户、是否带有访问凭证，官方没有说明。不能仅凭“订阅链接”这个名称推断其中有什么，也不能据此断言泄露后的具体后果。

Base64 不能替代保密措施

Base64 用字符表达数据，作用是编码。RFC 4648 明确指出，这种处理可以让内容不易被直接辨认，却不提供计算意义上的保密。返回内容看起来难读，不代表它受到加密保护。

截至 2026-11-08，按 v2rayN 7.25.6 源码，保存 HTTP 订阅地址时会出现安全提示，但仍允许保存。保存成功只说明地址被接受，不能据此判断安全性。

上述解析与提示行为以截至 2026-11-08 核对的源码为依据，后续版本需要重新核对。引用的 RFC 属于已发布标准，MDN 页面则可能修订。

第三方整理，与项目方无关。