V2Ray 协议、内核与客户端选型手册

01 / DECISION MODEL

先建立协议选型的判断模型

协议、传输、安全层和客户端不是同一层

看到一条节点信息时，先把它拆成四层。第一层是代理协议，例如 VMess、VLESS、Trojan 或 Shadowsocks，它规定客户端如何认证、如何组织连接以及服务端怎样识别请求。第二层是传输方式，例如 TCP、WebSocket、gRPC，它决定数据怎样承载在网络连接中。第三层是安全层，例如 TLS 或 REALITY，它负责握手身份、加密通道或特定的连接验证。第四层才是客户端与内核：v2rayN、v2rayNG、v2flyNG 提供界面，V2Fly 或 Xray 负责真正解析配置并建立连接。

这四层可以组合，但不能随意互换。VLESS 是协议，REALITY 是由 Xray 体系实现并与特定传输形态配合的安全方案，所以“VLESS”和“REALITY”不是两个完全平行的选项。类似地，WebSocket 不是代理协议，TLS 也不是节点类型。客户端订阅中常见的“VLESS + TCP + REALITY”实际上是三层组合。遇到导入后字段很多的情况，按层检查比逐个猜参数更可靠。

选型顺序应从兼容性开始

协议选择的第一项不是理论速度，而是服务端与客户端内核是否共同支持。服务端只提供 VMess 时，客户端侧讨论 VLESS 的开销优势没有实际意义；订阅给出 REALITY 参数时，则需要确认当前客户端使用的内核能够识别相关字段。兼容性通过后，再比较网络环境、设备资源、连接数量和维护难度。最后才看极限吞吐，因为多数日常差异来自线路质量、握手重试、域名解析和传输层配置，而不是协议名称本身。

一个稳妥的检查顺序是：先识别链接方案名，再确认客户端内核，随后查看传输与安全字段，最后检查地址、端口和认证信息。不要只根据节点显示名称判断协议。显示名称是订阅提供方写入的标签，可以包含任意文字；真正决定解析方式的是链接方案和配置中的 protocol、network、security 等字段。

稳定性是整条链路的结果

同一协议在不同配置下可能表现完全不同。TCP 直连通常结构简单，额外处理少；WebSocket 便于与常见 Web 服务部署方式配合，但有帧封装成本；gRPC 基于 HTTP/2，连接管理能力较强，也会带来更复杂的参数关系。TLS 的证书名称、系统时间和 SNI 必须相互匹配，否则协议本身配置正确也无法完成握手。REALITY 则要求客户端与服务端对短标识、公钥、服务名称等字段保持一致。

因此，选型时应记录“协议 + 传输 + 安全层 + 内核”完整组合，不要只记录一个缩写。排错时也按相同顺序回查。若导入成功但无法连接，先确认客户端是否识别了协议，再确认传输字段是否完整，最后查看安全层参数。若所有字段一致，再检查 DNS、系统代理和本地端口。更具体的错误现象可转到疑难解答逐项核对。

02 / VMESS

VMess：完整认证体系与成熟兼容面

设计背景与协议职责

VMess 是 Project V 早期生态中具有代表性的协议。它把用户标识、请求信息和时间相关的认证过程放入协议设计，客户端与服务端通过 UUID 等信息识别用户。其主要特点不是“某一种固定加密算法”，而是一套包含认证、请求封装和连接协商的完整机制。由于出现较早，许多 V2Ray 配置、订阅生成器和图形客户端都能识别 VMess，历史兼容面较广。

VMess 配置通常包含服务器地址、端口、用户 UUID、alterId、传输方式与安全层。当前配置中常见的 alterId 多为零，但旧订阅可能仍携带其他值。客户端导入时不应擅自改动该字段，因为服务端设置与客户端必须一致。加密选项常见为 auto，实际行为由内核按配置处理。若订阅能够正常更新但 VMess 节点全部连接失败，优先核对系统时间，因为时间偏差可能直接影响认证阶段。

VMess 的优势与代价

VMess 的优势在于资料成熟、配置工具覆盖广、V2Fly 与 Xray 通常都能处理常见组合。对于需要在不同客户端之间迁移、服务端仍采用传统 V2Ray 配置、订阅格式已经稳定运行的场景，继续使用 VMess 往往比主动改协议更省事。它也能与 TCP、WebSocket 等传输方式组合，并可叠加 TLS。对维护者而言，已有部署若运行稳定，没有必要仅因为出现了新协议就立即迁移。

代价主要来自协议处理相对复杂，认证与封装步骤比轻量设计更多。在计算能力充足的桌面设备上，这种差异通常不明显；在低功耗设备、高并发连接或频繁唤醒的移动环境中，额外处理会更容易被观察到。不过，实际耗电和速度仍受网络质量支配。连接反复失败导致的重试，往往比单次协议计算消耗更多资源，因此“配置可稳定完成握手”比纸面开销更重要。

常见字段怎样核对

先检查地址和端口是否被完整导入，再检查 UUID 是否保持原样。UUID 应符合标准分段形式，复制时不能带多余空格。随后查看传输层：如果服务端使用 WebSocket，客户端的路径和 Host 必须对应；如果叠加 TLS，SNI 或 serverName 应与证书覆盖的名称一致。客户端里显示的备注不参与连接，可自由修改，但其他字段不要为了“看起来更简洁”而删除。

{
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "server.example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-2222-4333-8444-555555555555",
            "alterId": 0,
            "security": "auto"
          }
        ]
      }
    ]
  }
}

上面的片段只展示 VMess 出站中的核心层级。完整配置还需要流量入口、传输参数和路由部分。手动录入时，界面字段与 JSON 名称可能不同，例如“用户 ID”对应 id，“额外 ID”对应 alterId。只要含义一致即可，不必追求界面文字和底层字段逐字相同。

哪些情况下保留 VMess

服务端已稳定运行、订阅在多台设备间使用、客户端同时存在 V2Fly 与 Xray 内核时，VMess 是偏保守的兼容选择。尤其当配置包含传统 WebSocket 与 TLS 组合，而运维目标是减少迁移变量，优先保持现状更合适。若新建配置并且客户端、服务端都明确支持 VLESS，则可以进一步比较认证开销和安全层选择，但这不意味着 VMess 已失去使用价值。

排查 VMess 时，先区分“导入失败”和“握手失败”。导入失败通常是链接编码、订阅内容或客户端解析问题；握手失败则更多关联时间、UUID、传输路径、TLS 名称和端口。不要在两个阶段之间来回修改全部参数。一次只改一项，并记录改动前后的结果，才能确认真正的故障点。

03 / VLESS + REALITY

VLESS 与 REALITY：轻量协议和安全层组合

VLESS 为什么采用更轻的设计

VLESS 将协议认证与传输安全更明确地分开。它使用 UUID 识别用户，但不在协议内部承担与 VMess 相同的加密职责，而是把通道安全交给 TLS、REALITY 等外层方案。这样的分层让协议本体更简洁，也便于内核根据传输与安全层组合功能。需要注意，“协议本身更轻”不等于可以省略安全层；是否需要 TLS 或 REALITY，应由完整部署方案决定。

在客户端中，VLESS 节点常包含地址、端口、UUID、流控、传输网络、安全类型、服务名称和指纹等字段。字段之间存在组合约束。例如某些流控值只适用于特定传输和安全层；REALITY 会额外要求公钥、短标识、serverName 等信息。订阅若漏掉其中一项，客户端可能仍能创建节点，但握手阶段会失败。因此，判断导入是否完整不能只看列表中是否出现节点。

REALITY 的位置与参数关系

REALITY 不是独立代理协议，而是 Xray 体系中的安全与握手机制，常与 VLESS 组合。客户端需要使用能够解析相应字段的 Xray 内核。配置中的 publicKey 用于客户端验证，shortId 用于匹配服务端设置，serverName 参与握手目标选择，fingerprint 则描述客户端握手指纹策略。这些字段不是可互相替代的别名，必须分别对应服务端配置。

REALITY 配置最常见的问题是字段存在但值错位。例如把服务器地址填入 serverName，把节点 UUID 当作公钥，或复制短标识时漏掉字符。还有一种情况是订阅链接包含参数，但旧内核忽略了无法识别的字段，界面看似导入成功，实际配置并不完整。遇到这种情况，先确认客户端当前内核类型，再重新导入；不要只在原节点上反复切换系统代理。

性能预期要保持具体

VLESS 的协议处理较轻，在高吞吐、较多并发连接或低功耗设备上具有合理的理论优势。但用户看到的连接速度由多项共同决定：往返时延影响握手耗时，丢包影响重传，服务端 CPU 与带宽影响持续传输，传输方式决定额外封装，DNS 影响首次访问。若线路本身波动明显，更换 VMess 与 VLESS 未必能产生稳定可见的差异。

REALITY 的握手参数更多，首次配置时比普通 VLESS + TLS 更容易因字段缺失失败；一旦参数正确，日常使用并不需要反复调整。维护重点应放在内核支持和订阅字段完整性上。升级客户端后如果旧节点仍正常，不必重新创建；若订阅更新后突然失败，则比较更新前后的 serverName、公钥、短标识和流控字段，通常比全量重装客户端更有效。

适合采用这一组合的条件

新建节点、服务端明确提供 VLESS + REALITY、桌面端使用 v2rayN 或 Android 端使用带 Xray 内核的 v2rayNG 时，这一组合具有清晰的支持路径。若 Android 端使用 v2flyNG，则应先确认订阅中的协议和安全层是否属于 V2Fly 支持范围，不能假设名称相近就能直接兼容。需要跨内核共享同一订阅时，普通 VLESS + TLS 或成熟 VMess 组合有时更容易保持一致。

最终判断标准不是“是否更先进”，而是服务端、内核和订阅三方能否稳定表达同一组参数。选择后应做三次确认：客户端能完整显示安全字段；连接日志没有未知配置项；连续断开重连后仍能恢复。通过这三项，再将节点设为常用配置。

04 / TROJAN + SHADOWSOCKS

Trojan 与 Shadowsocks：两种不同的简化路线

Trojan 的设计取向

Trojan 使用密码完成用户认证，并依赖 TLS 建立安全连接。它的配置概念相对直接：服务器地址、端口、密码、SNI、证书验证和传输设置构成主要部分。与 VMess 的时间相关认证相比，Trojan 更依赖 TLS 层是否正确；与 VLESS 相比，它通常不使用 UUID，而是使用密码字段。客户端界面若同时提供“密码”和“用户 ID”，应确认当前节点类型，避免把认证信息填入错误位置。

Trojan 的连接问题常集中在 TLS。系统时间偏差、SNI 与证书名称不一致、端口错误、证书链异常，都可能在代理请求开始前终止连接。配置中的 allowInsecure 控制证书验证行为，不应把它当作普遍的修复开关。正常证书配置应优先保持严格验证；只有在明确理解服务端证书安排并进行短时诊断时，才考虑改变该项，而且诊断结束后应恢复预期设置。

Shadowsocks 的核心结构

Shadowsocks 常简称 SS，核心配置由服务器、端口、密码和加密方法组成。它不使用 VMess 或 VLESS 的 UUID 模型，服务端与客户端必须选择完全一致的加密方法。由于配置项少、协议处理直接，SS 在资源有限设备和简单连接场景中通常具有较低的管理成本。与此同时，功能边界也更清晰：需要复杂传输组合时，应确认所用内核和服务端是否通过额外机制提供支持，不能把其他协议的字段直接移植到 SS。

选择加密方法时不要凭名称猜测。订阅提供什么取值，客户端就应保持什么取值。若导入后方法显示为空、被替换成不认识的值，通常意味着客户端内核不支持该方法或订阅转换过程中丢失字段。此时应先查看客户端日志中的“unknown method”或类似解析提示，再决定更换内核或让订阅输出兼容格式。反复修改密码不会解决加密方法不匹配。

连接速度与资源占用怎样看

SS 的处理链路通常较短，适合希望降低配置复杂度和计算开销的场景。Trojan 需要完成 TLS 握手，首次连接会有相应成本，但连接复用和稳定保持可以减少重复握手的影响。若应用频繁创建短连接，DNS、TLS 会话恢复和传输复用会显著影响体验；若主要是持续传输，则线路带宽与服务端负载通常更关键。

不要通过一次网页打开速度给协议下结论。更可靠的测试方式是固定同一服务器、同一时间段和同一应用，分别观察首次连接、持续传输、待机恢复和网络切换后的重连。至少重复多次，并把失败重试计入结果。某一协议偶尔出现更高峰值，不代表它在移动网络或弱信号下更稳定。

如何在两者之间做选择

服务端提供标准 Trojan 配置、证书与域名关系清楚、客户端内核支持完整时，Trojan 适合希望采用明确 TLS 模型的用户。服务端提供 SS、设备资源有限、配置目标是减少字段和维护步骤时，SS 更直接。两者都不是 VMess 或 VLESS 的“简化替代品”，因为认证模型和安全边界不同。迁移时必须由服务端同步提供对应协议，不能只在客户端下拉菜单中改类型。

若一个订阅同时提供多种协议，建议保留一个已验证稳定的节点作为基准，再测试新的协议组合。基准节点可以帮助区分本地网络问题和新配置问题。所有节点同时失败时，优先检查系统代理、DNS 和网络连接；只有某一类型失败时，再回到该协议的认证与安全字段。

05 / PERFORMANCE

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

速度应拆成四个阶段观察

“速度”至少包含解析、握手、首包和持续传输四个阶段。域名解析决定客户端何时获得目标地址；协议与安全层握手决定连接何时可用；首包时间反映应用请求与远端响应；持续传输才接近通常所说的带宽。VMess、VLESS、Trojan、SS 在协议处理上有差异，但如果 DNS 缓慢或线路丢包严重，协议差异会被更大的网络变量覆盖。

测试时先固定节点地址、传输方式和安全层，只改变一个变量。若把 VMess + WebSocket + TLS 与 VLESS + TCP + REALITY 直接比较，结果同时包含协议、传输和安全层差异，不能归因于其中任何一项。更合理的方法是使用服务端提供的可比组合，并在相同网络中重复测试。记录连接成功率和恢复能力，不只记录最高吞吐。

CPU 与内存开销来自哪些部分

CPU 主要消耗在加密、协议封装、TLS 握手、数据复制、压缩或额外传输处理。内存则与连接数量、缓冲区、路由规则、DNS 缓存和日志级别有关。协议本体较轻不代表整个客户端一定占用更低，因为图形界面、内核进程、规则集和 TUN 模式都可能成为主要开销。v2rayN 在桌面系统中通常由界面进程管理内核进程；查看资源时应把相关进程合并观察。

日志级别也会影响开销。排错阶段可以临时提高日志详细程度，正常使用后应恢复常规级别，避免大量磁盘写入。路由规则越多，匹配过程和内存占用越明显，但合理分类的规则通常不会成为首要瓶颈。真正需要关注的是规则重复、域名列表过大、DNS 查询反复失败和连接持续重试。

移动端电量的主要决定因素

Android 端使用 v2rayNG 或 v2flyNG 时，耗电并不只由协议决定。保持后台连接、网络在无线与蜂窝之间切换、系统省电策略终止进程、频繁 DNS 请求、失败重连和大量并发连接都会影响电量。一个理论开销较低但经常断线的配置，可能比稍复杂但稳定的配置更耗电，因为每次重连都要重新解析、握手并恢复应用连接。

检查电量时，先确保客户端获得持续运行所需的系统权限，并按设备设置加入合适的省电白名单。随后观察待机阶段是否频繁出现连接日志。如果屏幕关闭后连接不断中断，重点检查系统后台限制，而不是立即更换协议。关于 Android 端 VpnService 授权、省电白名单与分应用代理，可继续阅读v2rayNG 安卓使用要点。

TUN 模式会改变资源基线

桌面端启用 TUN 模式后，客户端处理的流量范围通常比普通系统代理更广，内核需要接管更多连接，并可能执行额外 DNS 与路由判断。因此，用普通系统代理模式和 TUN 模式比较协议开销没有直接意义。应先固定代理模式，再观察协议差异。若切换 TUN 后资源明显增加，先检查路由范围、DNS 设置和是否存在流量回环。

v2rayN TUN 模式适合需要统一接管不遵循系统代理设置的应用，但不应作为连接失败时的第一修复步骤。普通系统代理已无法连通的节点，切换 TUN 通常只会增加变量。正确顺序是先用客户端内置测试确认节点，再开启系统代理验证浏览器，最后根据应用需求决定是否使用 TUN。

形成可重复的测试记录

建议为每个候选组合记录协议、传输、安全层、内核、代理模式和测试网络。每次只修改一项，连续观察首次连接、十分钟持续使用、待机恢复和网络切换。若某组合在峰值上略高但重连失败较多，应优先选择成功率稳定的组合。日常体验由多数时刻的可用性决定，而不是单次最佳结果。

资源异常时按顺序收缩变量：关闭详细日志，恢复简单路由，退出 TUN，保留一个节点，再观察内核进程。若占用恢复正常，逐项重新启用功能。这样能够区分协议开销、规则开销和代理模式开销，避免把所有问题都归到节点类型。

06 / CORE FAMILY

V2Fly 与 Xray 内核家族及配置兼容性

共同来源与不同演进方向

V2Fly 与 Xray 都延续了 Project V 生态中的配置思想，常见入站、出站、路由、DNS 和传输层结构存在大量相似之处。它们不是图形客户端，而是负责解析配置与处理连接的核心程序。v2rayN 是桌面图形客户端，可以管理相应内核；v2rayNG 主要使用 Xray 内核；v2flyNG 则面向 V2Fly 内核。选择客户端时，实际也在选择默认内核能力。

两者的共同基础使许多 VMess、Shadowsocks、Trojan、普通 VLESS 与常见路由规则可以采用相似表达，但“相似”不等于所有字段双向兼容。Xray 在 VLESS、XTLS、REALITY 等方向加入了自身功能；V2Fly 则沿着原有配置体系持续发展。某个配置文件能被一个内核接受，不代表另一个内核会理解其中全部扩展字段。

功能差异要落到字段层面

判断兼容性时，不要只问“是否支持 VLESS”，而要继续检查安全层、流控、传输和扩展参数。例如普通 VLESS + TLS 与 VLESS + REALITY 对内核的要求不同；同为 TCP 传输，是否启用特定流控也会改变支持边界。订阅名称可能只写 VLESS，真正影响内核选择的参数藏在查询字符串或底层 JSON 中。

Xray 特有字段交给 V2Fly 时，常见结果包括导入时忽略、启动时报未知字段、节点能够保存但无法连接。反向迁移也可能遇到默认值不同或字段命名变化。最安全的方式不是手动删除报错项，而是先确认该项承担什么功能。如果它属于安全层必要参数，删除后即使配置能够启动，也不会得到等价连接。

配置迁移的检查顺序

从一个内核切换到另一个内核前，先导出或记录当前节点类型、传输方式、安全层和路由设置。第二步查看配置中是否包含目标内核不认识的扩展字段。第三步在目标客户端中只导入一个节点，确认内核能够启动。第四步检查 DNS 和路由日志，确认请求实际走到了预期出站。最后再迁移完整订阅。一次迁移全部节点会让错误来源难以定位。

如果只是图形界面升级而内核家族没有变化，通常不需要重写配置。若内核切换后普通 VMess 节点可用、REALITY 节点失败，就应把检查范围收缩到 Xray 扩展能力和安全字段，而不是重装网络驱动。相反，所有节点都无法启动时，应先看内核文件是否被客户端正确调用、本地监听端口是否被占用以及配置语法是否通过。

路由与 DNS 也有兼容边界

代理协议可用不代表整份配置完全兼容。路由规则中的域名类别、规则集引用、DNS 查询策略和出站标签也可能存在差异。迁移时如果节点测试成功但部分网站行为异常，应检查路由规则是否引用了不存在的标签，DNS 出站是否指向正确对象，以及规则顺序是否发生变化。底层配置通常按顺序匹配，前面的宽泛规则可能覆盖后面的具体规则。

简化配置是验证兼容性的有效方法。保留一个本地入口、一个代理出站和最小 DNS 配置，确认基础连接后再加入分流。不要在最小测试配置中同时启用复杂规则、TUN 和多个备用出站。每增加一层功能就做一次连通确认，这样能够明确是哪一层引入了差异。

如何选择默认内核

订阅以 VMess、普通 VLESS、Trojan 或 SS 为主，且既有 V2Fly 配置已经稳定时，可以保持原内核。订阅明确包含 REALITY、特定流控或 Xray 扩展字段时，应选择 Xray 支持路径。桌面端优先使用 v2rayN，再按节点需求设置内核；Android 端依据订阅能力在 v2rayNG 与 v2flyNG 之间选择。

内核选择不是长期不可变的决定，但每次切换都应有明确原因。只因某个名称更熟悉而更换内核，会增加配置解释差异。更具体的功能对照可阅读Xray 内核和 V2Fly 内核有什么区别，其中进一步拆解协议支持、性能和配置迁移边界。

07 / SUBSCRIPTION

订阅格式、分享链接与客户端兼容

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

订阅链接负责向客户端提供一个或多个节点配置，它本身不决定节点使用 VMess、VLESS、Trojan 还是 SS。客户端更新订阅后，会下载文本或结构化内容，再把其中的分享链接、字段和备注转换成内部配置。因而“订阅更新成功”只表示内容已获取，不代表每个节点都被完整解析，更不代表节点一定能够连接。

常见分享链接使用不同方案名区分协议，例如 vmess://、vless://、trojan:// 和 ss://。VMess 分享内容常经过编码后携带 JSON；VLESS 与 Trojan 常通过 URI 用户信息和查询参数表达传输、安全层及附加字段；SS 链接则包含加密方法、密码、地址和端口。客户端必须识别对应方案以及链接内的参数版本。

为什么同一订阅在不同客户端中数量不同

节点数量不同通常有四类原因。第一，某客户端不支持订阅中的协议或扩展字段，因此跳过对应条目。第二，订阅内容中存在格式错误，部分链接无法解析。第三，客户端启用了去重、筛选或按关键字排除。第四，订阅转换端针对客户端类型输出了不同内容。排查时先比较协议类型分布，而不是只比较总数。

若 v2rayNG 能看到 REALITY 节点而 v2flyNG 看不到，应先检查内核支持边界；若两者都缺少同一批 VMess 节点，则更可能是订阅编码或链接完整性问题。桌面端 v2rayN 若只导入部分节点，可以查看更新日志中的“跳过”“未知方案”或“字段解析失败”等信息。不要通过手工复制节点名称来补齐，因为名称不包含真正配置。

URI 编码会造成哪些隐蔽问题

密码、备注、路径和查询参数中若含有特殊字符，需要按 URI 规则编码。订阅转换过程中若重复编码，客户端看到的值会多出百分号序列；若完全没有编码，井号、问号、斜杠等字符可能被解释成链接结构。Trojan 和 SS 的密码尤其需要注意这一点。看到导入后的密码长度明显变化时，应回到原始订阅检查，而不是在客户端中猜测字符。

链接末尾的井号部分通常作为节点备注，不参与认证。备注出现乱码一般不会导致连接失败，但它提示订阅编码流程可能存在问题。若备注和关键参数同时异常，应重新获取完整订阅内容。复制链接时不要经过会自动换行或替换字符的编辑器，也不要只复制可见的截断文本。

订阅更新后的安全操作顺序

更新前先保留一个已经验证可用的节点，不要立即删除旧配置。更新后检查节点类型和数量，再选择一个新节点执行客户端内置测试。测试通过后开启系统代理并确认实际访问，最后再更新路由或 TUN 设置。这样可以把订阅解析、节点连接和系统接管分成三个阶段。任何阶段失败，都能回到上一个有效状态。

若订阅更新后原节点被覆盖，可以检查客户端是否提供保留本地修改、按备注合并或单独建立订阅分组的选项。手工修改订阅节点通常会在下次更新时被覆盖，长期修正应在订阅源完成。临时测试节点则适合复制为独立配置，并改一个清楚的备注，避免与自动更新条目混淆。

客户端选择与订阅类型对应

Windows、macOS、Linux 桌面端优先选择 v2rayN，它便于集中管理订阅、切换内核和检查日志。Android 订阅以 Xray 扩展能力为主时选择 v2rayNG；明确需要 V2Fly 内核兼容时选择 v2flyNG。具体安装包应从获取客户端页面按平台和架构选择，不要根据分享链接名称推断安装包类型。

订阅链接属于配置入口，应避免在公开页面或截图中直接展示完整内容。排错时可记录协议类型、错误提示和非敏感字段，但认证信息应保持私密。需要向他人说明问题时，用“协议 + 传输 + 安全层 + 内核 + 错误阶段”的形式描述，通常已经足够定位方向。

08 / SCENARIO GUIDE

按使用场景选择协议、内核与客户端

桌面日常使用：优先减少维护变量

Windows、macOS、Linux 桌面环境优先使用 v2rayN。第一步根据订阅已有协议选择，不主动改变服务端提供的节点类型。第二步检查是否包含 REALITY 或特定 Xray 扩展；如果包含，使用相应 Xray 内核支持路径。第三步在普通系统代理模式下完成单节点连通确认。只有应用不遵循系统代理或确有统一接管需求时，再评估 TUN 模式。

协议方面，已有 VMess + TLS 配置稳定时可以继续使用；新配置明确提供 VLESS + REALITY 时，按完整字段导入并确认内核；服务端提供 Trojan 时重点检查 TLS 与 SNI；使用 SS 时确保加密方法一致。桌面设备资源通常足以承担这些协议，选型重点应放在兼容性、恢复能力和维护成本，而不是追逐很小的理论开销差异。

Android 长时间后台：先控制重连

Android 端若订阅包含 VLESS + REALITY 等 Xray 能力，优先选择 v2rayNG；若配置明确围绕 V2Fly 内核组织，则选择 v2flyNG。完成导入后，先授予 VpnService 连接权限，再根据设备的后台管理方式处理省电白名单。观察屏幕关闭后的连接保持情况，如果日志持续出现断开和重新握手，先解决系统后台限制。

移动端协议选择应重视稳定连接和待机恢复。SS 的配置较简洁，VLESS 本体较轻，但任何协议只要频繁失败重试都会增加电量消耗。测试时固定同一节点使用半天以上，观察待机、网络切换和应用唤醒，而不是只看短时测速。分应用代理可减少不需要经过代理的应用连接数量，也有助于降低无关流量处理。

跨设备共享订阅：选择共同能力集合

同一订阅需要同时用于桌面和 Android 时，应以所有目标客户端共同支持的协议组合为基线。VMess、Trojan、SS 和普通 VLESS 常具有较广的客户端覆盖，但具体仍要看传输和安全字段。若订阅包含 REALITY，可让支持该能力的客户端使用对应节点，同时保留一个兼容范围更广的备用节点。不要为了“统一名称”把不同安全组合强行转换成同一种链接。

共享订阅的维护重点是字段一致和分组清楚。可按协议或内核要求给节点添加明确备注，例如“VLESS-REALITY-Xray”或“VMess-TLS-通用”，但备注只用于识别，不替代实际参数。每次更新后在两类设备上各测试一个节点，确认转换过程没有删除查询参数。

低资源与高并发场景：先测完整链路

资源有限设备可以优先比较 SS、VLESS 等处理较直接的方案，但必须在服务端支持和安全层完整的前提下选择。高并发场景则要同时看连接复用、传输方式、内核缓冲和服务端限制。协议封装较轻只能降低其中一部分开销，无法弥补线路丢包、服务端负载或错误 DNS 策略。

测试时记录 CPU、内存、连接成功率和持续吞吐。若降低协议开销后 CPU 有改善但失败率上升，整体效果仍可能变差。应选择在目标负载下连续运行稳定的配置，并保留可回退方案。调整传输、内核或安全层时一次只改一项，确保结果能够归因。

最终确认清单

完成选型后，依次确认八项：协议名称与服务端一致；客户端内核支持全部字段；地址与端口完整；认证信息没有空格或截断；传输方式及路径一致；TLS 或 REALITY 参数完整；客户端单节点测试通过；系统代理或 VpnService 接管后实际访问正常。任何一项未通过，都先停在当前阶段，不继续叠加路由或 TUN。

连接成功后再观察断开重连、待机恢复和网络切换。稳定运行一段时间后，保存当前有效组合的文字记录，包括协议、传输、安全层、内核和客户端名称。以后出现问题时，以这份记录作为基准，只比较发生变化的字段。这样比重新导入全部订阅更容易定位。

一页式选择结论

已有成熟配置并重视跨内核兼容，可先保留 VMess；新配置由 Xray 体系提供完整 VLESS + REALITY 参数，可使用支持该组合的内核与客户端；希望采用明确 TLS 认证模型并且证书配置完整，可选择 Trojan；配置目标简单、服务端明确提供 SS 且加密方法兼容时，可采用 Shadowsocks。协议没有脱离场景的统一排名。

桌面端首选 v2rayN，Android 端根据内核要求选择 v2rayNG 或 v2flyNG。选型完成后，可回到使用指南按订阅导入、代理开启和连通确认的顺序操作。若客户端启动闪退、端口占用或证书握手仍有错误，可查阅疑难解答以及TLS 证书报错排查清单。