V2Ray 协议与内核参考

01 / CONFIGURATION LAYERS

配置层次：协议不是整条连接

先把四类参数分开看

节点名称不是技术规格。列表里写着某个地区或用途，并不能说明它采用什么协议。打开 v2rayN 的节点编辑窗口，先看协议类型，再看传输方式，最后看传输层安全设置。这三个位置分别回答“请求如何表达”“数据怎样承载”“如何加密并确认对端”。内核则负责把这些约定实际执行出来。把层次分开，才能解释为什么两个都标为 VLESS 的节点，所需参数和连接表现仍然不同。

协议负责约定身份凭据、目标地址和请求格式。例如 VMess 使用用户标识参与认证，Trojan 使用密码验证请求，Shadowsocks 则依赖所选加密方法及对应密钥。传输层可以是直接承载数据的 TCP，也可以在外面增加 WebSocket 等封装。TLS 与 REALITY 属于连接安全相关机制，不应和协议名放在同一列当成互相替代的选项。界面把它们组合展示，是为了方便填写，并不表示这些概念处于同一层。

从服务端给出的参数反向核对

检查一个节点时，先确认地址和端口确实属于同一份配置，再核对身份信息。接着检查网络类型、路径、服务名和安全层。WebSocket 的路径必须与服务端设置一致；gRPC 的服务名也不能从另一个节点照抄。域名有时出现在服务器地址、TLS 的服务器名称和传输请求头三个地方，它们可能相同，也可能各有用途。把三个字段全部改成连接地址，并不一定是修复，反而可能破坏原本正确的分工。

客户端里的服务器名称通常对应 TLS 的 SNI，用于握手时声明希望访问的名称，也常参与证书名称验证。WebSocket 请求头中的 Host 则属于应用层请求信息。连接地址解决“先连接到哪里”，这两个名称解决后续阶段的不同问题。服务商提供完整分享链接时，优先保留原始字段；只有拿到明确配置说明，才单独调整。遇到名称不一致，先询问其用途，不要把“看起来不统一”当成错误依据。

区分本地接入与远端连接

系统代理和 Tun 不属于远端协议。系统代理告诉遵循该设置的应用，把请求交给本地代理端口；Tun 创建虚拟网络接口，让更多流量进入客户端处理链。两者改变的是流量如何进入内核，不会自动把 VMess 变成 VLESS，也不会替服务端补齐缺失能力。网页打不开时，若日志里根本没有对应请求，应先检查本地接入；若请求已进入内核但握手失败，再回到远端协议与安全参数。

路由和 DNS 也要单独理解。路由决定请求选择哪个出口，DNS 负责把域名解析为地址。连接测试通过，只说明测试涉及的路径能够完成某些步骤，不代表所有域名都走相同出口。修改路由规则后，原来的节点可以完全不变，而部分网站的访问结果仍会改变。因此排查时要记录改动层次，一次只改一类参数。需要逐项操作时，可配合已连接但无法上网排查清单使用。

02 / PROTOCOL CHOICES

协议设计：四类方案的取舍

VMess：认证与加密一起设计

VMess 是 Project V 生态的重要协议，设计时把用户认证、请求头和数据保护放进同一套约定，适合需要统一描述代理连接的场景。它不只是一个密码字段，还涉及用户标识、认证过程和加密选择。现代配置应以当前客户端能够解析的认证方式为准，不要为了迁就旧截图随意增加历史字段。某些认证过程对时间有要求，设备时钟偏差较大时，配置即使看起来正确，也可能无法完成认证。

在 v2rayN 中编辑 VMess 节点时，重点核对用户标识、加密方式、传输和 TLS 设置。分享内容里带有历史兼容参数，不代表这些参数在所有实现中都继续生效。应先确认订阅是否仍适用于当前内核，再决定是否需要重新获取配置。VMess 的优势是生态积累和已有部署较多；代价是配置概念相对集中，初学者容易把协议自身的加密和外部 TLS 混为一谈，误以为重复勾选就一定更可靠。

VLESS：简化协议本身的职责

VLESS 将设计重点放在轻量的认证和请求表达上，协议本身不提供通用的数据加密保护，通常需要与 TLS 或 REALITY 等安全机制组合。这里的“轻量”描述的是协议职责，不是对任何线路速度的保证。客户端里看到加密字段为 none，不能据此判断连接就是明文；应继续查看外层安全设置。反过来，若外层安全也没有启用，就不能想当然地认为协议名称已经提供了加密。

VLESS 配置还可能包含 flow 字段，它描述特定流控行为，不是随便选择的加速档位。服务端要求 Vision 时，客户端与内核必须同时支持对应组合。把空白 flow 改成 Vision，不能让一个普通节点自动获得该能力；传输条件不符合时甚至无法建立连接。选择节点时，应把协议、传输、安全层和 flow 当作完整组合比较。后面章节会说明 REALITY 与 Vision 的关系，以及它们为什么不是同一个功能。

Trojan：依托 TLS 的认证模型

Trojan 的常见部署依托 TLS 保护传输，再通过密码认证代理请求。它的配置表面上较直观，但连接成立仍依赖服务器名称、证书和服务端入口。密码正确只解决认证的一部分问题，不会自动修复证书名称不匹配。编辑节点时，应保留提供方给出的服务器名称和传输方式。不要因为密码形式更熟悉，就认为可以忽略安全层；也不要通过跳过证书验证来掩盖一个尚未查明的配置错误。

Shadowsocks：方法与密钥必须配套

Shadowsocks 常被简称为 SS，设计侧重明确的加密代理模型，配置通常围绕服务器、端口、加密方法和密码展开。不同方法的密钥要求、实现支持和协议行为可能不同，不能只看名称中都含有相似的加密算法就互换。较新的方法与传统方法也不是仅修改一个标签即可兼容。若导入后提示密码格式不符合要求，应先确认该方法规定的密钥编码，不要把结构化密钥改成普通短密码。

四类方案都可以用于日常代理连接，但没有脱离服务端部署的绝对优先级。已有稳定的 VMess 配置，不必仅因另一种协议名称更新就更换；需要某个 Xray 特性时，应检查 VLESS 的完整组合；使用 Trojan 或 Shadowsocks 时，则应先确认 TLS 条件或加密方法支持。真正可用的选择，是服务端提供准确参数、客户端能够完整表达、内核能够执行的交集，而不是节点列表里最醒目的标签。

03 / SECURITY AND FLOW

TLS、REALITY 与 Vision 的边界

TLS 先确认对端，再保护传输

TLS 提供传输加密，并通过证书等机制帮助客户端确认正在连接的服务端。在常规部署中，客户端需要检查证书信任链、有效期以及名称是否匹配。节点地址填写的是一个地址，而服务器名称可能是证书所对应的域名，这两者不能机械合并。握手失败时，先核对设备时间和服务器名称，再检查服务端证书状态。把“允许不安全连接”打开只会改变验证边界，并没有消除造成错误的实际原因。

还要区分 TLS 握手参数与浏览器外观相关设置。某些客户端提供指纹选项，用于选择握手特征的实现方式。它不等于用户身份，不会替代用户标识或密码，也不是所有内核都按相同方式支持。照抄另一个节点的指纹、服务器名称和应用层协议列表，可能引入新的不兼容。服务端说明没有要求时，应保留订阅给出的值或客户端适用的默认值，而不是把所有高级设置都填满。

REALITY：改变握手与认证的实现方式

REALITY 使用与常规证书部署不同的连接建立和认证机制。它结合目标站点的 TLS 特征及自身认证设计工作，并不是“随便填写一个真实域名就可以连接”。客户端需要服务器名称、公钥和短标识等配套信息，服务端也要有相应配置。这里的公钥用于认证关系，不是用户的登录密码；短标识属于服务端约定的认证参数，不能用另一个节点的值替代，更不能把示例文字直接填入真实连接。

客户端界面可能把公钥显示为 Public key，也可能随着实现调整使用其他字段名称。判断是否填对，应对照该客户端当前说明和订阅解析结果，不能只按旧截图的位置匹配。公钥与私钥职责不同，终端用户通常只需要服务端提供的客户端参数，不应索要或传播服务端私钥。若导入后某项为空，应先检查链接中是否携带该信息，再确认解析器支持，而不是从名称相似的字段拼凑一套看似完整的配置。

Vision：流控不是加密开关

XTLS Vision 是与特定连接组合配套的流控机制，主要处理加密流量在代理链中再次封装时的行为，减少符合条件的数据路径中的重复处理。它不是所有流量都能触发的万能优化，也不是仅打开 REALITY 就自动生效。TLS 与 REALITY 说明连接的安全建立方式，Vision 说明某些数据阶段怎样处理，三者有联系但职责不同。能否使用，要看协议、传输、内核和服务端配置是否形成受支持的组合。

在 v2rayN 或 v2rayNG 中核对这类节点时，先确认协议为提供方指定的类型，再看安全设置，最后核对 flow。若服务端没有启用对应流控，客户端自行选择 Vision 通常不会得到预期结果。某些组合对传输方式有明确限制，不能把可用于直接 TCP 承载的设置原样搬到 WebSocket 上。遇到导入成功却启动失败，优先阅读内核日志中的参数错误，而不是先更换 DNS 或系统代理模式。

如果安全参数已经逐项一致，却仍然无法连接，再检查地址是否可达、端口是否正确、设备时间是否正常，以及服务端是否仍提供该入口。不要为了让界面显示连接成功而降低验证要求。需要进一步理解重复加密与流控，可以阅读REALITY 与 XTLS Vision 原理科普。本文提供判断框架，具体字段仍以提供方与当前内核支持的完整配置为准。

04 / CONNECTION COST

连接速度与资源占用的判断顺序

先区分首开、持续传输与交互

“快”至少包含三件不同的事：第一次打开页面需要多久、持续下载能保持怎样的吞吐、交互请求能否及时得到响应。首开受到域名解析、建立连接和安全握手影响；持续传输更多依赖线路容量、拥塞和两端处理能力；交互体验则对往返时间与丢包更敏感。一个节点测速时传输量较大，不代表网页首开必然更短。比较协议之前，应先确定自己真正想改善的是哪一种等待。

连接建立通常需要经过若干阶段。域名需要解析，底层连接需要建立，安全层需要握手，某些传输还要完成额外协商。增加封装可能带来兼容性或部署上的便利，也会增加处理步骤和数据开销。但不能只数层数就给出固定速度排名，因为连接复用、服务端位置、缓存状态和网络丢包都会改变结果。减少一次握手在高往返时间的链路上可能更明显，在其他场景中则未必成为主要因素。

封装、复用与拥塞并非越多越好

WebSocket 把数据放进自己的帧结构，适合相应的服务端接入方式；gRPC 依赖其协议栈，也有不同的流管理特点。它们首先是承载与部署选择，不是通用加速按钮。连接复用可以减少部分重复建立连接的成本，但多个请求共享底层连接时，也可能受到同一处拥塞或传输阻塞影响。若服务端说明不支持某种复用模式，客户端单方面启用不会产生有效优化，反而可能导致请求异常。

资源占用也不能只看协议名。加密算法是否得到硬件支持、内核缓冲区如何分配、同时活跃连接有多少、日志是否过于详细，都会影响处理器与内存。某些算法在一类设备上执行高效，在另一类设备上却未必占优。界面显示的客户端内存还可能包含图形界面、缓存及后台任务，不等于协议本身开销。需要判断时，应同时观察内核活动和实际业务，而不是截取启动瞬间的单个数字。

用受控对照代替协议排行榜

较有意义的比较，应尽量保持服务端地区、访问目标、设备、接入网络和时间段相近。若两个节点背后的线路不同，结果首先反映线路差异，而不是协议优劣。可以先测试同一个页面的首次打开，再测试重复访问，最后观察持续传输和交互。每次只改变一个因素，并记录是否发生重新连接。不要把连接已预热的一组结果，与刚清空缓存、刚启动客户端的另一组结果直接比较。

出现“测试连接很快，网页却卡住”时，先确认测试使用的目标与网页是否经过相同路由，再看解析、证书和实际请求日志。有的测试只反映底层连接或特定探测请求，不能覆盖网页中的多个资源域名。路由把主页面和静态资源分到不同出口，也可能造成观感不一致。排查时先找到具体失败阶段，随后再判断是否值得换协议，否则频繁更换节点只会使变量越来越多。

实时应用还要单独核对 UDP。节点协议能够表达 UDP 请求，不代表客户端接入方式、服务端转发和远端网络都允许它正常工作。应用没有遵循系统代理时，即使节点支持相关能力，也可能根本没有进入代理链。开启 Tun 后，还需确认路由、权限和 DNS 一起正确。对持续视频访问，稳定性与拥塞控制往往比节点名称更重要；对网页浏览，则应优先关注解析与连接建立。

最终选择不需要追求所有指标同时最优。普通浏览可以把配置准确、连接稳定放在前面；长期传输则关注持续表现和设备负载；实时互动关注往返与丢包，并检查应用流量是否确实被接管。协议只决定这条路径中的一部分。关于节点列表中地区、倍率等信息的解读，可继续看节点选择因素对照，不要把商业标签误当成技术参数。

05 / MOBILE POWER

移动端电量与后台运行

耗电来自整条工作链

Android 设备上的电量消耗不只来自加密计算。无线连接保持活跃、应用持续发起请求、后台重连、DNS 查询和日志写入都可能参与其中。信号不稳定时，网络切换与重复握手还会放大开销。因此，“某个协议更省电”需要附带设备、流量类型和网络条件。脱离这些条件给出固定排名，没有可靠的判断价值。先确认客户端是否在做预期工作，再考虑协议层面的细微差别。

移动端首推 v2rayNG；需要 V2Fly 内核并且配置受支持时，可考虑 v2flyNG。二者不能只看界面相近就认定节点完全通用。导入后，应检查协议、安全层和高级字段是否完整保留，再确认实际连接。安装入口见Android 客户端下载。选择包时先按设备架构判断，不要把安装包体积差异当成耗电依据；支持的指令集和实际运行行为才与设备适配有关。

先排查重连，再讨论加密开销

如果待机时电量下降明显，先看客户端日志是否反复出现断开和重新连接。常见分支包括服务端不可达、名称解析失败、认证参数不匹配，以及系统在后台限制网络活动。持续失败时，客户端可能不断重试，每次重试又触发解析和握手。此时调整加密算法往往抓错重点。先恢复一个能够稳定连接的节点，再观察待机变化，才能判断之前的消耗是否来自异常循环。

另一种情况是后台连接被系统回收，解锁后才重新建立。需要长时间保持连接时，可在系统的应用电池管理中检查 v2rayNG 或 v2flyNG 的后台限制。不同设备的设置名称会变化，应沿“应用信息”进入电池与后台活动相关选项。放宽限制有助于维持运行，但也可能提高待机消耗，不能承诺两者同时改善。若只在使用时需要连接，就不必为了理论上的稳定性长期保留后台运行。

接管范围决定需要处理多少流量

Android 客户端通常通过系统提供的虚拟网络接口接收流量，系统出现连接标识，表示本地接口已经建立，不代表远端节点一定可用。应用分流可以改变哪些应用进入代理链，但排除应用前，应先确认它是否确实不需要代理，以及它的依赖服务是否随之改变。减少不必要的处理有时有助于降低开销，不过规则错误也可能让部分请求绕过预期出口。应先以功能正确为基线，再逐步收窄接管范围。

频繁自动测试、过密的保活和持续刷新连接信息也值得检查。保活用于维持某些状态，但间隔越短不等于体验越好；无线网络可能因为小包不断被唤醒。若客户端提供相关设置，优先采用适用的默认值，只有遇到明确的连接空闲失效问题才调整。排查时可以暂时停止非必要的批量测试，保持相同使用方式观察一段完整过程，而不是只看刚切换设置后的瞬时电量变化。

观察温度和电量时，还应排除屏幕亮度、系统更新、应用下载和视频解码等因素。建议在相近网络与相同应用任务下比较，分别记录前台使用和待机的表现。处理器负载增加而流量没有明显变化，可能与错误重试或详细日志有关；流量持续增长，则应检查实际联网应用。电池页面显示的是系统的归因结果，不一定完整区分界面、内核与虚拟接口，不能把单项百分比直接解释为协议成本。

节电选型的顺序是：保证配置兼容，解决重复重连，确认后台策略，再控制必要的接管范围，最后才比较协议实现开销。对于连接稳定的现有节点，随意换一种协议未必改善电量，反而可能引入新的握手条件。若 Wi-Fi 与移动网络表现差异明显，应分别记录，并在切换网络后重新验证 DNS 和连接。移动端最有价值的优化，是让客户端持续完成正确工作，而不是让设置页面尽量复杂。

06 / CORE COMPATIBILITY

V2Fly 与 Xray：家族关系和兼容边界

客户端界面与内核分工不同

Project V 是理解这套开源代理生态的背景。V2Fly 延续 V2Ray 的社区开发，Xray 与其具有共同的技术来源，并在此基础上形成自己的功能演进。两者存在相近概念和配置形式，但不是可以逐字替换的同一个程序。讨论开源属性时，应区分项目自身许可证与所含组件的许可证；使用客户端也仍需遵守相应条款。开源提供了公开讨论和审阅的基础，不代表每个配置组合都自动兼容。

v2rayN、v2rayNG 和 v2flyNG 是用户操作的图形客户端，负责展示节点、管理订阅和生成运行配置。内核负责建立连接、处理路由并执行协议。界面能够保存一个字段，只说明客户端接收了输入，不一定说明当前调用的内核能够执行。反过来，内核支持某项能力，但客户端尚未提供相应配置入口，也不能据此推断图形界面一定可用。选型应同时检查界面表达能力和内核执行能力。

相似 JSON 不等于相同语义

两类内核常见的配置概念包括入站、出站、路由和 DNS，某些基础结构看起来相近，但字段支持范围、默认值和组合限制可能不同。尤其是 REALITY、Vision 等功能，不应按“都属于 V2Ray 生态”推断可在 V2Fly 中直接使用。遇到内核不认识的字段，有的实现会明确拒绝启动，有的解析路径可能忽略部分信息。没有报错不等于目标功能已经生效，仍需查看实际生成的配置与运行结果。

切换前可以先把当前可用节点保留为独立副本，再查看客户端的核心设置与节点类型映射。不同界面布局可能把内核选择放在设置页或相关节点选项中，不能仅以托盘菜单的模式名称判断。选定后，重新启动受影响的连接，再查看日志中实际调用的内核与错误信息。不要同时修改路由、DNS 和安全参数，否则失败后很难分辨是内核差异还是其他设置造成。

迁移要验证行为，不只验证启动

以下片段展示一种常见的路由表达：匹配私有地址范围后，交给标签为 direct 的出口。它可以帮助理解字段关系，但不是完整连接配置。使用前必须确认完整配置中已经定义该出口，并确认内核支持所用字段。它也不表示所有局域网域名都会因此直连，因为域名是否参与解析、规则何时获得地址，仍取决于完整 DNS 与路由策略。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

迁移后至少验证三个层面：内核能否启动，目标请求是否走向预期出口，退出客户端后系统网络状态是否恢复。前两项验证配置语义，最后一项验证本地接入行为。Tun 与系统代理的权限和清理过程不同，不能因为节点连接成功就省略退出测试。若系统仍指向已关闭的本地代理端口，应先恢复系统代理状态，而不是把问题归因于远端协议。

对于已经稳定运行的配置，切换内核应有明确目的，例如需要某个被支持的协议组合，或解决一个可以复现的实现问题。不要把切换当成定期维护动作，也不要把新旧标签等同于质量排名。桌面首次运行时遇到权限或启动问题，可参阅v2rayN 首次安装与初始设置。选择正确的客户端与内核，再保留最少且必要的配置，通常比持续添加兼容参数更容易维护。

07 / SUBSCRIPTION FORMATS

订阅格式：导入成功不等于配置完整

分享链接、订阅地址和运行配置

分享链接通常描述一个节点，订阅地址则用于获取一组可更新的内容，运行配置是内核最终读取的结构化数据。三者用途不同。把订阅地址放进单节点编辑窗口，可能无法解析；把某个内核的完整 JSON 当成通用订阅，也不一定能被另一款客户端理解。订阅正文还可能使用编码包装，因此“浏览器打开后看起来像乱码”本身不足以判断失效。应由支持该格式的客户端解析，并观察具体错误。

常见分享内容包含 VMess、VLESS、Trojan 或 Shadowsocks 的协议标识，但相同前缀下仍可能存在参数编码差异。名称备注、特殊字符、请求头与安全参数的转义都会影响解析。复制时少一个字符，或把链接末尾的标点一起选中，都可能改变结果。导入之后，不要只看节点名称是否出现，应打开编辑窗口确认协议、地址、端口以及高级安全字段。名称能够显示，只表示部分内容被读取。

格式转换可能丢失能力

客户端解析器负责把订阅内容转换成内部节点模型，之后再生成内核运行配置。如果内部模型没有对应字段，转换过程可能无法完整保留新功能。表现可能是安全层退回默认值、flow 消失、服务名为空，或某个参数被当成普通备注。因此，同一订阅在两款客户端里出现不同结果，并不必然说明服务端变化。先比较导入后字段，再查看生成配置，最后才判断内核是否真正不兼容。

不要把格式转换服务当成透明步骤。转换方可能需要读取订阅内容，转换规则也可能重新解释字段。订阅地址往往带有个人授权信息，获得地址的人可能获取节点或消耗对应资源。复制截图、提交日志或寻求帮助前，应遮盖完整地址、用户标识和密码等敏感内容。若地址已经泄露，应通过提供方的管理入口更换授权，而不是仅仅从本地列表中删除分组。

更新路径与节点连接是两件事

在 v2rayN 中，先进入订阅分组设置，确认地址已保存，再执行“更新订阅(不通过代理)”。这一步用于区分直接更新路径和当前代理路径的问题，并不保证所有订阅都应该始终直接获取。如果订阅入口本来要求通过可用代理访问，就应在已有连接正常的前提下选择相应更新方式。关键是一次只变更获取路径，保留原分组，以便比较错误，不要同时清空所有节点。

若更新失败但旧节点仍能连接，优先检查订阅入口、授权和获取路径；若订阅能够更新而所有节点无法连接，优先检查节点参数、服务端状态和内核支持。两者都失败时，也应分别记录获取订阅与连接节点的错误。HTTP 返回成功不保证正文就是订阅，有时得到的是登录页面、错误提示或其他网页内容。解析器提示格式错误时，应确认返回内容类型，而不是反复改节点密码。

订阅更新还可能覆盖手动修改。若需要临时调整服务器名称或传输参数，应复制为独立节点，并写清调整目的，避免下次更新把测试结果替换。分组名称只是管理标签，不会改变服务端协议；给同一地址建立多个不同名称的分组，也不代表获得了不同线路。清理重复节点前，先确认它们的安全层和传输参数是否真的一致，不能仅按显示名称去重。

跨设备同步时，优先在每台设备上分别导入受支持的订阅，再核对字段，而不是直接覆盖整个客户端数据目录。桌面系统代理、Android 应用分流和本地文件路径都有设备差异，完整配置迁移容易带入不适用设置。若出现解析报错，可按订阅更新失败与解析报错逐项判断。订阅管理的目标是保存准确来源与更新关系，不是让节点列表看起来尽可能长。

08 / SELECTION AND VALIDATION

场景选型与连接验证

从需求出发，不从协议名称出发

日常网页浏览优先选择参数完整、能够稳定更新、客户端明确支持的节点。若现有 VMess、Trojan 或 Shadowsocks 配置运行正常，不必仅为了名称差异迁移。需要使用 REALITY 或 Vision 时，优先确认 Xray 相关支持，以及服务端提供的完整组合。桌面端首推 v2rayN，是因为需要在图形界面里集中管理订阅、系统代理和路由；协议选择则应继续根据服务端能力判断，两件事不能混为一谈。

持续视频或大文件传输，应先观察线路稳定性、持续拥塞和设备温度，再比较协议封装。实时互动则要检查往返时间、丢包以及 UDP 的完整路径。移动设备在不稳定网络中使用时，重连行为和后台策略可能比单次握手开销更重要。只有多个候选节点具备相近线路条件，协议与传输差异的对照才更有意义。先筛掉配置不完整或功能不匹配的选项，可以减少大量无效测试。

桌面端按层验证

在 v2rayN 导入后，先打开节点编辑窗口，核对协议、传输与安全层，保存并选为活动节点。接着在系统代理菜单中选择“自动配置系统代理”，用一个遵循系统代理设置的应用访问目标，同时查看日志是否出现对应请求。若应用没有进入本地代理，先排查系统接入；若请求进入后认证失败，再检查远端参数。不要一开始就同时开启 Tun、修改 DNS 和切换内核。

需要 Tun 时，先确认当前客户端与系统具备相应支持，并按提示处理权限。启用后重新检查路由和解析，不要假定原来系统代理下的行为会完全相同。对局域网设备的访问尤其要单独验证，私有地址规则、域名解析和实际出口需要配套。退出时确认系统代理与虚拟接口状态已恢复。若关闭客户端后所有网页都失败，应优先检查本地残留设置，而不是继续更换远端节点。

移动端验证与故障分支

在 v2rayNG 导入后，同样先核对高级字段，再启动连接并同意系统要求的虚拟网络接口权限。随后用实际应用验证，而不是只看系统状态栏的连接标识。若只有一个应用失败，检查应用分流和它所需的流量类型；若所有应用都失败，再检查节点与解析。换用 v2flyNG 前，先确认节点不依赖其内核未实现的功能，否则客户端切换只会重复同一个兼容性问题。

无法启动内核时，查看字段、功能支持和配置语法；能够启动但握手失败时，检查地址、端口、时间与认证；握手成功但部分域名失败时，检查 DNS 和路由；只有特定应用失败时，检查接管范围与应用自身设置。这个顺序不是把所有故障压成单一原因，而是把每次观察对应到一层。日志中的错误也可能是后续结果，因此应从最早出现的相关失败开始读，避免只搜索最后一行提示。

验证完成后，保存一份简短记录：客户端名称、实际内核、协议组合、系统接入方式，以及仍存在的问题。记录里不需要写凭据，也不必复制整段日志。下次更新订阅或调整内核时，可以按同样步骤回归测试。若新设置出现问题，恢复已知可用组合，再逐项比较差异，比持续叠加修复选项更可靠。能够复现的现象和明确的改动记录，通常比“所有协议都试过”更有帮助。

选型的最终标准是配置可解释、功能符合需求、运行结果可验证。没有脱离线路与设备条件的固定协议冠军，也没有只靠一个开关就能补齐的兼容性。初次配置回到快速上手教程执行主线；遇到订阅或连接问题，再按本页相关章节查阅。需要更换客户端时，从下载页按系统和架构选择，先建立一个可靠基线，再逐步调整确有需要的高级功能。