VMess、VLESS、Trojan、SS 与 REALITY 选型手册

一、协议选型框架：先拆开配置层次

协议名不是完整连接方案

客户端列表中的 VMess、VLESS、Trojan 或 Shadowsocks，首先描述的是应用层代理协议。一次实际连接还会同时包含地址与端口、用户凭据、传输方式、安全层、域名以及可选的路径等信息。只比较协议名称，无法判断两个配置是否能够互换，也无法直接推断连接速度。以 VLESS 为例，它可以运行在普通 TCP 之上，也可以与 TLS、WebSocket、gRPC 或 REALITY 组合；这些组合的握手过程、证书要求、数据封装和客户端支持范围并不相同。

选型时应把一条配置拆成四层。第一层是协议与认证，例如 VLESS 的 UUID、Trojan 的密码、Shadowsocks 的加密方法与密码。第二层是承载数据的传输方式，例如 TCP、WebSocket、gRPC。第三层是安全与身份确认，例如标准 TLS 或 REALITY。第四层是客户端和内核，即由 v2rayN、v2rayNG 或 v2flyNG 把界面字段转换为 Xray、V2Fly 可读取的配置。任一层不匹配，都可能表现为连接立即关闭、握手超时或导入后字段缺失。

从既有配置开始，而不是从偏好开始

客户端用户通常接收的是已经确定参数的分享链接或订阅。此时正确路径不是先挑一个看起来更新的协议，再尝试改写原配置，而是先确认服务端给出的协议和传输组合，再选择能够完整识别它的客户端与内核。服务端为 VMess 时，客户端应按 VMess 导入；服务端为 VLESS 与 REALITY 时，客户端不仅要支持 VLESS，还要能保存公钥、短标识、指纹和服务器名称等 REALITY 字段。单独修改客户端下拉框不会改变服务端能力。

如果能够同时选择服务端和客户端，则按兼容范围、配置复杂度、设备性能与维护成本排序。跨多种客户端共享时，优先考虑各端都能稳定解析的组合；希望使用 Xray 专属能力时，确认所有设备均运行兼容的 Xray 内核；低性能设备则减少不必要的多层封装。这里的“更简单”指字段更少、链路层次更少和排错边界更清楚，不等于某种协议在所有网络条件下必然更快。

二、VMess、VLESS、Trojan 与 Shadowsocks 的设计取舍

VMess：完整认证结构与时间一致性要求

VMess 起源于 Project V 早期协议体系，目标是在一套协议中完成用户身份识别、请求信息承载与数据保护。其配置通常使用 UUID 作为用户标识，并包含额外的协议握手结构。VMess 在 V2Fly 与 Xray 家族中都有较广泛的历史兼容基础，因此大量旧订阅和既有部署仍然使用它。对于需要延续旧配置、服务端暂不调整或多设备均已验证可用的环境，继续使用 VMess 通常比仅为追求新名称而迁移更稳妥。

VMess 认证过程依赖客户端与服务端时间处于合理偏差范围。设备时间、时区或自动校时异常时，可能出现地址和端口均正确但认证失败的情况。排查时应先恢复系统自动时间，再核对 UUID、alterId 兼容字段和传输参数。现代配置通常不需要依赖旧式 alterId 设计，但导入历史订阅时仍可能看到该字段。客户端能够显示字段，不代表服务端仍按相同旧行为工作，迁移时应以服务端当前配置为准。

VLESS：精简协议职责，能力交给组合层

VLESS 是 Xray 生态的重要协议之一，设计重点是减少协议自身承担的数据加密职责，把传输安全交给 TLS、REALITY 或其他明确的安全层。VLESS 使用 UUID 等信息完成用户识别，但其本身不应被理解为一个独立完成全部安全保护的封闭方案。实际部署必须连同传输方式和安全层一起描述，例如 VLESS over TCP with TLS，或者 VLESS over TCP with REALITY。

这种职责分离让 VLESS 配置更容易组合 Xray 的流控等能力，也减少某些重复处理。代价是选项之间存在明确约束：服务端没有配置 flow 时，客户端不能凭空增加；使用 REALITY 时，需要同时提供公钥、短标识和服务器名称；使用标准 TLS 时，则要按证书身份核对域名。VLESS 的优势主要体现在 Xray 功能组合和清晰的协议分层，而不是“选择 VLESS”一个动作就自动改善所有链路。

Trojan：以密码认证配合标准 TLS

Trojan 通常以密码作为用户凭据，并依赖 TLS 建立安全连接。它的概念模型较直接：客户端连接 TLS 服务，随后在协议层提交认证和目标信息。配置时最重要的不是密码字段本身，而是域名、服务器名称、证书校验和端口必须形成一致关系。直接把地址替换为另一个主机、保留原服务器名称，或者关闭必要的安全选项，都可能破坏原有身份校验逻辑。

Trojan 在多个内核生态中具有支持基础，适合已有标准 TLS 配置并希望维持较清晰参数结构的场景。它并不等于任意 TLS 服务，也不能把普通 HTTPS 地址直接当作 Trojan 节点。客户端导入后应确认安全项仍为 TLS、SNI 没有丢失、密码未被截断。若订阅转换工具只保留“地址、端口、密码”而遗漏传输层字段，生成的条目即使出现在列表中也无法代表原配置。

Shadowsocks：轻量结构与加密方法一致性

Shadowsocks 常简称 SS，其核心字段是服务器、端口、加密方法和密码。相较于组合层次较多的 VLESS 或 VMess 配置，基础 Shadowsocks 条目的字段较少，通常具备较低的配置理解成本。性能表现与所选加密方法、具体实现、处理器指令能力以及链路质量有关。较新的 AEAD 加密方法能提供明确的数据机密性与完整性语义，但客户端与服务端必须使用完全相同的方法名称和密码。

Shadowsocks 生态存在不同扩展与插件组合。基础 SS 支持并不代表内核支持某个特定扩展；订阅导入成功也不代表扩展字段被保留。使用 v2rayN 或 Android 客户端时，应在编辑条目中检查加密方法、插件参数和传输附加项。若目标是三款客户端之间转移配置，基础字段通常更容易保持一致，而带特定插件的条目应逐端验证。选择时应把“协议兼容”和“扩展兼容”分开记录。

三、传输方式、TLS 与 REALITY：组合关系和字段边界

TCP、WebSocket 与 gRPC 负责怎样承载数据

传输方式决定协议数据如何放入底层连接。TCP 通常具有较少的附加封装，参数也相对集中；WebSocket 在 HTTP 升级流程之上承载双向数据，配置中常见路径和 Host；gRPC 基于 HTTP/2 语义，常见字段是服务名与多路复用相关设置。三者不是仅靠客户端偏好即可切换的“速度档位”，服务端必须监听同一种传输并使用相同参数。把 WebSocket 条目改成 TCP，通常不会产生一个等价配置。

传输层对性能的影响来自握手次数、封装开销、连接复用方式以及中间网络设备行为。对于短连接密集场景，建立连接的成本更明显；对于持续大流量，链路质量、拥塞控制和服务端负载往往更重要。WebSocket 路径必须逐字符对应，gRPC 服务名也不能省略。客户端中的 Host、SNI 和地址可能看起来相似，但它们承担的职责不同：地址用于找到服务器，Host 属于应用层请求信息，SNI 用于 TLS 握手中的服务器名称。

标准 TLS：证书身份与服务器名称

TLS 为上层协议提供加密通道和服务端身份验证。配置里的服务器名称通常需要与证书可验证的名称一致，而连接地址可以是域名或在特定配置下使用的其他地址。客户端默认进行证书验证时，会检查证书有效期、信任链和名称匹配。遇到证书错误，优先核对系统时间、SNI、域名拼写和服务端证书配置，不应把关闭验证作为常规修复方式，因为那会改变原配置的身份确认条件。

ALPN 用于在 TLS 握手时协商上层协议，例如 HTTP/2 或 HTTP/1.1。该字段是否需要手动填写取决于传输组合和服务端设定。订阅提供了 ALPN 时应保留原值；没有明确要求时，不宜为了“参数更多”而随意添加。客户端允许多选并不表示所有组合均被服务端接受。类似地，指纹选项描述 TLS 客户端握手特征，属于连接实现细节，必须与所用内核及服务端方案相容。

REALITY：Xray 安全层及其必要参数

REALITY 是 Xray 体系中的安全层能力，通常与 VLESS 等配置组合。它不是独立代理协议，因此在客户端创建条目时，协议类型仍可能显示为 VLESS，安全项则选择 REALITY。常见参数包括服务器名称、公钥、短标识和客户端指纹；某些组合还会使用 flow。公钥用于客户端验证 REALITY 服务端身份，短标识用于服务端配置中的匹配，服务器名称参与握手语义。任何字段被订阅转换过程遗漏，都可能导致握手无法完成。

公钥与 UUID 承担不同职责。UUID 属于 VLESS 用户认证，REALITY 公钥属于安全层身份确认，两者不能互换。短标识通常是规定格式的十六进制字符串，其长度与可选值由服务端决定；客户端应原样保存，不自行补零或改变大小写结构。服务器名称也不是备注名，它必须符合服务端配置。使用 v2rayN 编辑 REALITY 条目时，应依次检查协议、地址、端口、用户 ID、security、SNI、publicKey、shortId、fingerprint 与 flow。

{
  "protocol": "vless",
  "address": "server.example.com",
  "port": 443,
  "id": "00000000-0000-4000-8000-000000000001",
  "network": "tcp",
  "security": "reality",
  "serverName": "www.example.com",
  "publicKey": "示例公钥需替换为服务端提供值",
  "shortId": "1a2b3c4d",
  "fingerprint": "chrome",
  "flow": "xtls-rprx-vision"
}

上面的片段用于展示字段之间的层次，不是可以直接连接的节点。实际值必须来自对应服务端配置。客户端界面可能使用中文字段名，也可能把这些内容分布在“传输设置”“TLS 设置”或“REALITY 设置”面板中，但字段语义不变。分享链接中的参数名还可能采用缩写，例如 pbk 对应公钥、sid 对应短标识、fp 对应指纹。手工比对时应先建立字段映射，再判断是否遗漏。

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

协议开销只是总耗时的一部分

用户感知的连接速度由域名解析、网络往返时间、握手过程、服务端负载、线路拥塞、传输封装和本机处理共同决定。协议只影响其中一部分。两条配置采用不同协议但服务器位置、出口负载和链路质量也不同，测速结果不能用于单独证明协议优劣。可靠比较需要保持服务器、端口链路、测试时间、目标资源和客户端版本条件尽量一致，并重复观察连接建立时间、持续传输和失败重试情况。

基础 TCP 传输通常具有较少的应用层封装，但并不保证在所有环境中获得最低延迟。WebSocket 和 gRPC 增加了相应协议层处理，同时也改变连接复用及中间链路行为。TLS 与 REALITY 都有握手和密码学计算，现代桌面处理器通常能较快完成这些工作；在低功耗移动设备上，频繁断开重连比维持稳定连接更容易放大能耗。因而减少无效重试、保持系统时间正确和避免错误的域名解析，往往比争论单次加密操作更有实际价值。

CPU、内存与连接数量

资源占用不能只按协议名称排序。内核需要维护连接状态、路由规则、DNS 缓存、日志和可选的 TUN 网络栈；客户端界面还会执行订阅更新、列表渲染和统计展示。大量并发连接、复杂正则规则、过细的日志级别以及频繁健康检查，都会提高 CPU 唤醒和内存使用。基础 Shadowsocks 配置通常字段较少，处理路径容易理解；VLESS 配合简洁传输也可以保持较低额外开销；多层传输与复杂路由则需要更多状态管理。

桌面端观察资源占用时，应区分 v2rayN 图形进程和 Core 进程。界面内存增长不必然表示协议内核存在问题，反之亦然。先停止自动更新和额外检查，再用同一条配置复测，可以判断后台任务是否参与。日志级别建议在日常使用时保留必要信息，排错时临时提高详细程度，完成后恢复。持续记录完整访问日志会增加磁盘写入和处理负担，也会让真正的错误行更难定位。

Android 设备的电量判断

Android 上的 v2rayNG 或 v2flyNG 通常需要通过系统 VPN 接口接管流量。电量消耗不仅来自加密，还来自网络保持、应用流量总量、无线网络状态切换、DNS 请求和后台唤醒。屏幕关闭后若连接频繁重建，应先检查系统对客户端的后台运行限制、网络切换和订阅自动更新频率。仅替换协议但保留不稳定链路，通常无法解决重连造成的耗电。

TUN 或 VPN 接管范围也会影响处理量。设备上所有应用流量均进入客户端时，内核要处理更多连接；按系统能力和实际需求减少不必要的后台应用流量，可以降低总工作量。路由规则过于庞大或包含大量需要域名解析的规则，也会增加判断成本，但常规规模下通常不是首要瓶颈。更有效的排查顺序是：确认连接是否持续稳定，观察是否存在循环重试，再检查日志级别、自动更新、DNS 与路由，最后才比较协议组合。

协议选择最终应以稳定性、兼容性和维护成本为优先，性能数据作为同条件下的补充证据。若一条现有 VMess 配置长期稳定，迁移到 VLESS 并非紧急操作；若需要 REALITY 或特定 Xray 流控，则应把内核升级与全端兼容检查纳入迁移计划。遇到异常资源占用时，可结合帮助中心的故障分类进行排查，不要同时修改协议、DNS、路由和系统代理，以免失去可比较基线。

五、V2Fly 与 Xray 内核家族关系

共同来源与独立演进

V2Fly 与 Xray 都继承了 Project V 生态中的配置思想和多协议代理能力，因此在 VMess、部分 VLESS、Shadowsocks、路由规则与出站结构上能看到相近概念。两者后来形成独立维护方向，功能增加、字段含义和实现细节并不会始终同步。共同来源能够解释为什么许多基础配置结构相似，但不能推导出两套内核对所有扩展功能完全互换。

Xray 更集中地发展了 REALITY、XTLS Vision 等能力，并在 Xray 客户端生态中形成相应字段。V2Fly 则保持自己的发布、协议实现与功能路线。对普通用户而言，最重要的结论是：基础 VMess、Shadowsocks 或标准传输配置可能具有较好的跨内核可迁移性；带有 Xray 专属安全层、flow 或特定扩展字段的配置，应明确选择 Xray Core。配置文件能被解析，只表示语法层面可能成立，并不保证运行语义一致。

三款客户端与内核定位

v2rayN 是本站桌面端首推客户端，覆盖 Windows、macOS 与 Linux，提供服务器列表、订阅分组、路由设置、系统代理和 Core 类型管理等图形入口。面对含 REALITY 的 VLESS 配置，应在 v2rayN 中选择支持该能力的 Xray Core，并确认导入后的安全字段完整。桌面端需要同时管理多组订阅、细分路由和系统代理时，v2rayN 的集中设置结构更适合作为主要管理端。

v2rayNG 是 Android 上采用 Xray 能力路线的客户端，适合与桌面 v2rayN 共享 VLESS、REALITY 等 Xray 配置。v2flyNG 则以 V2Fly 内核家族为主要定位，适合使用对应内核支持的 VMess、Shadowsocks 和其他兼容配置。二者的名称相近，但不能仅凭界面字段相似判断功能一致。服务端条目依赖 Xray 专属字段时，优先使用 v2rayNG；明确需要 V2Fly 行为或已有 V2Fly 配置基线时，再选择 v2flyNG。

配置兼容的三个层次

判断兼容性应分为语法、功能和行为三个层次。语法兼容表示 JSON 字段或分享链接能够被识别；功能兼容表示内核真正实现对应协议、传输和安全层；行为兼容表示相同配置在 DNS、路由、连接复用和错误处理上达到预期结果。很多迁移问题发生在把第一层误认为第三层，例如导入工具成功生成条目，但忽略了不受支持的字段，直到连接时才暴露问题。

配置文件迁移还要注意出站标签、路由引用和 DNS 结构。协议节点本身可用，不代表原有路由规则能直接复制。规则中的 outboundTag 必须指向实际存在的出站标签；DNS 查询策略和域名解析模式也可能影响分流判断。使用图形客户端时，优先通过客户端界面创建或导入配置，让客户端生成与当前 Core 匹配的结构。只有需要定位具体字段时，再导出配置并进行只读比对。

xray run -test -config ./config.json

上面的测试命令用于让已安装的 Xray Core 检查配置语法，不会替代实际连接测试。命令成功表示配置能够通过基础解析，不表示地址可达、凭据正确或安全层握手必然成功。v2rayN 用户通常可直接查看日志中的 Core 启动结果；手工命令更适合定位未知字段、JSON 结构或标签引用错误。测试时应使用客户端实际生成的临时配置副本，避免修改正在运行的配置文件。

六、订阅格式、分享链接与字段兼容性

订阅是配置容器，不是协议

订阅地址用于返回一组节点或客户端配置，订阅本身并不是 VMess、VLESS 等代理协议。一个订阅可以同时包含多种协议条目，也可以采用特定客户端能够识别的结构。用户看到“订阅更新成功”，只表示客户端完成了请求和基础解析；还需要检查条目数量、协议类型、备注、传输方式与安全字段是否完整。若列表为空，应区分地址访问失败、返回内容为空、格式不受支持和分组筛选错误。

常见分享链接以协议方案开头，例如 vmess://、vless://、trojan:// 或 ss://。不同方案的参数组织方式不同。VLESS 和 Trojan 链接通常可在查询参数中携带传输、安全层、SNI、指纹等信息；VMess 历史格式常把一组 JSON 字段编码后放入链接；Shadowsocks 链接则重点保存加密方法、密码、地址和端口，并可能附加插件参数。复制时任何截断、转义变化或二维码识别缺失都可能造成字段丢失。

通用订阅与客户端专用格式

所谓通用订阅通常是多行分享链接或被编码后的链接集合，优势是结构直观、容易在多款客户端间传递，限制是难以完整表达复杂路由、DNS 与客户端专属策略。客户端专用配置可以包含分组、规则和界面选项，但迁移到另一客户端时往往只能保留节点主体。选择订阅格式时，应先确定共享目标：只同步服务器条目，还是连同路由与 DNS 策略一起迁移。

对于 v2rayN、v2rayNG 与 v2flyNG，最稳妥的跨端方式是让订阅提供每端都支持的节点字段，并在各客户端分别维护本地路由。桌面端的系统代理模式、Android 的系统 VPN 接管方式和应用分流能力并不相同，强行把整套客户端设置包装成同一订阅，容易产生语义偏差。节点订阅负责地址、协议和传输；设备本地负责代理接管、DNS 与路由，这种职责划分更容易排错。

订阅转换的收益与信息损失

订阅转换可把一种容器格式整理为另一种格式，也可执行重命名、筛选或分组。但转换过程只有在目标格式能表达源字段时才是无损的。VLESS REALITY 条目需要保留 security、SNI、publicKey、shortId、fingerprint 和 flow；WebSocket 需要保留 path 与 Host；gRPC 需要保留 serviceName。若转换后的目标模板没有对应字段，工具可能忽略它们，而不是主动报告错误。

验证转换结果时不要只对比节点备注。应随机选择每种协议至少一个条目，打开编辑面板逐项核对协议、地址、端口、认证字段、传输、安全层和扩展参数，再进行连接测试。原订阅与转换订阅应放入不同分组，避免同名节点覆盖。确认全部协议类型都能正确工作后，再切换日常使用分组。遇到转换后 VLESS 可导入但 REALITY 失败的情况，优先检查安全层附加参数，而不是反复更新订阅。

更新、覆盖与本地修改

订阅节点通常由远端内容管理。用户在客户端内直接修改订阅条目后，下次更新可能恢复为订阅原值。需要长期保留的自定义设置应放在独立的本地条目或客户端支持的覆盖规则中。修改前复制条目并更改备注，可以保留对照基线。若只是调整系统代理、路由模式或活动分组，则通常属于客户端本地状态，不必改动节点协议字段。

订阅更新失败时，先检查地址是否完整以及对应分组是否启用，再查看客户端日志中的 HTTP 状态、解析错误或证书错误。不要把订阅地址粘贴进“手动添加服务器”的地址字段，也不要把单个分享链接误当作一定能定时更新的订阅。完整操作流程可参考使用指南中的订阅导入步骤；关于列表为空和分组选择的问题，可继续查阅帮助中心。

七、在 v2rayN、v2rayNG 与 v2flyNG 中落实协议选择

v2rayN：先检查 Core，再检查节点编辑页

v2rayN 是桌面端的主要选择。导入节点后，先在设置中确认 Core 类型，再打开服务器编辑页核对字段。VMess 重点检查用户 ID、传输方式和安全项；VLESS 需要继续检查 encryption、flow 与 REALITY 或 TLS 面板；Trojan 检查密码、TLS 与服务器名称；Shadowsocks 检查加密方法和密码。客户端列表中的备注只用于识别，不参与协议认证，因此备注显示正常不能说明配置完整。

启用连接前，应把节点设置与系统代理设置分开。选择活动服务器只决定 Core 使用哪个出站配置，系统代理决定支持系统代理的应用是否把请求交给客户端，路由规则决定连接走代理出站、直连出站或其他已配置出口。三者属于连续但不同的环节。节点测试失败时先看协议日志；节点已连接但应用未接管时再看系统代理；只有部分域名路径不符合预期时再检查路由。

v2rayNG：核对分享链接中的完整参数

v2rayNG 导入 VLESS REALITY 链接时，应进入配置详情确认安全类型、SNI、公钥、短标识、指纹和 flow 均存在。二维码识别或剪贴板导入后，如果某一字段为空，应回到原分享内容核对，不要随意从另一节点复制。不同节点的公钥和短标识与各自服务端绑定，外观相近也不能混用。VMess 条目则需额外关注设备时间和传输参数，Shadowsocks 条目重点核对加密方法。

Android 的连接按钮启动系统 VPN 接管，并不改变节点协议。连接后若所有应用均无网络，应先观察日志中 Core 是否启动、配置是否通过解析和握手是否完成；若只有特定应用表现不同，再检查系统级限制与应用分流。频繁切换多个协议条目会让日志交错，排错时应固定一个已核对的节点，清空或记录当前日志时间，再执行一次明确的连接操作。

v2flyNG：按 V2Fly 功能范围选择条目

v2flyNG 适合作为 Android 上的 V2Fly 内核客户端。导入前应先判断配置是否依赖 Xray 专属功能。基础 VMess、受支持的 Shadowsocks 以及 V2Fly 已实现的协议传输可按实际配置核对；带 REALITY 或特定 Xray flow 的 VLESS 条目不应仅因协议名称可见就认定兼容。若同一订阅混合多类条目，可以建立独立分组，只把经过验证的兼容节点用于 v2flyNG。

在两个 Android 客户端之间比较时，应使用同一条基础兼容配置，并保持 DNS、路由和网络条件接近。若一端导入后字段缺失，结论应记录为格式或功能不兼容，而不是简单归因于网络。客户端选择的目标是匹配内核能力，不是让每台设备强制使用同一应用。Xray 配置优先 v2rayNG，V2Fly 配置优先 v2flyNG，这种明确分工比反复转换更容易维护。

从日志定位配置层级

日志中的错误通常可按阶段分类。配置解析阶段会出现未知字段、格式错误、出站标签不存在等信息；DNS 与连接阶段会出现名称解析失败、连接被拒绝或超时；TLS 与 REALITY 阶段会出现证书名称、密钥或握手问题；协议认证阶段则与 UUID、密码或服务端用户配置有关。先确定失败阶段，再回到对应字段，效率高于逐项随机切换。

排错过程中每次只改变一个变量。例如先保持协议与传输不变，仅修正 SNI；再次测试后再检查公钥。不要同时更换 Core、节点、DNS 和路由模式，因为成功后无法确认真正原因，失败后也会扩大范围。若需要向他人描述问题，应记录客户端名称、Core 家族、协议、传输、安全层、错误阶段和日志中的关键错误类别，凭据部分则应隐藏。

尚未安装对应客户端时，可在客户端页按 Windows、macOS、Android 或 Linux 选择软件包。桌面环境优先使用 v2rayN；Android 再按 Xray 与 V2Fly 内核需求选择 v2rayNG 或 v2flyNG。安装完成后的订阅导入、系统代理和连接验证属于使用指南范围，本章只负责把协议选型结果映射到客户端设置。

八、按使用场景选型、迁移与故障回退

既有配置稳定：保持协议，优先减少变更

已经稳定使用的 VMess、Trojan 或 Shadowsocks 配置，没有必要只因协议名称变化而立即迁移。先记录当前客户端、Core、传输、安全层、DNS 和路由基线，之后再评估迁移能解决什么具体问题。若目标只是更换设备，可以在新设备导入同一配置并核对字段；若目标是使用 REALITY 或 Vision，则属于服务端与客户端共同变更，应安排独立测试条目，而不是覆盖原节点。

稳定配置的价值在于提供可比较基线。新条目测试失败时，可以切回旧条目确认本地网络、系统代理和客户端整体仍可工作。若旧条目也同时失败，则问题可能不在新协议本身。迁移期间保留原订阅分组、原 Core 设置记录和关键字段清单，可以快速判断变化发生在哪一层。待新配置在所有目标设备完成验证后，再逐步停止使用旧条目。

桌面多平台：以 v2rayN 和共同能力为中心

Windows、macOS 与 Linux 桌面需要统一操作习惯时，可优先使用 v2rayN 管理订阅和路由。协议选择应先取三套桌面环境都能稳定运行的 Core 与传输组合，再考虑平台差异。基础 VLESS 配合标准安全层、既有 VMess、Trojan 或基础 Shadowsocks 都应按服务端参数逐项验证；使用 REALITY 时，确保每个平台的 v2rayN 均调用兼容 Xray Core，并能保存完整字段。

跨平台同步不等于复制整个客户端目录。系统代理实现、证书存储、网络接口和开机启动方式存在平台差异，更适合分别配置。订阅负责同步节点，路由规则可按业务需求建立可读的规则集，系统级设置则留在本机。Linux 桌面部署与自启动可参考技术笔记v2rayN Linux 桌面安装，协议字段仍以本页的分层方法核对。

Android 与桌面共享：先确定内核交集

桌面 v2rayN 与 Android v2rayNG 共享配置时，Xray 能力交集通常最清晰，适合需要 VLESS REALITY 的场景。若 Android 端使用 v2flyNG，则应选择 V2Fly 明确支持的协议与传输，不把 Xray 专属参数带入共同配置。一个订阅可以包含多类节点，但建议用备注或分组标明内核需求，例如“Xray 配置”和“V2Fly 兼容配置”，避免仅凭协议名误选。

移动端更应关注稳定连接和后台行为。若配置在桌面正常、Android 失败，先比较导入后的字段，再看系统 VPN 启动和设备网络，不要立即判定服务端异常。若 Android 能建立连接但耗电明显，按前文顺序检查重连、网络切换、自动更新和日志，而不是首先替换加密协议。跨设备选型的目标是参数一致、内核匹配和故障边界明确。

复杂订阅：按协议抽样验证

订阅同时包含 VMess、VLESS、Trojan 与 Shadowsocks 时，不应只测试列表第一项。先按协议分类，每类选择一个字段完整的条目；再按传输分类，至少覆盖 TCP、WebSocket 或订阅实际提供的其他方式；最后单独检查 TLS 与 REALITY。这样能够判断故障是某个节点、某类协议、某种传输还是整个订阅格式造成。测试结果应记录到分组或备注中，而不是依赖短期记忆。

若同一协议中只有 REALITY 条目失败，应检查 Xray Core 和 REALITY 参数；若所有 WebSocket 条目失败而 TCP 正常，应比较路径、Host 和 TLS；若各协议都无法解析，则回到订阅响应和格式层。按层分类能减少无关修改。更多协议与客户端横向差异可阅读v2rayN、v2rayNG、v2flyNG 怎么选。

迁移执行清单与回退条件

正式迁移可分为准备、并行验证、切换和观察四个阶段。准备阶段记录旧配置，不删除可用分组；并行阶段添加新条目，在相同网络条件下测试解析、握手、持续连接和常用应用；切换阶段只改变活动节点，保持 DNS 与路由不动；观察阶段再逐步应用新的路由或系统设置。每个阶段都有明确回退点，出现异常即可恢复旧活动节点，而无需重新构建全部配置。

回退条件包括：目标客户端无法保存必要字段、Core 不实现所需能力、订阅更新持续覆盖本地修正、移动端频繁重连，或多平台中任一关键设备无法稳定运行。回退不是协议优劣判断，而是当前组合尚未满足兼容要求。保留旧方案后，可以单独修正服务端、订阅格式或客户端设置，再开始下一轮验证。

完成协议决策后，可前往使用指南执行订阅导入、节点选择、系统代理和连接验证。遇到连接失败、列表为空或路由不生效，可在帮助中心按错误阶段查找处理路径。需要进一步设计国内外分流规则时，参考v2rayN 国内外分流实战，将节点协议与路由策略分别维护。