V2Ray 协议与内核参考

协议分层与参数对应

代理协议决定如何表达请求

VMess、VLESS、Trojan 与 Shadowsocks 解决的共同问题，是让客户端向服务端说明目标地址，并按双方约定处理身份认证和数据。它们不是完整网络环境的代名词。一次连接还涉及域名解析、底层传输、安全握手以及路由出口。v2rayN 中看似属于同一条服务器记录的多个选项，实际上分属不同层。判断配置是否可用，应先把这些层拆开，避免把某一个字段当成万能开关。

VLESS 可以搭配不同的传输方式与安全层，因此仅知道服务使用 VLESS，还不足以完成配置。客户端至少需要服务器地址、端口、用户标识，并核对传输类型、安全类型以及该组合要求的附加字段。Trojan 通常依赖 TLS 提供传输安全，Shadowsocks 的加密方法则是协议配置的重要组成部分。订阅导入能够代填字段，但不能改变这些字段必须相互匹配的事实。

传输方式决定数据如何承载

TCP、WebSocket 与 gRPC 等名称描述的是不同承载方式，而不是不同账号。WebSocket 常用于需要反向代理转发的部署，路径和请求主机可能参与转发匹配；gRPC 则需要核对服务名称等参数。裸 TCP 配置通常没有同样的路径语义。把 WebSocket 的路径复制到另一种传输里，既不能增加兼容性，也可能让用户误以为配置已经完整。客户端里出现的可编辑框，并不代表当前组合一定会使用它。

TLS 与 REALITY 位于安全配置层，不能和 VMess、VLESS 排成同一层的替代项。用户看到的“VLESS + REALITY”，是代理协议和安全方案的组合名称。TCP 是承载方式，Xray 是执行配置的内核，v2rayN 是管理配置的图形客户端。这几个名称同时出现并不矛盾。讨论选型时应说清组合，而不是把某个组合的表现归因于其中一个名字。

流量接入与远端协议分别检查

系统代理、TUN 和安卓 VPN 模式负责把应用流量交给客户端，远端协议负责把接收到的请求送往服务端。前者设置正确，并不能证明后者握手成功；远端测试成功，也不能证明所有应用都已接入。v2rayN 只启用系统代理时，不读取系统代理设置的应用可能继续直连。v2rayNG 开启 VPN 模式后，也仍需考虑应用分流和局域网绕过规则。

路由规则负责在接入后选择出口，可以按域名、地址或其他条件匹配。DNS 则影响目标名称怎样转换为地址，以及路由还能否取得域名信息。使用服务端地址时，解析服务端本身与解析最终目标是两件事。前者失败会导致连接尚未建立，后者失败则可能表现为客户端已运行但网站打不开。两种情况应在日志中分别定位，不能一律归类为协议不兼容。

参数记录建议按层保存：先记地址和认证，再记承载方式，最后记安全层及路由例外。修改时一次只动一层，并保留上一次可用配置。这样在出现故障时，能够明确判断问题来自接入方式、协议握手还是名称解析，也能避免在多个客户端之间迁移时遗漏某个看似不起眼的附加字段。

代理协议的设计取舍

VMess 与 VLESS：认证和加密职责不同

VMess 是 Project V 生态早期的重要代理协议，设计中包含用户身份认证和数据保护机制。它不仅描述目标地址，也承担一部分安全职责，因此配置涉及用户标识、加密选项和时间相关的认证条件。讨论 VMess 时应区分现代实现与历史配置；旧教程中的兼容参数不能直接当作新配置建议。导入后如果出现认证错误，应核对用户标识、客户端时间和服务端实际要求，而不是连续切换加密选项碰运气。

VLESS 采用更精简的协议设计，将数据加密职责交给外部安全层。它的“精简”主要描述协议职责，不代表任意网络中都能获得更低延迟。VLESS 常见配置会搭配 TLS 或 REALITY，整体安全性与连接成本需要按完整组合判断。用户标识正确但安全层配置错误，连接仍然不能正常建立；把外部安全层关闭，也不能据此获得等价的安全配置。

VMess 更适合继续使用已有且维护正常的兼容部署。VLESS 则常见于围绕 Xray 功能配置的新部署。两者的选择首先取决于服务端提供什么，而不是客户端下拉框里哪个名字更新。服务端没有对应监听入口时，修改客户端协议类型不会完成转换。迁移需要服务端和客户端协同，涉及认证、传输、安全字段的重新核对，而不是只保留地址与端口。

Trojan：把安全建立在 TLS 之上

Trojan 的设计强调借助 TLS 建立安全连接，再在其中进行代理认证和请求转发。用户通常需要配置密码、服务器名称以及证书验证相关选项。相较于把认证与加密全部绑定在协议内部的方案，它更多复用成熟的 TLS 基础设施。优势是安全层的职责清晰，代价是必须正确处理证书、域名与握手流程。密码正确不能弥补证书名称错误，证书有效也不能证明代理密码正确。

Trojan 配置也不能被简化成“有密码的 TLS”。内核对传输扩展和附加选项的支持存在差异，分享链接未必能表达全部部署细节。用户在 v2rayN 或 v2rayNG 中导入后，应确认安全类型、服务器名称、传输方式和密码都被保留。遇到握手错误时，先检查 TLS 层；握手已经通过而认证失败时，再核对密码与服务端配置，能够减少无效尝试。

Shadowsocks：配置紧凑，方法必须匹配

Shadowsocks 较早采用紧凑的加密代理设计，常见配置由地址、端口、加密方法和密码组成。现代使用应明确具体方法及实现支持范围，不能只写“支持 Shadowsocks”就假定所有变体都可互通。不同代际的认证和密钥要求可能不同；某些方法要求特定格式的密钥，不能随意替换成普通口令。客户端能保存该方法名称，也不等于当前内核已经实现它。

Shadowsocks 的参数数量较少，适合需要直接管理固定入口的场景，但简洁不代表可以省略服务端信息。TCP 与 UDP 能力需要同时看服务端、客户端和当前接入模式，插件或额外封装也不是任意内核的通用能力。旧分享链接如果依赖附加组件，应先确认当前三款客户端的实际支持方式；不明确的扩展字段，应向配置提供方确认，而不是直接删除后继续使用。

协议选型最终应回到可维护性：现有服务是否稳定、客户端是否持续支持、参数能否完整迁移、异常时是否能读懂日志。已正常工作的组合没有必要只因名称不同就迁移。需要新能力时，再评估迁移成本与服务端支持范围，通常比单纯追求协议新旧更有效。

TLS、REALITY 与认证边界

TLS 要核对名称和信任链

TLS 为连接提供加密与服务端身份验证。客户端填写的服务器地址可以是域名或地址，但用于安全验证的服务器名称有独立含义。连接到某个地址，并不意味着该地址对应的任意证书都应被接受。证书有效期、名称匹配和信任链都是检查的一部分。系统时间明显错误时，有效证书也可能被判定为尚未生效或已经过期，因此时间同步是排查安全握手问题的基础步骤。

服务器名称通常对应客户端界面中的 SNI 或 ServerName 字段，它可能与用于建立连接的地址不同。连接地址负责找到服务器，服务器名称参与握手和验证，两者各有用途。WebSocket 请求中的 Host 又属于另一层，可能参与反向代理的站点匹配。服务配置确实可能让这些名称相同，但不能因此认定它们是同一个字段，修改时应依据部署说明逐项处理。

TLS 的应用层协议协商用于决定连接上使用的应用协议，常见于需要 HTTP 相关承载的配置。它不是可以随意勾选的性能加速项，客户端与服务端需要有兼容的协商结果。启用自定义选项前，应先确认当前传输真正需要什么。未经确认同时改动服务器名称、协商列表和承载方式，会让日志中的单一握手错误对应多种可能原因，反而增加排查难度。

REALITY 是安全方案，不是独立代理类型

REALITY 是 Xray 支持的传输安全方案，常与 VLESS 配合使用。它有自己的认证和握手要求，客户端通常需要服务端提供的公钥材料、允许的服务器名称以及短标识等信息。这里的公钥材料用于对应服务端身份与握手配置，不是 VLESS 用户标识的替代品。用户标识、短标识和公钥分属不同职责，填对其中一项不能抵消其他字段不一致。

REALITY 配置中的客户端指纹选项影响握手特征的构造，但不能替代认证条件。选择列表中看似熟悉的名称，并不会自动修复错误公钥或不匹配的短标识。指纹选项也依赖当前内核实现，迁移时要核对其是否被识别，而不是只检查文本是否出现在配置中。部分界面会保留未知字段，实际启动时仍可能报出不支持的值，应以运行日志为准。

VLESS 的流控字段同样需要与传输和安全组合一起判断。常见的 Vision 选项属于特定实现提供的流量处理能力，不是所有 VLESS 连接都必须开启。服务端要求某种流控时，客户端应使用相同且受支持的设置；服务端没有对应配置时，不应为了追求速度自行添加。导入后流控字段为空，也不能直接断定链接不完整，要先确认该部署是否要求它。

把握手错误拆成可验证的步骤

v2rayN 排查安全连接时，可以先确认服务端地址能否解析，再观察连接是否到达目标端口，随后查看安全握手和代理认证分别是否完成。端口可达只说明传输连接可能建立，不说明身份验证通过。反过来，连接超时也不必然是安全层出错，地址解析失败、路径异常或服务端未监听都可能在握手之前发生。日志中的阶段信息比笼统的“无法连接”更有价值。

v2rayNG 迁移 REALITY 配置时，应特别核对导入工具是否保留服务器名称、指纹、短标识、公钥材料与流控。界面名称可能随客户端调整，但参数含义应与服务端说明保持一致。如果原配置可用而迁移后失败，先比较这些字段，再考虑网络差异。不要公开完整分享链接排查问题，因为其中的用户标识和认证材料可能允许他人使用同一个入口。

TLS 和 REALITY 都不能取代终端应用本身的安全措施。客户端连接安全与网站使用的 HTTPS 是不同连接层次，服务端之后的访问路径仍需单独考虑。选择方案时应同时理解信任对象、认证材料的保管方式与更新流程；一个参数更少却配置清晰的组合，通常比堆叠大量未知选项更容易长期维护。

连接速度与资源占用

首个请求与持续下载分别测量

VMess、VLESS、Trojan 和 Shadowsocks 的性能不能脱离完整链路排名。用户感受到的首次打开时间，包含域名解析、连接建立、安全握手、代理认证以及目标站点响应。持续下载速度则更多受到带宽、拥塞、服务端负载和目标资源限制影响。同一个组合可能首次打开稍慢，却能保持稳定吞吐；另一个组合可能握手较快，但在长连接中因丢包或限速表现不佳。

v2rayN 的连接测试只覆盖测试请求所经过的路径，不是所有应用性能的缩影。测试目标、连接复用状态和缓存都会影响结果。某个入口对测试地址响应较快，并不能说明视频、软件仓库或办公系统同样更快。比较时应固定客户端、网络、目标资源和接入模式，分别记录首次请求、连续访问及大文件传输的表现，避免把多个变量的变化算到协议头上。

TLS 等安全握手需要通信往返与密码学运算，因此高往返时间网络更容易放大连接建立成本。已经建立并被应用复用的连接，不会为每个请求重新承担全部成本。浏览器连接池、内核复用以及服务端空闲超时共同决定实际效果。比较之前应区分冷启动和已有连接状态，否则先测的一组与后测的一组可能根本没有经历相同的握手过程。

加密、封装与复用都有代价

加密运算的成本受处理器、系统实现和硬件加速影响。相同方法在桌面设备和低功耗设备上可能有不同表现，因此不能直接从台式机测试推导手机电量。VLESS 将加密交给外部安全层，也不意味着完整连接没有加密开销；Trojan 借助 TLS，同样要计算 TLS 的处理成本。评估时应观察整条连接，而不是只看代理层本身处理了多少字节。

WebSocket、gRPC 等承载会引入各自的帧结构、状态维护和部署路径。额外封装可能增加处理开销，但反向代理设施、连接复用与网络路径也可能带来实际收益。某种承载在特定部署下更稳定，不代表它天生更快。选择时应首先满足服务端的部署要求，再考虑额外封装是否必要，避免为了名称丰富而叠加当前应用并不需要的层次。

多路复用可以让多个逻辑请求共用已有连接，减少反复建立连接的成本，但也会共享底层连接的拥塞和故障影响。底层连接发生丢包时，其他逻辑请求可能一起等待；服务端或中间设备的超时策略也会影响复用效果。浏览器已经在应用层复用连接时，继续增加另一层复用未必获得明显收益。是否开启，应以相同场景的重复测试为依据，而非默认越多越好。

资源对照要控制测试条件

v2rayN 对照资源占用时，应让两组配置处理相同任务，并分别观察空闲、持续传输和大量短请求三个阶段。内存驻留包含配置缓存、规则数据和运行时管理，不等于当前连接正在消耗同等规模的网络资源。图形界面进程与内核进程也应区分统计，避免把界面刷新成本误算为协议处理成本。日志开得过于详细，还可能额外影响磁盘和处理器负担。

UDP 应用需要单独验证。实时语音、游戏或其他数据报业务关心抖动、丢包与持续可达性，不能用网页测试代替。某些组合的 UDP 转发依赖特定封装或实现，服务端和客户端必须共同支持。测试不通过时，应检查这条数据路径是否真正启用，再讨论时延；一条仅支持当前 TCP 业务的可用连接，并不能证明所有类型流量都已经正确转发。

性能调整建议保留一条基线配置，每次仅修改一个选项，在多个时段重复相同任务。若收益只在一次测试中出现，暂时不要据此长期改动。可复现的稳定性改善通常比偶发的峰值更有参考意义；需要进一步区分接入方式与路由影响，可阅读系统代理与路由模式的区别。

安卓电量与后台运行

VPN 常驻不等于持续高负载

v2rayNG 与 v2flyNG 在安卓上可通过系统 VPN 接口接入应用流量。系统显示 VPN 状态，说明流量接入服务正在运行，并不表示处理器始终处于高负载。真正影响耗电的因素包括流量规模、连接唤醒频率、无线网络状态、加密处理、DNS 请求和其他应用的后台活动。只根据通知图标持续存在就认定客户端异常耗电，容易忽略产生流量的实际应用。

安卓的耗电统计可能把部分网络处理成本归到 VPN 客户端，而原始请求来自其他应用。因此应结合使用时长、前后台流量和同一任务的对照观察，不能只看一个百分比。持续视频播放、大量云同步和短消息推送的负载结构不同，分别影响吞吐、连接次数与设备唤醒。相同协议在不同任务下的电量差异，可能远大于更换协议本身带来的差异。

移动网络的无线模块从休眠进入活跃状态也有成本。频繁短连接、过密的保活以及失败后的持续重试，都可能延长活跃时间。连接参数错误导致反复握手时，耗电上升往往来自失败循环，而不是协议本身在正常运行时成本过高。排查应先看日志是否重复出现超时、认证失败和连接重建，再考虑精简配置或调整后台策略。

省电设置需要与稳定性一起评估

v2rayNG 如果被系统限制后台运行，可能在锁屏后中断服务；应用恢复联网时又会发起连接重建。解除电池限制有助于保持连续运行，但也扩大了客户端正常工作的时间范围，不能简单理解为省电开关。合理做法是先确定使用目标：需要全天稳定接入时，允许必要的后台运行；只在特定任务使用时，可在任务结束后主动断开，减少不必要的常驻。

v2flyNG 的后台表现同样受到系统调度和设备厂商策略影响。更换内核家族不能自动绕过系统限制，也不能保证降低耗电。两个客户端对照时，应只运行其中一个，并保持网络、应用任务和观察时段相近。若一个客户端保持 VPN 服务、另一个被系统停止，得到的电量差异没有可比性。需要比较的是完成相同任务的成本，而不是后台存活时间不同的总消耗。

VPN 模式和仅代理模式具有不同接入范围。仅代理模式通常需要应用主动使用本地代理，不能据此假定整机流量都得到处理。它看起来更省电，可能只是处理的流量更少。分应用代理和绕过局域网规则可以减少不必要的转发，但同时会改变流量路径；修改前应确认哪些应用必须经过代理，避免为了降低统计数值而破坏预期的连接方式。

移动网络切换与 DNS 需要单独检查

无线局域网与移动数据切换会改变地址、路径和系统网络状态，已有连接不一定能够直接继续使用。v2rayNG 可能需要重新建立远端连接，应用也可能保留已经失效的连接池。切换后短暂恢复不应立即判断为协议故障；若长期无法恢复，应检查客户端能否重新连接、DNS 是否仍使用失效路径，以及应用重建连接后是否正常。

DNS 请求如果形成失败重试或被错误路由，也会增加后台活动。远程解析与直连解析需要有可到达的出口，解析服务端本身还应避免依赖尚未建立的代理形成循环。FakeDNS 能改变域名与地址的关联方式，但不是节电选项；启用前应理解它与路由、应用缓存和 VPN 接入的配合关系。相关边界可参阅FakeDNS 原理与适用场景。

电量排查可以分三轮进行：先以正常配置完成固定任务，再检查锁屏空闲时是否持续产生异常流量，最后复现一次网络切换。记录每轮的客户端状态、任务时长和错误类型，比只记录电池百分比更有效。若某轮出现重复认证错误，应先修正参数，再继续比较，否则观察到的只是错误配置的重试成本。

v2rayNG 的具体后台策略可结合安卓耗电与后台运行排查操作。长期使用的目标应是稳定完成任务并减少异常唤醒，而不是让客户端在系统统计中尽量接近零。协议选择只是其中一个环节，后台策略、流量来源和网络质量通常同样重要。

Xray 与 V2Fly 内核家族

共同来源不意味着配置永久等价

V2Fly 延续 Project V 的相关实现与社区维护，Xray 从同一技术生态发展出独立的功能路线。两者存在共同概念和部分相似配置结构，但各自维护功能、字段与行为。理解家族关系，有助于辨认协议名称和配置术语；把这种关系理解成“配置文件可以随意互换”，则会在实际迁移中遇到问题。兼容性应落实到具体功能和字段，而不是只看项目来源。

Xray 对 REALITY 和相关 VLESS 流控组合的支持，是常见选型因素。V2Fly 则有自身的协议、传输与路由实现范围。判断支持情况时，应以当前安装内核的能力为准，而不是根据某篇旧文章或客户端历史截图。功能可能演进，字段也可能调整；本页不把某一时刻的全部功能表当作永久承诺，迁移前应结合客户端日志和对应配置说明确认。

v2rayN 是桌面图形客户端，承担服务器管理、订阅解析、系统代理和内核启动等任务。客户端能展示某个设置，只说明界面提供了表达入口；配置最终仍由选中的内核执行。切换内核后，原先可用的字段可能不再受支持，甚至某些服务器记录不适合新内核。切换前应确认当前入口所需的协议、安全层和流控，而不是只比较内核名称。

安卓客户端按所需能力选择

v2rayNG 以 Xray 内核能力为主要选型方向，适合需要相应协议组合的安卓使用场景。v2flyNG 是 V2Fly 家族的安卓备选入口，适合与其实现范围匹配的配置。两款客户端的界面和配置导入体验可能相近，但这不保证同一个分享链接导入后具有相同行为。尤其是包含特定安全方案或扩展字段的链接，应先核对内核能力，再检查界面显示。

客户端更新与内核更新也不是完全相同的事情。图形界面负责解析订阅并生成运行配置，内核负责实际通信；其中任意一层较旧，都可能影响新字段的使用。只替换内核不能保证旧界面会生成正确参数，只更新界面也不能保证当前执行文件实现所需能力。遇到“字段存在但不起作用”的情况，应同时确认配置生成路径与实际启动的内核。

配置迁移以实际字段为单位

Xray 与 V2Fly 的配置迁移应从最小连接开始。先建立只有一个远端出口的基础配置，确认认证和安全握手，再逐步迁移路由、DNS 与其他附加设置。直接复制包含大量规则的完整配置，即使启动成功，也难以判断哪个字段被忽略或采用不同默认行为。程序没有立即退出，只能说明通过了某些启动检查，不能证明每条业务路径都符合预期。

路由资产和内核配置也需要区分。某些规则引用域名分类或地址分类数据，相关文件是否可用、分类名称是否存在、加载路径是否正确，都会影响结果。把原客户端的路由文本复制过去却没有相应数据，可能出现加载失败或匹配不符合预期。此类问题通常不是远端代理协议失效，应在启动日志和规则命中行为中单独验证。

自定义配置应明确由谁维护。图形客户端可能在重载、订阅更新或修改设置后重新生成运行文件，直接编辑生成结果未必会长期保留。需要自定义字段时，优先使用客户端提供的对应入口，并确认保存位置和覆盖规则。导出配置用于对照时，注意其中可能包含认证信息；提交问题前应移除地址、用户标识和密码等敏感内容。

内核选择的顺序应是先满足必要能力，再考察稳定性与维护成本。已有 V2Fly 配置工作正常且不需要额外能力，可以继续使用匹配的客户端；需要 REALITY 等特定组合时，则选择能够完整表达并执行该配置的 Xray 路径。安装包按系统与芯片区分，统一从客户端下载页选择，不需要为协议名称寻找另一个独立客户端。

分享链接与订阅格式兼容

导入成功只代表解析了一部分信息

订阅是配置分发方式，不是新的代理协议。订阅地址返回的内容可能是一组分享链接，也可能是某种结构化配置；客户端需要先识别格式，再转换为内部记录。导入时显示了服务器名称，只能说明解析器读到了一些内容。认证、安全层、传输字段是否完整，仍需进入编辑界面确认。名称正确、数量正常和连接可用，是三个不同层面的结果。

VMess 分享链接常见对编码后的结构化信息进行封装，VLESS 与 Trojan 链接常以地址和查询参数表达选项，Shadowsocks 链接则还需要注意认证部分的编码方式及扩展参数。不同生成工具对字段名称和编码细节的处理可能不同，不能只按链接前缀判断兼容性。遇到新字段时，旧解析器可能忽略它而非报错，因此“没有提示错误”不是完整兼容的证明。

订阅响应中的 Base64 编码只是内容包装方式，不是安全加密。持有订阅地址的人往往能够读取其中的服务器和认证信息，因此地址本身应按敏感凭据管理。不要把完整订阅链接放入公开截图、日志或问题描述，也不要把订阅响应交给不明转换服务。需要对比格式时，可以在本地查看必要字段，并用脱敏副本说明问题。

按字段对照，比重新导入更有效

v2rayN 与 v2rayNG 对照同一条入口时，建议依次核对地址、端口、认证、传输、安全层、服务器名称和附加参数。REALITY 组合还需核对公钥材料、短标识、指纹与流控；WebSocket 需要核对路径和请求主机；gRPC 则需要确认服务名称。字段为空时，先确认它是合法默认值还是导入丢失，不要用另一个入口的值补齐。

特殊字符会增加导入差异。密码、备注或路径中出现保留字符时，需要按分享格式正确编码；重复编码可能让客户端读到编码文本本身，而不是原始值。手工复制时也应注意换行、首尾空格和被聊天工具截断的内容。若同一链接在一个客户端正常、另一个失败，可先比较解析后的字段，避免反复更新订阅却没有改变任何实际参数。

结构化配置与分享链接不是等价容器。完整配置可能包含多个出口、路由规则、DNS、入站和策略，而单条分享链接通常只表达一个远端入口及有限附加信息。把完整配置转换成链接列表，可能保留服务器却丢失分流和解析语义。反向导入也不会自动恢复原来的全局行为，因此迁移时必须分别处理服务器记录与客户端全局设置。

短配置示例：规则引用也有依赖

下面是 Xray 或 V2Fly 配置中常见的路由片段写法，用于说明出口标签如何被规则引用。它不是完整运行文件，需要合并到已有配置，并确保已定义名为 direct 的直连出口。规则使用私有地址范围，不依赖额外分类数据；它只处理这一类地址，不代表已经覆盖域名分流、DNS 和所有局域网发现业务。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "fc00::/7"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

这段配置也说明了为什么不能只验证 JSON 语法。即使括号与引号全部正确，如果出口标签不存在，或者图形客户端生成了另一套路由结构，片段也不能按预期工作。规则顺序同样重要，更早命中的规则可能决定出口。使用图形客户端时，应优先通过路由设置表达目标，不要把示例直接覆盖到客户端生成的整个配置文件。

订阅更新后若部分入口消失，应先检查返回格式、分组过滤和解析提示，再判断服务是否撤下。更新失败则应区分订阅地址访问、认证响应和内容解析三个阶段。保留一条已验证可用的配置作为排查基线，有助于判断问题来自分发格式还是连接本身；常见操作疑问可在帮助中心继续查阅。

按场景选型与验证

先列约束，再选择组合

v2rayN 桌面使用应先确认服务端提供的组合和本机接入要求。日常浏览只需要系统代理时，可以先保持接入路径简单；需要处理不读取系统代理的应用时，再评估 TUN。协议选择则依据现有入口：VMess 部署维护正常即可继续使用，Trojan 需要正确的 TLS 条件，VLESS 需要配套安全层，Shadowsocks 需要明确方法与密钥要求。客户端功能多，不代表每次都需要全部启用。

v2rayNG 移动使用应把稳定恢复和后台成本放在同一个评估框架中。需要 REALITY 等 Xray 能力时，选择能够完整导入相应参数的配置；使用与 V2Fly 实现匹配的入口时，也可以评估 v2flyNG。两款客户端不要同时承担同一系统 VPN 接入任务。对照前应停止另一款的服务，以免把系统接入切换带来的中断误判为远端协议问题。

开发和办公任务通常同时涉及浏览器、命令行工具、内部地址及依赖仓库。系统代理不一定覆盖所有工具，部分程序还会使用自己的代理设置。此时优先核对接入范围与路由例外，而不是立即更换远端协议。内部地址通常需要明确的直连路径，DNS 也要能解析相应名称；若仅有某一个工具失败，应从该工具实际采用的代理配置开始排查。

用分阶段验证代替一次性判断

第一阶段确认客户端和内核正常启动。启动失败应优先看字段格式、功能支持和文件依赖，暂时不要调整系统代理。第二阶段验证一条远端连接，观察地址解析、安全握手和认证是否完成。第三阶段让实际应用接入，确认其请求进入客户端。第四阶段再验证路由、DNS 和特殊流量类型。每阶段有明确结果，才能知道下一次修改应该发生在哪一层。

连接通过但网站打不开时，应进一步区分目标解析失败、路由选错出口和目标服务异常。某个测试地址可达，只能证明那条路径成功。浏览器可能缓存解析结果，应用也可能保留旧连接，因此改完设置后应重新发起请求，必要时重启受影响应用。不要同时清空所有设置，否则虽然暂时恢复，却难以知道真正改变了哪一个条件。

DNS 验证需要结合期望路径，而不是只看是否得到了地址。直连 DNS、远程 DNS 和服务端地址解析各有用途，路由规则还可能影响解析请求本身。某些检测结果也受浏览器安全 DNS 和缓存影响，不能只凭一个页面的单次输出下结论。完整操作可参阅v2rayN 与 v2rayNG 的 DNS 路径检测，先明确目标，再验证请求实际走向。

保留基线，按能力迁移

配置迁移建议保留原有可用入口，先导入新组合并完成独立测试，再迁移分组和默认选择。若新配置需要不同内核，应先核对其他常用入口是否兼容，避免修复一条连接却影响整组配置。订阅更新后也应抽查关键字段，尤其是安全层、流控与传输参数。对长期使用的配置，记录修改原因比保存大量难以区分的副本更有帮助。

排查记录可以保持简洁：写明客户端、内核家族、协议组合、接入方式、失败阶段和最近一次改动。不要记录或公开完整密码、用户标识和订阅地址。日志应围绕复现时间筛选，避免大量无关输出掩盖真正的错误。向配置提供方询问时，描述“安全握手失败”或“导入后流控缺失”通常比只说“速度慢”更容易得到可执行的答复。

选型的最终标准是必要能力得到满足、日常任务能够重复完成、异常时能够定位到具体层次。不存在脱离设备和网络条件的永久速度榜，也不存在单靠更换协议名称就能解决的所有问题。先使用匹配服务端的完整配置，再控制变量比较稳定性、资源与电量，才能形成可靠结论。需要开始配置时返回入门指南，需要安装包时前往客户端下载页，参数概念则可继续在本页按章节查阅。