V2Ray 协议与内核选型手册

01 / MODEL

选择协议前：先分清协议、传输与安全层

客户端中的一行节点，实际由多层参数组成

“协议”在客户端界面里经常被用作一个宽泛分类，但一条可用连接并不只由协议名称决定。以常见的 VLESS 节点为例，VLESS 负责描述客户端与服务端交换身份信息和转发数据的基本方式；TCP、WebSocket、gRPC 等字段描述底层数据如何被承载；TLS 或 REALITY 负责握手和安全层；XTLS Vision 则可能作为流控方式参与数据处理。地址、端口、用户标识和服务器名称又属于连接参数。任何一层不匹配，都可能表现为超时、握手失败或连接后没有有效流量。

因此，选型时不能把“VLESS”和“VLESS + TCP + REALITY + Vision”视为同一个精度的名称。前者只指出协议骨架，后者才接近一套完整组合。客户端导入订阅后显示的类型标签，通常只突出最容易识别的部分；完整参数仍应进入节点编辑页检查。尤其是从文本订阅迁移到另一款客户端时，名称显示相同不代表所有扩展字段都被保留。

四个判断维度比固定排名更可靠

第一项是服务端兼容。客户端不能单方面把 VMess 改成 VLESS，也不能只勾选 REALITY 就让普通 TLS 节点获得对应能力。协议、传输和安全参数必须与服务端配置逐项一致。第二项是内核能力。v2rayN 可以承载桌面端常见配置，v2rayNG 主要使用 Xray 内核，v2flyNG 则面向 V2Fly 内核；同一条基础节点在这些客户端中的支持范围可能不同，涉及 REALITY、Vision 或特定传输扩展时差异更明显。

第三项是设备环境。桌面设备通常有更充足的处理器时间和内存，可以优先考虑兼容性、路由能力和维护便利。Android 设备还要考虑后台运行、无线网络切换、持续握手和重复重连带来的耗电。第四项是配置来源。如果节点来自订阅，应优先选择订阅明确提供且客户端完整识别的类型，不要为了追求某个名称而手工猜测缺失参数。

先确认完整性，再讨论性能

连接速度的前提是参数正确。地址解析、端口可达、系统时间准确、用户标识一致、传输路径一致，这些基础条件比协议名称对首次成功率的影响更直接。如果导入后缺少服务器名称、WebSocket 路径、REALITY 公钥或短标识，单纯切换节点类型通常不会解决问题。应返回节点资料或订阅来源核对，而不是在客户端中逐项试猜。

一个实用顺序是：先确认客户端是否识别节点类型；再核对地址、端口和身份字段；随后检查传输方式及其附属参数；最后检查安全层和流控。完成这些步骤后，才比较连接建立时间、持续吞吐、内存占用和电量表现。这样的顺序可以把“配置错误”和“协议取舍”分开，避免把一次握手失败误判成某类协议本身速度较慢。

02 / VMESS

VMess：存量配置兼容与参数边界

设计背景与当前定位

VMess 是 Project V 生态中较早形成广泛使用的一类协议。它把用户标识、认证信息和数据传输规则组织在统一协议结构内，并在客户端与服务端之间引入基于时间的认证过程。这个设计使 VMess 不只是“地址加密码”的简单组合，也解释了为什么系统时间偏差可能影响连接。许多较早部署的服务端、订阅转换工具和客户端配置都以 VMess 为基础，因此它在存量节点兼容方面仍有实际价值。

选择 VMess 的主要理由通常不是追求最少处理步骤，而是现有配置已经稳定运行，相关订阅字段也能被客户端完整解析。若服务端只提供 VMess，客户端应保持协议一致。把节点类型改为 VLESS 并保留原 UUID，并不会得到等价连接，因为两种协议的认证和数据结构不同。协议迁移需要服务端与客户端同时调整，不能只改本地标签。

alterId、加密选项与旧配置识别

旧资料中经常出现 alterId。它属于早期 VMess 配置体系的一部分，现代配置中通常使用零值。导入历史订阅时，如果客户端仍显示该字段，应以服务端实际配置为准，不要根据教程年代自行改成其他数字。不同客户端可能隐藏不再常用的选项，或者在导入阶段自动填写默认值；这类界面差异不等于协议内容被改变。

VMess 节点还可能显示 security 或“加密方式”。这个字段描述 VMess 数据层采用的处理方式，与外层 TLS 不是同一个选项。外层 TLS 是否启用，由传输安全字段决定。用户常见的误区是看到 security 已有值，就认为 TLS 也已配置；实际上两者位于不同层级。排查时应分别检查，不应把其中一项替代另一项。

{
  "protocol": "vmess",
  "settings": {
    "vnext": [{
      "address": "example.com",
      "port": 443,
      "users": [{
        "id": "11111111-1111-4111-8111-111111111111",
        "alterId": 0,
        "security": "auto"
      }]
    }]
  }
}

上面的片段只展示 VMess 出站的核心层级。真实连接还需要与服务端一致的传输和安全设置。示例地址与用户标识仅用于说明字段结构，不能作为节点使用。手工录入时，应把节点资料中的每个值放入对应位置，而不是复制示例内容。

传输组合与性能理解

VMess 可以与 TCP、WebSocket 等传输组合，也可以叠加 TLS。不同组合的差异往往大于 VMess 协议本身。例如，直接 TCP 的封装路径相对短；WebSocket 需要额外的帧处理，并依赖路径、Host 等字段匹配；TLS 又会增加握手和加密计算。讨论“VMess 快不快”时，必须说明比较双方是否使用相同传输、相同安全层、相同服务器和相同网络条件。

在资源占用方面，VMess 的认证和数据处理通常比结构更精简的 VLESS 多一些步骤，但现代桌面设备上，这种差异未必会成为主要瓶颈。真正明显的延迟常来自域名解析、服务器距离、无线网络抖动、连接反复建立和传输层重试。移动端持续使用时，应关注客户端日志中是否发生周期性断线重连；反复握手会同时增加等待时间与电量消耗。

适合保留与适合迁移的情况

如果 VMess 节点参数完整、连接稳定、订阅更新正常，并且当前客户端能够准确识别传输设置，继续使用是合理选择。协议选型不是每次出现新名称就必须迁移。反之，如果正在新建服务端，且客户端与内核都明确支持 VLESS 及所需安全组合，可以从更精简的协议骨架开始评估。迁移时应保留原节点作为对照，先新增配置并验证，再移除旧配置，避免在参数尚未核对完成时失去可用基线。

在 v2rayN、v2rayNG 与 v2flyNG 之间传递 VMess 节点时，基础字段通常具有较广兼容性，但某些传输扩展仍取决于内核。导入成功后至少检查协议、地址、端口、UUID、传输方式、TLS 开关、服务器名称和路径。若订阅只提供一个 vmess:// 项目，客户端通常会负责解码；若显示为空白节点或字段错位，应优先检查订阅内容是否完整，而不是手工补猜。

03 / VLESS · REALITY

VLESS、REALITY 与 XTLS Vision：三个层级分别做什么

VLESS 是轻量协议骨架

VLESS 的设计重点是简化协议自身承担的工作。它使用用户标识完成身份匹配，但不在 VLESS 数据层内重复提供一套完整加密机制，而是把安全能力交给 TLS、REALITY 等外层方案。这种分工让协议结构更清晰，也减少了某些重复处理。不过，“VLESS 本身更轻”不等于任何 VLESS 组合都一定更快；最终开销仍由传输方式、安全握手、流控、服务器实现和网络路径共同决定。

在客户端编辑页中，VLESS 常见字段包括地址、端口、UUID、加密值、传输方式、安全类型和流控。部分界面会要求加密字段使用 none，这是协议结构的一部分，不表示整条连接没有安全层。若节点同时使用 TLS 或 REALITY，安全处理位于外层。判断安全组合时，应查看“传输层安全”或同义选项，不能只看 VLESS 的加密字段。

REALITY 是安全握手方案，不是 VLESS 的替代名称

REALITY 经常与 VLESS 一起提供，因此不少客户端把组合名称连在一起显示。严格区分时，VLESS 负责应用协议，REALITY 负责安全与握手相关能力。REALITY 配置通常涉及服务器名称、公钥、短标识和客户端指纹等参数；这些值必须成组匹配。仅有地址、端口和 UUID 不足以建立完整连接。订阅转换若遗漏其中任一扩展字段，客户端即使显示为 VLESS，也可能在握手阶段失败。

公钥是客户端验证并参与握手所需的重要字段，短标识用于匹配服务端配置，服务器名称则参与握手语义。客户端中的“指纹”选项描述握手表现所采用的预设。不同版本界面对这些字段的命名可能略有差别，例如“Public Key”“公钥”或缩写名称，但字段作用并未因此改变。迁移节点时应按含义映射，不要只按界面位置复制。

XTLS Vision 属于流控与数据处理方式

XTLS Vision 常出现在 VLESS + REALITY 组合中。它不是新的身份协议，也不是服务器地址的附加形式，而是一种流控选择。Vision 的目标之一是减少特定场景中的重复处理，让已经具有安全语义的数据能够采用更合适的数据路径。客户端和服务端都需要支持并配置一致；若服务端没有启用对应流控，客户端单方面选择 Vision 可能导致连接异常。

界面中常见的值是 xtls-rprx-vision。选择时应以节点资料为准。留空与填写该值不是可以随意互换的性能档位，而是服务端配置的一部分。某些订阅格式可以直接携带 flow 参数，某些旧转换流程则会丢失它。导入后如果 REALITY 的公钥、短标识都存在，但仍无法传输，应继续检查 flow，而不是只反复修改服务器名称。

为什么这类组合常有较好的响应表现

VLESS 协议骨架较精简，REALITY 省去了自行准备普通 TLS 证书配置的部分流程，Vision 又针对数据处理路径作出优化。三者组合时，较少的重复封装与合适的流控可能降低处理开销。但实际体验仍受往返时延、服务端负载、拥塞、域名解析和设备性能影响。协议只决定其中一部分，不应从一次测速直接推导普遍结论。

移动设备上的优势通常体现在持续连接较稳定、重复计算较少时。若网络频繁在无线局域网与移动数据之间切换，任何协议都会重新建立连接；此时后台策略和网络质量可能比协议差异更影响电量。想进一步理解握手和数据路径，可阅读REALITY 与 XTLS Vision 技术科普。实际配置前还应确认所用客户端和内核支持完整字段，其中 v2rayNG 更适合承载 Xray 相关扩展。

04 / TROJAN · SS

Trojan 与 Shadowsocks：结构简洁，但取舍不同

Trojan：认证与 TLS 组合清晰

Trojan 通常以密码作为身份凭据，并与 TLS 一起使用。它的配置认知相对直接：客户端连接指定地址和端口，使用密码完成协议认证，同时由 TLS 提供安全层。常见节点资料还会包含服务器名称和证书验证相关选项。这里的服务器名称需要与服务端证书配置相匹配，不能仅根据地址栏内容推断。

Trojan 的优势在于参数层次容易理解，许多客户端也能稳定解析标准分享链接。它并不是“只有密码和端口”这么简单，因为 TLS 握手、服务器名称、传输方式仍然需要一致。若使用 WebSocket 或 gRPC，路径、服务名等附属字段同样参与连接。排查时可以先把问题分为 TLS 握手阶段和 Trojan 认证阶段：前者重点检查系统时间、服务器名称和安全设置，后者重点检查密码及服务端协议配置。

Shadowsocks：精简的加密转发结构

Shadowsocks 常缩写为 SS。它的核心参数通常包括服务器地址、端口、加密方法和密码，结构比 VMess 或带多个扩展层的 VLESS 组合更短。精简配置让它便于手工录入，也容易跨客户端传递。与此同时，加密方法必须由客户端和服务端共同支持，名称需要逐字匹配；把一个看起来相近的方法替换进去，并不会自动协商成可用值。

不同内核对 Shadowsocks 加密方法的支持范围可能存在差异。较新的方法需要相应内核能力，旧客户端即使能够读取 ss:// 链接，也可能在连接阶段提示不支持。遇到这类情况，应先确认客户端内核，而不是改动密码。v2rayN 适合桌面端统一管理不同协议，v2rayNG 与 v2flyNG 则分别受到所用内核支持范围影响。选择客户端时，应把实际加密方法列入兼容性检查。

{
  "protocol": "shadowsocks",
  "settings": {
    "servers": [{
      "address": "example.com",
      "port": 8388,
      "method": "aes-128-gcm",
      "password": "your-password"
    }]
  }
}

这个片段展示标准出站字段关系。地址、端口、方法和密码必须替换为服务端提供的真实值。加密方法不是本地偏好选项，不能为了减少资源占用而单方面更换。若客户端导入后方法为空，应重新核对分享链接或订阅转换结果。

两者的性能差异不能只看字段数量

Shadowsocks 参数少，并不意味着所有网络条件下都比 Trojan 快。Trojan 通常承担 TLS 握手成本，但长连接建立后，握手成本会被后续持续传输摊薄。Shadowsocks 的实际开销与所选加密方法、设备硬件加速、数据包大小及内核实现有关。短连接很多时，连接复用和客户端行为可能主导体验；持续下载时，服务器带宽和链路质量往往更加重要。

移动设备上，持续加密计算与频繁重连都会影响电量。现代处理器对常见加密运算有较好支持，单看算法名称很难准确预测耗电。更有意义的观察方式是保持同一网络、同一服务器区域和相近负载，分别记录一段时间内的连接稳定性、唤醒次数和客户端后台状态。一次几秒的测速不足以判断长期电量表现。

适用边界与选择方法

节点资料若只提供标准 Trojan 参数，并且客户端能正确识别 TLS 相关字段，保持 Trojan 是最稳妥的做法。节点若提供 Shadowsocks，应重点确认加密方法是否受当前内核支持。两者都不需要为了与其他节点“统一类型”而转换。订阅中同时包含多个协议时，可以保留不同类型，让客户端按节点维度管理；系统代理和路由规则不要求所有出站都采用同一协议。

从维护角度看，参数较少有利于人工核对，但不代表后续更新可以省略。服务端地址、密码、证书名称或加密方法发生变化后，旧节点仍会失效。使用订阅时应通过客户端的更新订阅功能接收变化，避免长期维护多个手工副本。关于桌面端与 Android 的订阅入口，可参阅V2Ray 订阅链接导入方法。

05 / PERFORMANCE

连接速度、资源占用与移动端电量如何比较

把“快”拆成四个可观察阶段

协议比较中的“速度”至少包含四个不同指标。第一是连接建立时间，从客户端发起连接到握手完成；第二是首包时间，即请求发出后收到第一段有效数据的等待；第三是持续吞吐，反映较长传输过程中的稳定速率；第四是抖动与重连，决定网页连续加载、音视频播放和后台任务是否平稳。某个组合连接建立稍慢，不代表持续吞吐一定较低；反过来，首次连接很快也不代表弱网络下更稳定。

进行对比时，应固定服务器、网络、目标地址、路由规则和测试时段。若两个节点位于不同地区，所得差异主要反映网络路径，而不是协议。还应先完成一次预热，减少域名解析与首次连接缓存对结果的影响。客户端中常见的“延迟测试”可能只测 TCP 建连或特定探测地址，不一定完成真实协议握手。想判断节点能否工作，应使用真连接测试，并在连接后访问实际目标验证。

协议处理通常不是唯一瓶颈

VMess 具有自身认证和数据处理流程；VLESS 把安全能力更多交给外层；Trojan 常伴随 TLS；Shadowsocks 的开销与加密方法相关；VLESS + REALITY + Vision 又包含握手与流控协作。理论上的处理步骤可以帮助解释差异，但在普通客户端使用中，网络往返、服务器处理能力、丢包和拥塞经常占据更大比例。只有在服务器与链路条件接近时，协议层差异才更容易被观察。

传输方式也会改变结果。TCP 组合通常路径直接；WebSocket 增加帧封装；gRPC 基于 HTTP/2 语义并可能利用多路复用。多路复用并非连接越多越好，过度聚合可能让单个底层连接的抖动影响多个请求。客户端中的并发、连接复用或 mux 选项应保守调整，一次只改一项，并保留默认值作为比较基线。

内存、处理器与后台唤醒

资源占用由客户端界面、内核、规则集、连接数量和日志级别共同构成。协议只是其中一部分。大型路由规则、持续详细日志和大量并发连接，往往比单个协议字段更明显地增加内存与处理器使用。桌面端 v2rayN 还需要管理系统代理、托盘状态和配置列表；Android 客户端则通过系统网络接口接管流量，并受到后台策略影响。比较资源时，应确认两次测试使用相同规则和日志级别。

日志等级尤其容易干扰长期观察。排错时启用详细日志很有价值，但完成排查后可以恢复常规等级，减少持续写入与格式化开销。节点列表过多通常不会持续占用大量处理器，但频繁执行全量测试会同时建立许多连接。移动设备上不宜把自动测试间隔设得过短；按需测试当前候选节点更容易得到可解释结果。

移动端电量由稳定性与重连频率共同决定

移动端耗电不能简单按照 VMess、VLESS 或 Trojan 排出固定顺序。无线模块唤醒、屏幕使用、网络信号强弱、后台保活、连接数量和重试策略都会影响结果。一个理论处理较轻、但每隔几十秒断线重连的节点，可能比稳定维持长连接的节点消耗更多电量。应先选择稳定路径，再讨论协议处理差异。

在 v2rayNG 或 v2flyNG 中比较节点时，可以保持相同路由模式与应用范围，关闭不必要的连续测速，观察正常使用周期内的系统电量统计。测试期间不要频繁切换网络，也不要同时进行大规模系统更新。若设备进入休眠后连接总是被系统回收，应检查系统针对客户端的后台运行设置；这属于设备调度问题，换协议未必能够解决。

06 / CORES

V2Fly 与 Xray：内核家族、功能范围和配置兼容

客户端界面与代理内核是两个组成部分

v2rayN、v2rayNG 和 v2flyNG 都提供图形界面，但实际协议解析、连接建立、路由处理通常由内核完成。界面负责订阅管理、节点编辑、系统代理、日志展示和启动控制；内核负责读取配置并执行网络逻辑。理解这层分工后，很多兼容问题会更容易定位：界面能显示某个字段，只说明数据被保存；内核能否执行，还取决于对应功能是否受支持。

v2rayN 是桌面端首选，适合 Windows、macOS 与 Linux，能够管理多种节点与路由配置。v2rayNG 是 Android 端常用客户端，主要结合 Xray 内核能力。v2flyNG 同样面向 Android，但采用 V2Fly 内核路线，可作为需要该内核兼容范围时的选择。三款客户端的安装入口集中在下载中心，应按设备平台和节点类型选择，不要仅根据名称相似度判断。

V2Fly 延续 Project V 配置体系

V2Fly 维护 V2Ray 相关核心能力，配置结构延续常见的 inbounds、outbounds、routing、dns 等层级。VMess、Shadowsocks、Trojan 以及相应传输能力都可以在其支持范围内组织。对于已有 V2Fly 配置、依赖其具体行为或希望保持同一内核体系的用户，v2flyNG 提供了直接的 Android 图形入口。

“配置结构相似”不代表所有扩展字段完全通用。某些字段可能只在特定内核中存在，另一些字段虽然名称相同，支持的取值范围也可能不同。把完整 JSON 从一个内核复制到另一个内核前，应先检查协议与传输支持，再检查路由规则和 DNS 结构。基础出站通常更容易迁移，涉及实验性功能、专用流控或扩展传输时则应逐项验证。

Xray 扩展了 VLESS、REALITY 与 Vision 等能力

Xray 与 V2Ray 配置体系有较深的结构联系，因此许多基础配置看起来相似。Xray 在 VLESS、XTLS Vision、REALITY 等方向提供相应能力，这也是这些节点通常更适合使用 v2rayNG 或桌面端相应内核环境的原因。节点资料若明确包含 REALITY 公钥、短标识和 Vision 流控，应优先确认当前客户端实际调用的内核是否支持，而不是只确认界面里存在 VLESS 类型。

内核选择也会影响分享链接解析后的字段保留。客户端可能在导入阶段识别 URI 参数，但启动内核时仍会进行配置转换或检查。如果日志提示未知字段、无效取值或不支持的流控，问题重点通常在功能范围，而不是地址是否可达。此时应回到节点类型与内核匹配关系处理，不宜通过删除随机字段让配置勉强通过，因为被删除的字段可能正是连接必需项。

哪些配置通常容易兼容，哪些需要谨慎

地址、端口、基础用户标识、标准 VMess 字段、部分常见传输和基础路由规则，通常较容易在相近配置体系之间映射。DNS 与 routing 的基本层级也有共同概念。但 REALITY、XTLS Vision、特定传输扩展、协议专用设置，以及不同内核新增的字段，应视为需要单独核对的部分。客户端生成的完整配置还可能包含本地监听端口、日志路径和平台相关设置，这些内容不适合原样跨设备复制。

更稳妥的迁移方式是以节点分享信息为输入，让目标客户端生成自己的本地配置。这样可以避免把源客户端的本地端口、缓存路径和平台选项一并带过去。随后再迁移路由规则，并逐项验证。若必须处理 JSON，先保留最小出站和必要传输字段，确认连接后再加入 DNS、路由和高级选项。每增加一层都进行一次测试，出现错误时就能定位到最近的变更。

v2ray test -c config.json
xray run -test -c config.json

以上命令用于在相应内核可执行文件已经正确安装且位于当前命令环境时检查配置语法。命令测试通过只表示配置能够被解析，不代表服务器一定可达。图形客户端用户通常可以直接查看启动日志，无需离开客户端操作。

07 / SUBSCRIPTION

订阅、分享链接与客户端兼容：字段怎样在工具间传递

订阅链接是配置集合入口，不是协议本身

订阅链接通常返回一组节点数据，客户端获取内容后再解析为本地配置。它可以包含 VMess、VLESS、Trojan、Shadowsocks 等不同类型，也可能返回经过 Base64 编码的多行分享链接。订阅地址本身不能说明内部节点采用哪种协议，只有更新并解析后才能看到具体类型。把订阅地址直接粘贴到单节点编辑框，通常不会得到正确结果。

在 v2rayN 中，应使用订阅分组或订阅管理入口保存地址，再执行更新订阅。v2rayNG 与 v2flyNG 也有对应的订阅设置和更新操作。更新后先确认节点数量和类型，再选择节点测试。若列表为空，应检查地址是否完整、网络请求是否成功、返回内容是否为客户端支持的格式。完整步骤可查看v2rayN 与 v2rayNG 订阅导入说明。

常见 URI 格式分别携带哪些信息

vmess:// 常见形式会把一段 JSON 信息编码后放入链接，其中可包含地址、端口、UUID、传输、Host、路径和 TLS 等字段。不同生成工具曾使用过略有差异的字段名称，因此旧链接在新客户端中的解析结果需要人工核对。vless://、trojan:// 与部分 ss:// 链接更接近标准 URI：身份信息位于用户信息部分，地址和端口位于主机部分，其余参数放在查询字符串中。

URI 中的参数名具有明确含义。例如 security 可能指出 TLS 或 REALITY，type 可能表示传输方式，flow 表示流控，sni 或同义参数表示服务器名称，pbk 与 sid 常用于 REALITY 公钥和短标识。客户端需要认识这些参数并正确映射到内核配置。分享链接看起来较长并不表示信息一定完整；如果生成工具没有写入某个必要字段，再长的链接也无法恢复缺失内容。

Base64 只是表示方式，不等于某一种协议

不少订阅把多行分享链接整体进行 Base64 编码，以便作为单段文本传输。解码后仍然是多个 vmess://、vless://、trojan:// 或 ss:// 项目。Base64 不负责加密节点内容，也不决定客户端兼容性。兼容性取决于解码后的协议链接、扩展参数以及目标客户端的解析能力。

当一个客户端能导入、另一个客户端导入为空时，不应先判断订阅失效。可以依次确认目标客户端是否支持订阅返回类型、是否识别其中的协议、是否支持链接所带扩展参数。v2flyNG 与 v2rayNG 使用不同内核路线，含 REALITY 或 Vision 的节点更应注意差异。若订阅同时包含多种节点，部分成功、部分失败通常意味着协议或参数支持范围不同，而不是整个订阅请求失败。

更新、去重与本地修改的边界

订阅更新可能覆盖由订阅管理的节点。若在客户端中直接修改订阅节点，下一次更新后这些改动可能丢失。需要长期保留的本地实验配置，可以复制为独立节点并改名，避免与订阅项目混淆。节点名称相同也不一定是重复项，应比较地址、端口、协议、身份字段、传输和安全参数后再决定是否删除。

更新订阅后突然无法连接，应先检查节点参数是否发生变化，再判断本地代理设置。服务端可能调整地址、端口或安全字段，客户端也可能因为解析规则变化而显示不同。保留一份更新前的独立对照配置，有助于判断变化发生在哪一层。若所有订阅节点同时超时，再按照节点超时排查顺序检查系统时间、本地端口、节点参数与订阅状态。

08 / DECISION

按使用场景选协议，并安全完成迁移

已有稳定节点：兼容优先于追逐名称

如果现有 VMess、Trojan 或 Shadowsocks 节点已经稳定工作，订阅更新正常，客户端也能完整识别参数，就没有必要仅因为看到新的协议名称而立刻迁移。协议选型首先受服务端能力约束，其次才是本地偏好。稳定连接本身包含经过验证的服务器配置、网络路径和客户端组合，这些条件比理论对比更有价值。

需要更换客户端时，桌面平台优先选择 v2rayN；Android 上，含 Xray 扩展的配置优先考虑 v2rayNG，需要 V2Fly 内核路线时选择 v2flyNG。迁移前记录原客户端中的协议、传输、安全、服务器名称、路径、流控和身份字段。通过分享链接或订阅导入后，再逐项对照。只有名称和地址一致还不够，扩展字段缺失可能让节点在握手阶段失败。

新建配置：先确定内核，再确定组合

准备新建节点时，可以先从目标设备与客户端反推内核能力。若桌面与 Android 都需要使用，并且配置涉及 REALITY 与 Vision，应确认两端均有适合的 Xray 运行环境，然后再采用 VLESS + REALITY + Vision 组合。若目标环境强调 V2Fly 配置一致性，则应从 V2Fly 支持范围内选择协议和传输。先定内核可以避免服务端部署完成后才发现某一端无法解析关键字段。

若需求是参数简洁、手工录入方便，并且服务端与客户端对加密方法支持一致，Shadowsocks 可以作为明确选项。若已有标准 TLS 配置体系，并希望采用密码认证与清晰的 TLS 层次，Trojan 便于理解和维护。VMess 更适合继续承载现有配置和兼容历史订阅。不同组合没有脱离环境的绝对排名，应把兼容、维护、稳定和资源四项放在同一张检查表中。

弱网络与移动设备：优先减少重连

网络波动明显时，选择稳定服务器和合适传输比追求理论封装最少更重要。观察日志中的连接重置、握手超时和重复解析。如果某节点频繁断开，应先判断是无线信号、服务端负载、传输设置还是协议参数问题。直接更换协议可能同时更换服务器和路径，从而让对比失去依据。

Android 设备应减少持续批量测速和过于频繁的订阅更新，保持合理的路由规则规模，并让系统允许客户端按需要在后台运行。VLESS + REALITY + Vision 在支持完整、参数匹配的前提下，可能具有较好的处理路径；但一个稳定的 Trojan 或 Shadowsocks 节点仍可能在实际设备上表现更好。应以完整使用周期的稳定性、电量和真连接结果判断。

多设备同步：以订阅作为来源，以客户端配置作为本地层

桌面端与 Android 端共同使用时，适合把节点订阅作为共享来源，把系统代理、应用范围、路由模式和本地监听端口留在各自设备管理。不要直接复制完整客户端配置文件，因为其中包含平台相关字段。订阅更新后，两端分别检查节点类型和扩展参数；如果某类节点只在一端出现，应检查该端的解析与内核支持，而不是立即删除订阅内容。

路由规则也不应与协议选择混为一谈。同一条 VLESS 或 VMess 出站可以被不同规则引用，切换路由模式不会改变节点协议。排查“某些网站能访问、某些不能访问”时，应先判断请求是否命中了预期路由，再检查节点。若所有请求都失败，才回到协议和连接参数。分清两层可以减少无效修改。

迁移流程：新增、对照、验证、再清理

安全迁移可以分为四步。第一步保留旧节点，新增目标协议配置，不覆盖当前可用项。第二步逐项对照地址、端口、身份、传输、安全和流控，确保服务端已经同步支持。第三步执行真连接测试，检查日志并访问实际目标，分别验证连接建立和系统代理生效。第四步经过一段稳定使用后，再删除不再需要的旧配置。

如果新配置失败，应回滚到最近一次可用状态，并按层级排查。认证错误检查 UUID 或密码；握手错误检查系统时间、服务器名称、公钥和短标识；超时检查地址、端口和传输；启动阶段提示未知字段则检查内核兼容。不要同时改动协议、传输、路由和 DNS，否则日志很难指出真正原因。详细的首次连接验证流程可参考v2rayNG 首次连接全流程。