手动添加 VLESS 与 VMess 节点：字段逐项对照

绝大多数时候你不需要手动填 VLESS 或 VMess 节点——从剪贴板导入一条分享链接，v2rayN 会自动把参数拆进各个输入框，又快又准。手动填写的真正价值在别处：当导入后连不上，你得知道那条链接里的哪一段对应界面上的哪一格，才有可能定位到是哪个字段错了。

这类字段错误有一个非常鲜明的特征——它们不会让你"变慢"，只会让你"连不上"。UUID 少了一位、SNI 填成了服务器地址、Reality 的公钥被截断，结果都是握手阶段直接失败，延迟测试显示超时。这个特征很有用，因为它把排查方向一刀切开了：测延迟失败往下查字段，测延迟正常但速度差往下查线路。

所以这一篇按"链接的一段 → 界面的一格 → 填错会怎样"这个顺序展开，把两种协议放在一起对照。至于协议本身为什么这样设计，属于原理层面的问题，可以另看 VLESS 与 VMess 的代际差异。

一条 VLESS 分享链接，各段参数对应哪个输入框#

先看一条结构完整的链接。以下地址与凭据均为占位示例，不是可用节点：

vless://11111111-2222-3333-4444-555555555555@node.example.invalid:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.example.invalid&fp=chrome&pbk=PUBLICKEYPLACEHOLDER&sid=0123abcd&type=tcp#示例节点

把它按分隔符切开，每一段的归属如下：

VMess 的分享链接结构不同，它把参数打包成一段编码后的 JSON，肉眼看不出内容，但字段名基本一一对应：add 是地址、port 是端口、id 是 UUID、aid 是 alterId、net 是传输协议、host 与 path 是伪装参数、tls 是传输层安全。

别名（# 之后的部分）不参与连接，只影响列表里的显示。有人以为改了别名会影响连接结果，其实不会；反过来，带中文别名的链接在个别工具间传递时可能被截断，这才是需要注意的地方。

UUID、加密方式和 flow 分别该填什么#

这三格挨在一起，出错概率却相差很大。

UUID 一律用复制粘贴，不要手打。它是三十多个字符加四个连字符，肉眼校对成本极高，而错一位的表现和填错服务器地址一模一样——超时，没有任何提示告诉你是身份不对。粘贴后检查一件事：首尾有没有混进空格，这是从聊天软件复制时的高发问题。

加密方式那一格常引发误解。VLESS 填 none 是协议本身的规定，因为它把加密职责整个交给了外层的 TLS 或 Reality，自身不再做一层。这不等于明文传输。VMess 相反，它自带一层加密，选 auto 让客户端与服务端协商即可。

flow 是 VLESS 特有的流控字段，必须与服务端配置严格一致。服务端开了流控而客户端留空，或者客户端填了服务端没开，都会出现"连接建立后立刻断开"这种比超时更迷惑的现象。不确定时以机场给的链接为准，留空和填错都比猜一个安全。

传输协议选 tcp、ws 还是 grpc#

这一格决定数据在 TLS 之下用什么方式承载，选错会导致服务端根本认不出你的请求。

没有"哪个更好"的答案，只有"服务端开了哪个"。这一格属于必须完全对齐的配置项，和后面要说的 SNI 一样，猜是没有意义的。

一个实用的判断线索：如果节点的地址看起来是某个 CDN 服务商的域名而不是一个裸 IP，那多半是 ws 或 grpc，且 host 和 path 不能留空。

伪装域名 host 与路径 path 什么时候必须填#

只有传输方式选了 ws、h2 这类基于 HTTP 的承载时，这两格才有意义；选 tcp 时填了也不生效。

它们的作用是让请求在 HTTP 层面看起来像访问某个正常网站的某个路径。服务端会按 path 分流，填错 path 的结果通常是服务端返回 404 之类的响应，客户端表现为握手后立刻断开。

需要特别区分的是 host 和 SNI：

两者的值经常相同，于是很多人以为它们是一回事。真正需要分清的时刻是排错——报证书相关错误就去看 SNI，握手过了却马上断就去看 host 和 path。证书类报错的完整对照可以看 TLS 握手失败的报错反查。

Reality 的 publicKey、shortId 和指纹怎么对上#

Reality 不是独立协议，它是 VLESS 使用的一种握手伪装方式，因此它的字段是叠加在 VLESS 之上的。原理层面的解释见 Reality 的证书借用机制，这里只说填法。

三个专属字段的对应关系：

1. publicKey（pbk）——服务端生成的公钥，整串复制，最容易出错的是被聊天软件自动换行截断，粘贴后确认长度完整。
2. shortId（sid）——一段短标识，服务端可能配置了多个，填其中任意一个都行，但必须在服务端的列表里。留空只在服务端允许空值时可用。
3. 指纹（fp）——指定客户端模拟哪种浏览器的 TLS 指纹，常见值是 chrome。它必须与服务端预期一致，填一个服务端不接受的值会直接握手失败。

还有一项不属于 Reality 专属但影响巨大的因素：系统时间。TLS 握手对时间敏感，本机时间偏差过大会让证书校验失败。遇到 Reality 节点集体连不上时，先看一眼系统时钟是不是准的，这比检查任何字段都快。

Reality 节点不需要你自己准备域名和证书，SNI 那一格填的是被借用的那个真实站点域名，不是你的服务器地址。把服务器地址填进 SNI 是这一类配置里最常见的错误。

VMess 的 alterId 为什么现在统一填 0#

alterId 是 VMess 早期用来生成额外用户 ID 的机制，目的是增加流量特征的随机性。这个设计后来被证明收益有限、开销不小，新版协议改用了另一套方案，alterId 随之废弃。

现在的规则很简单：

填了非 0 值而服务端已升级到新方案，或者反过来，表现都是认证失败、连接超时。这也是老配置在新客户端上突然连不上的常见原因之一——不是节点坏了，是这一格的约定变了。

保存后不生效，优先检查哪两处#

排查顺序不必从头到尾扫一遍字段，先看两处，命中率最高。

第一处是传输层安全那一组：security 选了 tls 或 reality，但 SNI 留空或填成了服务器 IP。这一组填错的表现是测延迟直接超时，日志里能看到握手相关的失败记录。把日志级别临时调到 info 就能看到具体卡在哪一步。

第二处是复制粘贴的完整性：UUID 和 publicKey 这两串长字符是被截断和混入空格的重灾区。快速验证方法是把界面里的值重新复制出来，和原始链接里的那一段做一次比对。

这两处排除之后，再按下面的顺序看：

1. 端口是否正确，特别是从链接里复制时有没有带上冒号。
2. 传输方式与 host、path 是否配套，选了 ws 却没填 path 的情况很常见。
3. 内核是否支持该协议特性，旧内核对 Reality 的支持不完整，表现同样是握手失败。
4. 系统时间是否准确。

# 结构示例：日志级别调到 info 后，握手失败通常呈现为类似这样的记录
[Warning] failed to handshake with node.example.invalid:443

如果这四步都过了仍然不通，问题大概率已经不在字段上，而在节点本身或本地网络，此时该转向连接层的排查思路。

小结#

VLESS 与 VMess 的手动配置，关键不在于记住每一格填什么，而在于建立"链接的一段对应界面的一格"这个映射关系。UUID 与 publicKey 一律复制粘贴并检查完整性；VLESS 的加密方式固定 none、flow 必须与服务端一致；VMess 的 alterId 统一填 0，除非链接明确给了别的值。SNI 和 host 分属 TLS 与 HTTP 两层，报错表现不同，不要混为一谈。所有这些字段填错的共同表现都是握手失败而非速度下降，所以测延迟能否通过，就是判断问题在字段还是在线路的分水岭。