V2Ray 协议手册：协议、传输与内核选型

一、先拆开协议、传输、安全层与内核

客户端里的“协议”不是单一开关

在 v2rayN、v2rayNG 或 v2flyNG 的服务器编辑界面里，一条连接通常同时包含协议类型、地址、端口、用户凭据、传输方式、安全层和路由出口。协议类型解决的是客户端如何与服务端进行身份认证、如何组织数据帧；传输方式决定这些数据帧通过 TCP、WebSocket、gRPC 等哪种承载方式发送；TLS 或 REALITY 等安全层负责握手、服务器身份确认和链路加密；内核则负责把这些字段组合成可执行配置。把这些概念混在一起，容易得出“某协议必然更快”或“只改类型就能连接”的错误结论。

例如 VLESS 可以运行在普通 TCP、WebSocket 或 gRPC 上，也可以与 TLS、REALITY 组合。两条都标为 VLESS 的节点，如果传输层、拥塞状况、证书握手和服务端实现不同，实际表现可能完全不同。REALITY 也不是与 VLESS 平级的代理协议，它更接近一套由 Xray 实现的传输安全方案，常见组合是 VLESS、TCP、REALITY 与 XTLS Vision。客户端选择服务器时，应把完整组合视为一个整体，而不是只看分享链接开头的 vless://。

选型时优先确认四项约束

第一项是服务端已经提供什么。客户端无法单方面把 VMess 改成 VLESS，也不能在服务端未配置 REALITY 时自行勾选 REALITY。第二项是内核是否认识对应字段。v2rayNG 以 Xray 内核为主要执行环境，v2flyNG 面向 V2Fly 内核；v2rayN 是桌面图形客户端，常见配置由 Xray 内核执行。基础 VMess、VLESS、Trojan 与 Shadowsocks 字段在生态中有较广覆盖，但 XTLS Vision、REALITY 等扩展必须匹配支持它们的内核。

第三项是配置来源。订阅链接会同时携带协议、地址、端口和传输参数，通常应完整导入，不要只复制地址与端口后重新手填。第四项是使用环境。桌面端更容易承担 TUN、复杂路由和多进程连接；移动端更关注常驻耗电、网络切换后的重连和后台状态。相同协议在不同平台上的体验差异，往往来自系统网络栈、TUN 实现和连接保持策略，而不是协议名称本身。

不要用单一标签代替完整判断

协议选型的合理顺序是：先确认服务端组合与客户端内核相容，再检查分享链接或订阅是否完整，之后才比较性能与资源占用。如果连接可以建立但网页无法访问，应继续检查系统代理、TUN、DNS 与路由分流；如果配置导入时字段已经丢失，则应先处理订阅格式，而不是反复切换系统代理。v2rayN 的桌面安装包、v2rayNG 与 v2flyNG 的 Android 安装包可在安装包页面按平台选择，安装完成后的基本操作则由入门指南承接。

二、VMess：完整会话协议与兼容性基线

诞生背景与设计重点

VMess 是 Project V 生态早期形成的核心协议之一。它把用户身份、时间信息、请求目标和数据传输组织进自己的协议结构，服务端根据用户 ID 识别连接。早期配置中经常能看到 alterId，它曾用于附加身份机制；现代实现普遍采用 AEAD 形式，常规配置里的 alterId 通常为零。导入较旧订阅时，如果客户端仍显示较大的 alterId，不应机械照搬到新服务端，而应以服务端实际配置为准。

VMess 的优点不是某一项极端性能，而是生态积累较久、字段定义成熟、许多客户端和订阅转换工具都能识别。对于已经稳定运行的 VMess 配置，没有必要仅因为出现了新协议名称就立即迁移。它仍适合作为跨客户端迁移时的兼容基线，尤其是连接组合只使用 TCP、WebSocket 与 TLS 等常见功能时，V2Fly 和 Xray 一般都能处理其基础配置。

认证、时间与加密字段

VMess 请求中包含与时间有关的认证信息，因此客户端和服务端系统时间相差过大时，可能出现地址、端口和用户 ID 全部正确却仍然认证失败的情况。排查时应先确认设备启用了系统自动时间与正确时区，再检查服务端时钟。这里关注的是系统时间误差，不是网络延迟。重复导入同一链接、切换全局代理或重装客户端都不能修复明显的时钟偏差。

客户端界面常把 VMess 的安全选项显示为 auto、aes-128-gcm、chacha20-poly1305 或 none。这些字段描述 VMess 数据层的处理方式，不能替代外层 TLS。选用 auto 时，内核会按实现和设备能力决定合适方式；手动固定算法只有在服务端明确要求或排查兼容问题时才有意义。外层启用 TLS 后，服务器名称、证书对应域名和传输路径仍需分别匹配。

VMess 常见配置错误

第一类错误是把用户 ID 当成普通密码编辑。VMess ID 通常采用 UUID 形式，字符缺失、前后带空格或复制到错误用户项都会导致认证失败。第二类错误是 WebSocket 路径与 Host 混淆：路径是 HTTP 请求路径，Host 是请求头或 TLS 服务器名称相关字段，两者可以相同也可以不同，必须按照原配置填写。第三类错误是只保留分享链接的主要字段，遗漏传输层参数。一个能被客户端识别的 vmess:// 链接不等于其中所有字段都被当前转换工具正确解析。

第四类错误出现在 TLS 开关。服务端要求 TLS 时，客户端关闭 TLS 通常无法完成正确握手；服务端未配置 TLS 时，客户端自行启用也不会自动获得安全连接。第五类错误是核心升级后继续使用过时字段。内核可能对已废弃字段给出警告或直接拒绝加载，图形客户端有时只显示“启动失败”。此时应查看日志中的字段路径，例如 outbound、streamSettings 或 security，而不是只看托盘状态。

何时保留，何时迁移

现有 VMess 连接稳定、服务端维护明确、订阅更新正常时，保留它通常比无目的迁移更省事。需要迁移的信号主要来自服务端配置变化、内核功能需求或订阅提供方明确更换协议。如果希望使用 REALITY 或 XTLS Vision，应按新的 VLESS 配置完整导入，不能把 VMess 节点的地址和 ID 简单复制后只改协议下拉框。迁移后也应保留原节点一段时间用于对照，以区分协议配置问题与本地 DNS、路由规则问题。

三、VLESS 与 REALITY：轻量认证和现代安全层组合

VLESS 为什么采用精简设计

VLESS 将重点放在轻量身份认证与请求转发，不在协议自身重复提供一套内容加密。客户端界面里常见的 encryption 值是 none，这并不表示完整链路必然缺少加密，而是说明安全能力应由 TLS、REALITY 等外层承担。这样做减少了协议层与传输安全层重复处理的机会，也让 VLESS 更容易与 XTLS 系列流控组合。配置人员必须明确：只有 VLESS 加 TCP 且未启用任何安全层时，链路属性与 VLESS 加 TLS 或 REALITY 完全不同。

VLESS 用户凭据通常仍是 UUID。与 VMess 相比，它不依赖 VMess 的时间认证结构，也没有 alterId。服务端可以为用户设置 flow 等扩展字段，客户端必须逐项匹配。常见的 xtls-rprx-vision 是 XTLS Vision 流控值，它属于 Xray 生态中的实现能力，并非所有使用 VLESS 名称的内核都支持。订阅导入后如果 flow 为空，而原链接明确包含 Vision，应先检查客户端内核与订阅解析过程。

REALITY 解决的配置层问题

REALITY 是 Xray 的传输安全实现，通常使用目标站点相关信息参与握手，并通过服务端私钥与客户端公钥建立对应关系。客户端侧常见字段包括服务器名称、指纹、公钥、Short ID 和 SpiderX；服务端则保存对应私钥及允许的服务器名称等配置。客户端只需要公钥，不应把服务端私钥写入订阅或分享链接。公钥、Short ID 或服务器名称任一不匹配，都可能表现为连接快速关闭。

服务器名称通常在客户端中显示为 SNI 或 serverName，它参与握手选择与校验。指纹字段常见值为 chrome 等浏览器指纹标识，用于确定握手特征实现；它不是设备浏览器版本，也不要求实际启动对应浏览器。Short ID 是服务端允许值之一，长度和内容必须满足服务端设置。SpiderX 常见默认值为斜杠，用于 REALITY 相关行为配置，除非服务端另有指定，不应凭经验添加复杂路径。

XTLS Vision 与转发路径

XTLS Vision 的目标之一是识别适合直接转发的数据路径，减少不必要的重复封装和内存复制。在传输内容本身已经具有安全层时，合理的流控可以降低额外处理成本，尤其对持续吞吐连接更有意义。不过，Vision 的收益依赖内核、服务端、传输组合与实际数据类型。短连接页面加载主要受握手、DNS 和往返时间影响，不能期待仅勾选 flow 就消除所有等待。

Vision 通常与 TCP 组合。把它和不受支持的传输方式任意拼接，可能导致配置无法加载或服务端拒绝。客户端编辑器如果提供了协议、传输、安全和 flow 四组选项，应按服务端给出的完整组合填写。正确的思路是先确认 protocol = vless，再确认传输方式，然后确认 security = reality，最后核对 flow、公钥、服务器名称、指纹与 Short ID。

{
  "protocol": "vless",
  "user": {
    "id": "00000000-0000-4000-8000-000000000000",
    "encryption": "none",
    "flow": "xtls-rprx-vision"
  },
  "transport": {
    "network": "tcp",
    "security": "reality",
    "serverName": "www.example.com",
    "fingerprint": "chrome"
  }
}

上面的片段用于说明字段层次，采用保留示例域名和示例用户 ID，不能直接连接到实际服务器。真实配置还必须包含服务器地址、端口、REALITY 公钥和 Short ID。它的意义在于帮助识别订阅转换后字段是否落在正确位置：VLESS 的用户字段、TCP 传输字段与 REALITY 安全字段不能互相替代。

导入失败时的核对顺序

先确认当前客户端确实使用支持 REALITY 与 Vision 的 Xray 内核，再确认链接中的 security=reality、flow=xtls-rprx-vision 没有在订阅转换时丢失。随后检查 pbk 或 publicKey、sid 或 shortId、sni、fp 等字段。不同分享链接规范可能使用简称，但导入后的界面应还原成对应配置项。如果客户端能保存节点但启动时报未知字段，通常是内核能力不匹配；如果内核启动正常但握手失败，则优先核对公钥、服务器名称和 Short ID。

四、Trojan 与 Shadowsocks：两种不同的简洁路线

Trojan 的 TLS 前提

Trojan 使用密码进行用户认证，并把标准 TLS 作为连接设计中的重要基础。客户端配置通常包括服务器地址、端口、密码、服务器名称和证书检查相关选项。它的字段数量相对直观，但“字段少”并不意味着可以忽略 TLS。服务器名称必须与服务端部署对应，证书名称检查依赖该字段；如果直接把服务器名称改成 IP，可能导致证书主机名不匹配。除非处于明确的诊断环境，不建议把关闭证书验证当作长期解决方案。

Trojan 与 VLESS 的主要区别不只在认证凭据。Trojan 使用密码，VLESS 常用 UUID；Trojan 的常规连接紧密依赖 TLS，VLESS 则可以与不同安全层组合。两者都能搭配部分传输方式，但具体支持范围由服务端和内核决定。收到 trojan:// 分享链接时，应完整保留密码、SNI、传输类型、Host 与路径，不能只提取最显眼的服务器地址。

Trojan 常见故障边界

如果 TLS 握手阶段就失败，应先检查设备时间、服务器名称、证书有效状态与网络是否能到达目标端口；如果 TLS 建立后认证失败，则继续核对密码。密码是区分大小写的字符串，链接中的特殊字符需要正确进行 URL 编码。某些手工复制过程会把加号、百分号或井号误作链接结构字符，导致导入结果与原密码不同。最稳妥的方式是由客户端直接导入完整分享链接，再在编辑界面核对字段。

WebSocket 或 gRPC 等传输还会增加路径、服务名和 Host 等参数。此时“Trojan 可连接”实际意味着 Trojan 认证、TLS 握手与传输层参数同时正确。日志出现 HTTP 状态错误时，应检查传输路径；出现证书名称错误时，应检查服务器名称；出现认证拒绝时，再检查密码。按阶段排查比反复切换多个开关更容易定位问题。

Shadowsocks 的加密方法与密码

Shadowsocks 采用较精简的加密代理结构，客户端与服务端必须使用完全相同的加密方法和密码。常见 AEAD 方法包括 aes-128-gcm、aes-256-gcm 与 chacha20-poly1305。不同方法在支持硬件加速的桌面处理器与移动处理器上可能表现不同，但现代设备上的差距通常还会被网络质量、连接数量和服务端负载覆盖。选型时优先服从服务端配置，不要在客户端单方面更换算法。

Shadowsocks 2022 系列方法改进了密钥和会话处理，但其密码或密钥格式与旧 AEAD 方法不同，而且并非所有内核与订阅解析器都完整支持。看到方法名包含 2022 时，应先确认客户端内核支持对应方法，再检查导入后的密钥是否完整。把 2022 方法改成传统 AEAD 名称不会产生兼容连接，因为服务端使用的协议细节已经不同。

什么时候选择这两类协议

服务端提供标准 Trojan 配置、证书与服务器名称管理清晰时，Trojan 的配置模型容易理解，也便于按 TLS 与认证两个阶段排查。服务端提供简洁 Shadowsocks 配置，且客户端明确支持对应加密方法时，Shadowsocks 的字段较少，适合不需要复杂流控扩展的场景。两者之间没有脱离环境的绝对优先级。实际选择应考虑服务端维护方式、客户端内核、订阅是否能完整表达字段，以及设备是否需要 TUN 与复杂路由。

v2rayN、v2rayNG 与 v2flyNG 都可能在界面中展示这些协议选项，但可见选项不代表当前内核支持所有扩展组合。特别是 Shadowsocks 插件参数、2022 方法和 Trojan 的特殊传输组合，应以执行内核的配置结果为准。若节点来自订阅，优先查看订阅更新后的原始类型，不要用名称相近的节点作为字段模板覆盖。

五、连接速度、资源占用与移动端电量

速度由多段链路共同决定

用户感知的“速度”至少包含 DNS 查询、客户端到服务器的连接建立、TLS 或 REALITY 握手、服务器到目标站点的连接、首字节等待和持续传输吞吐。协议只影响其中一部分。短网页请求更容易受到 DNS、握手往返和连接复用影响；大文件传输更容易体现加密实现、内存复制、拥塞控制与服务器出口能力。仅凭一次节点测速，无法把差异准确归因到 VMess、VLESS 或 Trojan。

比较协议时，应使用同一设备、同一网络入口、相近时间、同一服务器与目标内容，并尽量保持传输层一致。若一条节点使用 WebSocket 加 TLS，另一条使用 TCP 加 REALITY，那么结果反映的是完整组合差异。测试还应区分冷连接与已建立连接：冷连接包含 DNS 与握手成本，重复请求可能复用连接，二者适合回答不同问题。

CPU、内存与连接复用

加密算法是否具有硬件加速、数据封装层数、并发连接数量和日志级别都会影响 CPU 使用。AES-GCM 在具有 AES 硬件指令的桌面处理器上通常效率良好；ChaCha20-Poly1305 在缺少对应 AES 加速的设备上可能更合适，但不能只根据设备类别做绝对判断。VLESS 配合适当流控可以减少部分重复处理，实际收益仍需服务端和传输组合共同支持。

Mux 多路复用把多个逻辑连接汇集到较少的底层连接中，可能降低频繁握手的成本，也可能在单条底层连接出现拥塞或丢包时让多个请求相互影响。网页包含大量短请求时，Mux 有机会改善连接建立开销；持续下载、实时连接或网络质量波动明显时，关闭 Mux 反而可能更稳定。客户端默认值通常是合理起点，不建议把“连接数越少”直接理解成“速度越快”。

内存占用还与路由规则、域名数据库、DNS 缓存、TUN 缓冲和并发连接有关。协议本身的帧头差异通常不是图形客户端总内存的唯一主要来源。排查高占用时，应先比较关闭详细日志、减少过大的规则集、停止重复测速和关闭不必要的并发任务后的变化，再决定是否更换协议。

TUN 模式为何更耗资源

系统代理主要接管遵循系统代理设置的应用流量，处理路径相对直接。TUN 模式建立虚拟网络接口，可以覆盖更多不读取系统代理的程序，但需要处理 IP 包、DNS、路由匹配和协议栈转换。移动端长期启用 TUN 时，唤醒频率、后台连接保持、DNS 请求和网络切换重建都会影响电量。这里的主要成本来自系统级流量接管，并不能简单归因于所选代理协议。

如果只需要浏览器和遵循系统代理的桌面程序，优先使用系统代理通常更省资源；需要按进程或完整接管应用流量时，再启用 TUN。启用后应避免同时运行另一个占用虚拟网络接口的工具，并检查绕过局域网、DNS 模式和路由规则。TUN 可以提升覆盖范围，但不是“更强的协议”，也不会修复错误的用户 ID、公钥或服务器名称。

移动端电量的实际控制项

移动端电量表现更受网络状态和后台行为影响。信号较弱时，设备维持无线连接本身就需要更多能量；节点频繁断线会触发重连、DNS 重试与连接重建；自动测速和过短的订阅更新周期也会唤醒网络。合理做法是选择稳定节点，避免持续运行批量测速，按需要设置订阅更新，并在不需要完整流量接管时减少 TUN 使用时间。

协议层面可优先选择客户端内核原生支持、字段完整且连接稳定的组合。一个理论处理开销较低但频繁握手失败的节点，实际耗电可能高于稳定的传统配置。v2rayNG 使用 Xray 内核，适合需要 REALITY、Vision 等 Xray 功能的配置；v2flyNG 使用 V2Fly 路线，适合与对应内核配置保持一致。选择应用时，应把协议功能和后台稳定性一起考虑，而不是只比较安装包名称。

六、V2Fly 与 Xray 内核家族及配置兼容边界

共同基础与演进方向

V2Fly 和 Xray 都延续了 Project V 生态的模块化配置思路：入站负责接收本地流量，出站负责连接目标或代理服务器，路由决定流量交给哪个出站，DNS 模块提供域名解析策略，传输设置描述 TCP、WebSocket、gRPC 等承载方式。两者在 VMess、部分 VLESS、Trojan、Shadowsocks 和基础路由结构上存在大量相似概念，因此许多订阅可以被不同客户端识别。

相似不等于配置文件完全可互换。Xray 在 VLESS、XTLS Vision、REALITY 等方向形成了自己的功能扩展，也可能为传输和路由增加特定字段；V2Fly 则沿着自身版本和模块体系维护功能。某个 JSON 能被一个内核读取，不代表另一个内核会接受其中所有字段。图形客户端的“导入成功”也只说明链接被解析成了服务器记录，真正的兼容结果要以内核启动和连接日志为准。

三款客户端与内核定位

v2rayN 是本站桌面端首推客户端，覆盖 Windows、macOS 与 Linux，提供服务器列表、订阅分组、系统代理、TUN、路由设置和内核管理等图形入口。它适合需要在桌面端处理多订阅、复杂路由和协议测试的用户。常见配置以 Xray 能力为主，因此导入 REALITY 与 XTLS Vision 时，应确认实际启用的是对应内核，而不是只查看客户端名称。

v2rayNG 面向 Android，主要使用 Xray 内核，适合 VLESS、REALITY、Vision 以及常见 VMess、Trojan、Shadowsocks 配置。v2flyNG 同样面向 Android，但以内核路线区分，适合需要使用 V2Fly 配置语义的场景。两款应用的界面字段可能相近，执行结果仍由内核能力决定。服务端明确要求 Xray 扩展字段时，优先选择 v2rayNG；配置明确面向 V2Fly 时，可以选择 v2flyNG。

配置兼容性的三个层次

第一层是语法兼容，即 JSON 字段名称和数据类型能否被解析。第二层是功能兼容，即内核是否实现该协议、传输或安全层。第三层是行为兼容，即两边虽然都接受字段，但默认值、DNS 策略或路由匹配细节是否相同。迁移时只看到“配置加载成功”还不够，应继续验证域名解析、直连规则、代理规则和 UDP 流量是否符合预期。

分享链接兼容也分层次。客户端可能认识 vless://，却不认识链接中的新查询参数；也可能保留节点主体，但丢失 flow、fingerprint 或 Short ID。订阅转换服务还可能把内核专属字段改写成自己的中间格式。遇到这类情况，应该对比原始分享链接和导入后的编辑页面，并查看客户端导出的完整配置，而不是把问题笼统归为“协议不支持”。

切换内核前后的检查

在 v2rayN 中切换执行内核前，应记录当前节点协议、传输、安全层和路由设置。切换后重新启动客户端，使配置完整载入，再查看启动日志是否包含未知字段、无效枚举值或资源文件缺失。对于只使用基础 VMess、TCP 和 TLS 的配置，迁移往往较平顺；对于 REALITY、Vision、特殊 DNS 和内核专属路由功能，应按字段逐项验证。

移动端不建议为了测试频繁在不同客户端之间手工重建复杂节点。更可靠的方法是保留原订阅，在目标客户端重新导入，然后核对节点类型与关键字段。若订阅本身针对单一内核生成，应选择对应客户端。安装入口可在Android 客户端列表查看，两款客户端不要同时保持活动连接，以免虚拟网络接口和系统路由互相覆盖。

七、订阅、分享链接与原生 JSON 的兼容性

三种常见配置载体

单条分享链接通常以 vmess://、vless://、trojan:// 或 ss:// 开头，一条链接描述一个服务器。订阅链接则指向可更新的节点集合，客户端请求订阅后解析其中多条记录。原生 JSON 配置包含入站、出站、DNS、路由和策略等完整结构，表达能力最强，但不一定适合直接导入只接受服务器记录的订阅界面。三者用途不同，不能仅凭内容看起来都是文本就相互替代。

Base64 聚合订阅常见做法是把多条分享链接按行排列后再编码。Base64 只是编码，不提供协议转换能力。如果其中某条 VLESS 链接包含 REALITY 字段，客户端仍需认识这些查询参数。原生 JSON 订阅可能使用客户端自定义结构，字段名称与核心配置并不完全相同。判断订阅是否兼容，应先确定响应内容属于分享链接集合、客户端专用 JSON，还是完整核心配置。

各协议链接的关键字段

VMess 链接常见于编码后的 JSON 对象，包含地址、端口、用户 ID、网络类型、Host、路径、TLS 与服务器名称等信息。由于历史格式存在多个字段约定，转换工具之间容易对 host、sni 和路径作不同处理。VLESS 链接通常把 UUID 放在用户信息位置，并通过查询参数表达 encryption、security、type、flow、sni、fp、pbk 和 sid 等字段。REALITY 配置尤其依赖查询参数完整保留。

Trojan 链接以密码作为用户信息，查询参数可携带 SNI、传输类型、Host 与路径。密码中的特殊字符必须进行 URL 编码，否则井号后的内容可能被识别成节点备注，问号后的内容可能被识别成查询参数。Shadowsocks 链接既有把加密方法和密码整体编码的形式，也有分别表达用户信息的形式；部分链接还包含插件参数。客户端能识别 ss:// 前缀，不代表能支持其中指定的所有插件或 2022 方法。

订阅导入后节点为空

第一步在客户端中手动更新订阅分组，并查看更新提示是请求失败、内容为空还是解析结果为零。请求失败通常与订阅地址、网络路径或地址有效状态有关；响应有内容但节点为零，则更可能是格式不受支持。第二步确认复制的是订阅地址，而不是网页地址或单条节点备注。第三步检查地址前后是否混入空格、换行或中文标点。

如果只有部分节点缺失，应按协议分类检查。传统 VMess 能导入而 REALITY 节点消失，通常说明解析器没有保留新字段或内核能力不足；普通 Shadowsocks 能导入而 2022 方法缺失，可能是方法支持范围不同；Trojan 节点存在但无法连接，则继续核对密码、SNI 和传输参数。更完整的格式结构与转换思路可参考Base64、原生 JSON 与分享链接说明。

订阅更新与本地修改的冲突

订阅节点通常由远端记录管理。用户在客户端中手动修改订阅节点后，下一次更新可能覆盖本地字段。需要长期调整路由、DNS 或系统代理时，应优先修改客户端的全局设置或路由配置，而不是逐个改订阅节点。确实需要保留节点副本时，可以复制到本地分组，并清楚区分它与可更新订阅之间的关系。

订阅分组还可以用于区分不同配置来源，分别设置更新周期。更新不宜过于频繁，因为服务器列表通常不需要按分钟刷新，移动端频繁更新还会增加后台网络活动。节点备注可以帮助识别用途，但备注不参与协议认证。重命名节点不会改变服务器地址、公钥或密码，也不能修复底层字段缺失。

二维码、剪贴板与手动输入

二维码只是分享链接的图形载体。扫描成功后仍由客户端解析原始 URI，因此二维码清晰度只能影响读取，不能解决字段不兼容。剪贴板导入适合一次处理单条或多条完整链接，手动输入则适合核对少量字段。REALITY、WebSocket 与 gRPC 配置字段较多，优先使用完整导入，再进入编辑界面检查，通常比从零手填更可靠。

在 v2rayN 和 v2rayNG 中导入订阅的具体入口、手动更新时机与节点列表检查顺序，可继续阅读订阅链接导入教程。如果只是收到一条 vmess:// 或 vless:// 链接，则可参考分享链接与订阅的区别，避免把单条链接误填到订阅地址栏。

八、按使用场景选择协议并完成迁移验证

桌面常规使用

Windows、macOS 与 Linux 桌面端优先使用 v2rayN。已有稳定订阅时，先完整导入并使用订阅提供的协议组合，不必预先把所有节点改成同一类型。常规浏览和遵循系统代理的应用，可以先启用系统代理；只有不读取系统代理的程序需要接管时，再评估 TUN。节点选择先看能否稳定完成连接，再比较连续访问表现，避免用一次测速排序替代长期判断。

如果订阅同时提供 VMess、VLESS REALITY、Trojan 与 Shadowsocks，可以保留多个类型作为对照。使用 Xray 内核时，服务端提供的 VLESS、REALITY、Vision 组合通常具有较完整的功能匹配；已有 VMess 或 Trojan 稳定连接仍可继续使用；Shadowsocks 则应重点确认加密方法。协议名称不是质量等级，服务端维护和完整配置比名称新旧更重要。

移动端常驻连接

Android 上需要 Xray 扩展时选择 v2rayNG，需要 V2Fly 内核语义时选择 v2flyNG。移动端首先考虑稳定性、后台重连和电量，而不是开启尽可能多的功能。选择一个稳定节点，关闭不必要的批量测速，合理安排订阅更新。如果应用流量可以由系统提供的代理路径覆盖，就不必始终使用更重的 TUN 接管；必须使用 TUN 时，应简化路由规则并检查 DNS 是否重复处理。

移动网络与无线局域网切换后，原有 TCP 连接通常需要重建。短暂断线并不一定是协议故障；如果每次切换后长期无法恢复，再检查客户端后台权限、系统网络状态和节点重连日志。更换协议只能解决协议或握手层问题，无法修复系统暂停后台网络、订阅字段缺失或服务器不可达。

旧配置迁移到现代组合

从 VMess 迁移到 VLESS REALITY 时，应让服务端生成完整的新配置，并在客户端作为新节点导入。不要修改旧 VMess 节点的协议下拉框后继续沿用其 TLS、WebSocket 或用户字段。迁移需要同时核对 UUID、传输类型、REALITY 公钥、Short ID、服务器名称、指纹与 flow。旧节点应暂时保留，便于在同一网络下对照。

从传统 Shadowsocks 方法迁移到 2022 方法时，同样需要服务端和客户端同时更换，旧密码格式不能直接复用。Trojan 更换证书或域名后，需要更新服务器名称和可能关联的传输 Host。任何迁移都应先验证基本连接，再恢复复杂路由、TUN 和自定义 DNS；一次改动过多会让日志难以指向具体原因。

故障现象对应的优先检查项

一套可重复的验证流程

第一步，记录原配置的协议、传输、安全层和执行内核。第二步，导入新配置但暂不删除原节点。第三步，关闭复杂路由与额外 DNS 改写，只验证内核能否启动、服务器能否连接和基本域名能否访问。第四步，依次恢复系统代理、路由分流、DNS 与 TUN，每恢复一项就进行一次简单访问测试。第五步，观察网络切换和设备休眠后的恢复情况。第六步，再根据实际使用比较冷连接、连续访问与持续传输。

日志阅读也应遵循层次。配置解析错误位于启动阶段，应检查字段和内核；握手错误位于连接阶段，应检查凭据与安全层；域名解析错误应检查 DNS；只有特定应用无法访问时，应检查系统代理、TUN 与路由。把日志阶段和配置层次对应起来，可以避免将所有问题归结为“节点不可用”。

如果目标是尽快完成首次连接，按入门指南的主线操作即可；如果还未安装适配平台的客户端，可前往安装包页面选择 v2rayN、v2rayNG 或 v2flyNG。Windows 安装与桌面版、WPF 版差异可查看v2rayN Windows 安装配置全流程。完成连接后再回到本手册核对协议字段，通常比一开始同时修改内核、路由和传输参数更容易得到可解释的结果。