V2Ray 协议与内核参考

配置分层：先读懂字段位置

客户端里的“服务器类型”并不描述整条连接。一次代理连接通常同时涉及应用入口、代理协议、底层传输、安全设置和路由出口。地址与端口只回答连接到哪里，UUID 或密码回答如何认证，TCP 或 WebSocket 回答字节怎样承载，TLS 或 REALITY 则属于另一组安全协商设置。把这些字段分开理解，比背诵一串组合名称更有用，也能避免把服务端要求的安全方式误填到协议下拉框。

协议、传输和安全层的边界

VMess、VLESS、Trojan 和 Shadowsocks 是本页讨论的代理协议。它们规定客户端与服务端如何表达目标地址、验证身份以及组织代理数据，但具体能力和安全模型并不相同。TCP、WebSocket、gRPC 等属于承载方式；TLS 是广泛使用的传输安全机制；REALITY 是 Xray 生态中的安全传输方案，通常与 VLESS 一起出现，却不是与 VLESS 平级、可以单独替换服务器类型的选项。

阅读一份 VLESS 配置时，先确认服务器类型，再核对传输方式，最后检查安全层。例如服务端要求 TCP 与 REALITY，客户端不能因为看到同样的 UUID，就改为 WebSocket 与普通 TLS。反过来，同为 VMess 的两条记录，也可能因为路径、主机名或传输方式不同而不能互换。实际可用性取决于整套参数是否一致，而不是列表中的协议简称是否相同。

地址、名称与路径不是同一个参数

服务器地址用于建立底层连接，TLS 的服务器名称用于名称验证和协商，WebSocket 的 Host 则属于应用层请求信息。这些值有时相同，但不能因此认为它们永远绑定。只有服务端明确提供了不同值时才分别填写，不要凭经验复制到每个文本框。端口也只是服务监听入口：某个常见端口并不自动意味着已经启用 TLS，更不能证明传输方式正确。

WebSocket 路径需要与服务端及反向代理配置一致，开头的斜杠、大小写和查询部分都可能影响匹配。gRPC 的服务名称与普通网页路径也不是同一概念。导入后界面出现空白字段，不一定就是缺失，有的协议不需要该字段，有的客户端会使用默认值；判断前先核对协议和传输组合，不要把其他教程中的路径直接补进去。

本地入口与远端协议分别排查

桌面应用连接本地 SOCKS 或 HTTP 入口后，内核才会根据路由选择直连或代理出口。本地端口不是远端服务器端口，修改其中一个不会同步改变另一个。系统代理也不是协议的一部分：它只影响愿意读取系统代理设置的应用。某个程序未经过代理时，应先确认它采用什么接入方式，而不是立刻替换远端协议。

安卓 VPN 模式则通过系统虚拟网络接口接收符合范围的流量，再交给内核处理；它与桌面的系统代理具有不同的覆盖边界。看到连接图标，只能说明本地接入已建立，不能证明远端认证、域名解析和路由都正确。按“本地是否收到请求、路由选到哪里、远端能否连接”的顺序阅读日志，可以把多个问题拆成独立检查点。

VMess 与 VLESS 的设计取舍

VMess 与 VLESS 都常见于 Project V 相关客户端，但设计目标不同。VMess 来自 V2Ray 的早期协议体系，将身份认证、请求组织和数据保护等能力纳入协议设计；VLESS 在 Xray 生态中广泛使用，采用较轻量的协议结构，把安全传输更多交给外层机制。两者没有脱离服务端条件的优劣排名，选择的起点应是服务端提供什么，以及当前内核是否支持完整组合。

VMess：区分现代认证与旧配置

VMess 的 UUID 是身份参数，不是服务器地址，也不是可以自由生成后就直接替换的备注。现代 VMess 配置应使用 AEAD 认证方式；旧资料里的额外 ID 或 alterId 属于历史兼容背景，不能照着旧教程随意填入一个非零数字。服务端与内核对旧模式的支持范围可能不同，导入旧订阅后应先确认提供方给出的当前配置要求。

VMess 的认证涉及时间，设备时钟明显偏差可能造成认证失败。遇到地址可达但握手失败时，先检查系统日期、时区和自动校时，再检查 UUID 与服务端状态。不过“VMess 失败就是时间问题”同样不准确，传输路径、外层 TLS 和远端端口错误也会表现为连接失败。日志中出现的错误阶段，比单纯的超时提示更能缩小排查范围。

VMess 可与不同承载方式组合，因此它的资源开销不能只按协议名称估计。VMess 加 WebSocket 和 TLS，与另一条直接承载的配置，在握手、封装和连接复用方面可能存在差别。若现有 VMess 配置工作稳定，订阅更新正常且符合业务需要，没有必要只因另一个名称更常见就更换。迁移应有具体目的，例如统一内核支持或减少不必要的传输层。

VLESS：轻量头部不等于完整安全方案

VLESS 主要处理代理请求与身份信息，本身不提供与 VMess 相同的载荷加密机制。客户端中常见的 encryption 为 none，是这一协议字段的正常取值，不代表整条连接必然以明文传输。是否具有传输保护，需要继续查看外层 TLS、REALITY 或部署中的其他安全安排。因此不能只截取“none”一个字段，就对整体安全性下结论。

同样，也不能因为 UUID 看起来复杂，就认为 VLESS 可以省略外层保护。身份标识与保密传输解决的是不同问题。普通用户应按服务端交付的安全组合完整导入，不要为了减少设置项把安全层关闭。若提供方只给出一条缺少安全说明的记录，应先确认部署边界与用途，而不是把它当成通用公网配置直接使用。

flow、传输方式与服务端能力

VLESS 的 flow 字段不是通用加速开关。部分 Xray 配置会使用 xtls-rprx-vision，它要求服务端、客户端内核及承载方式满足相应条件。把这一值复制到任意 VLESS 记录，可能导致配置被拒绝或握手失败。尤其不要在没有服务端依据时，把直接传输的设置与 WebSocket、gRPC 的字段混合拼接，最终形成名称正确但组合无效的记录。

客户端编辑器能显示某个选项，也不保证当前选定内核实现了该选项。核对 VLESS 时，建议依次检查 UUID、传输方式、安全类型、服务器名称和 flow；REALITY 相关公钥与短标识再单独核对。参数一致后仍失败，应记录内核日志中的具体错误，并到帮助中心按认证、握手、解析三个方向继续排查。

实际选型可以保持简单：已有且维护中的 VMess 服务继续按原参数使用；服务端提供 VLESS 与明确的 TLS 或 REALITY 参数时，再选支持该组合的 Xray 客户端。不要把协议迁移理解成改一个类型下拉框。两边的认证结构和安全配置不同，迁移需要服务端提供一套新的完整记录，并保留旧配置用于对照验证。

Trojan、SS 与 REALITY

Trojan、Shadowsocks 与 REALITY 经常同时出现在订阅列表里，但并不是三个同层级的替代项。前两者是代理协议，REALITY 属于安全传输方案。比较时应写出完整组合，例如 Trojan 与 TLS、VLESS 与 REALITY，或 Shadowsocks 的具体加密方法。只说某条记录“用了 REALITY”仍不足以判断它需要哪种客户端和哪些参数。

Trojan：把 TLS 当作基础条件

Trojan 的设计建立在 TLS 安全连接之上，客户端通常通过密码认证代理请求。配置时既要核对密码，也要核对服务器名称与证书验证条件。服务器地址可以是域名或地址值，但用于 TLS 的名称必须符合服务端证书和配置要求。地址可连接而名称不匹配，依然可能在建立代理请求之前失败，这不是修改密码就能解决的问题。

遇到证书错误时，不应把跳过证书验证作为常规修复。关闭验证会改变连接的安全边界，也可能掩盖填错名称、设备时间不准或服务端证书异常。先检查名称、时间和证书有效性，再联系服务提供方确认配置。如果某个专用测试环境确实使用自签名证书，也应按该环境的信任配置处理，而不是将测试做法扩散到日常记录。

Shadowsocks：方法名称也是协议条件

Shadowsocks 常缩写为 SS，围绕轻量代理与加密传输形成了独立的协议体系。客户端一般需要地址、端口、密码和加密方法。加密方法不是可以自由选择的本地偏好，必须与服务端一致。旧流加密方法、常见 AEAD 方法与较新的协议变体具有不同兼容范围，不能因为客户端下拉框里有相似名称，就认为它们能够互通。

密码格式也可能随方法变化。某些方法接受用户熟悉的文本密码，某些新方法要求特定长度的编码密钥；把文本口令直接填进去，可能在本地解析阶段就报错。订阅导入若只显示地址与密码，而没有保留方法、插件或额外参数，应视为不完整记录。是否需要插件，要以服务端说明与内核支持为准，不能自行删除后假定功能不变。

SS 的优势常在配置简洁和较少的封装层，但这并不保证它在所有设备上更省电或吞吐更高。实际结果仍受加密实现、处理器能力、传输质量和应用请求模式影响。需要 UDP 的业务还应确认服务端与本地入口都支持 UDP 转发；仅仅完成一次网页访问，无法验证这一能力，更不能用网页成功推断所有应用都能工作。

REALITY：核对公钥、短标识与名称

REALITY 采用与普通证书部署不同的认证安排。用户常接触的字段包括服务器名称、公钥、短标识与客户端指纹。公钥必须对应服务端配置，不能从普通证书内容中随便截取；短标识也应逐字保留，不要因看起来像备注而删除。短标识是否允许为空取决于服务端，不应拿其他记录的值补齐。

客户端指纹描述握手特征相关设置，不是设备身份认证密码。它需要使用当前内核支持的值，并与部署要求相符；随意更换并不等于提高性能。服务器名称也不是任意选取的网页域名，应使用服务端允许的名称。连接失败时，按名称、公钥、短标识、指纹、时间和 flow 的顺序检查，通常比反复切换端口更有针对性。

最终选择仍应从服务端能力出发。需要标准证书验证流程时，可评估维护明确的 Trojan 配置；已有 SS 服务时，先确认方法兼容；使用 REALITY 时，优先选择明确支持该组合的 Xray 内核。三者之间没有只修改协议名称就完成的迁移方式，订阅中的完整参数才是客户端建立连接的依据。

连接速度与资源开销

“连接快”至少包含三个不同指标：第一次请求建立成功的时间、连续下载的吞吐，以及页面上许多小请求完成的时间。协议头部更短，可能减少少量处理工作，但不代表跨网络的往返次数更少；持续吞吐更高，也不一定让首次打开页面更快。选型前先确定主要业务是短请求、长连接、视频传输还是频繁休眠后的唤醒，避免用一个测试替代所有场景。

把握手链路拆开看

一次冷启动请求可能依次经过域名解析、底层连接、安全协商、代理认证和目标站点连接。某些传输还会加入额外的应用层建立过程。每一阶段的耗时都会影响首个响应，因此服务端距离、解析状态和丢包情况，往往比协议之间的固定头部差异更明显。如果域名解析一直超时，换用另一种认证协议并不能直接消除这个等待。

WebSocket 和 gRPC 等承载方式适合特定的部署结构，但也会引入自己的封装和连接管理行为。直接承载的链路在结构上通常更简单，却必须与服务端入口条件相符。不要为了追求“少一层”而擅自删除传输配置；那会让请求无法到达正确服务，而不是得到一个更快的等价连接。比较时应使用服务端实际提供的可用组合。

CPU、内存与吞吐的关系

加密计算、用户态数据转发、缓冲区复制和规则匹配都会消耗资源。设备是否具有相关硬件加速，内核是否采用高效实现，应用是否同时建立很多连接，都会改变结果。低端设备可能先碰到 CPU 限制，桌面设备则可能主要受远端带宽限制。仅凭协议名字给出固定资源排名，会掩盖真正的瓶颈，也不利于定位可调整的设置。

内存占用也不等同于协议负担。规则数据库、域名解析缓存、连接数量、客户端界面和日志缓存都可能占用内存。客户端长时间运行后的占用高于刚启动，并不能直接说明协议泄漏。观察时应区分客户端进程与内核进程，保持相同的业务负载，并确认是否有持续增长且不回落的现象，再决定是否需要报告问题。

复用与保活需要按业务验证

连接复用可以减少重复建立连接的成本，但也会让多路业务共享部分传输状态。底层丢包、服务端实现以及连接关闭策略，都可能影响效果。对于已经使用成熟多路传输的组合，再额外打开某个复用选项，不一定有收益。出现部分网站卡住或大文件正常、小请求异常时，可在副本配置中关闭额外复用，比较问题是否随之消失。

保活同样存在取舍。较积极的保活可能减少空闲后的重连，却会增加移动网络无线模块被唤醒的机会；较保守的设置可能降低后台活动，但首个请求需要重新建立连接。对桌面常供电设备与安卓待机设备，不宜套用同一套“性能优化”设置。默认值通常是更适合开始验证的基线，只有观察到具体问题时再调整。

可重复的对照方法

先关闭后台下载并保持相同路由，确认两个配置访问同一业务出口；然后分别进行一次冷启动访问和一段持续传输，重复几轮而不是只看单次结果。记录失败率、首次响应、持续传输是否平稳，以及设备是否明显发热。客户端里的延迟测试可能只覆盖某个测试地址或某段握手，不能自动代表完整网页和 UDP 业务的体验。

若两条配置使用不同服务器，只能得出“这两条配置在当前条件下表现不同”，不能据此证明某个协议必然更快。需要隔离协议影响时，服务端位置、带宽和负载应尽量一致。无法控制条件时，把兼容性、维护成本和持续可用性放在前面，比依据一次测试的细小差距反复切换更实际。

V2Fly 与 Xray 内核家族

Project V 是理解这一生态的背景。V2Ray 最初形成了可组合的入站、出站、路由和传输架构；V2Fly 延续 V2Ray 相关内核的发展，Xray 则从这一技术基础分支演进，并增加自身的协议与传输能力。二者共享部分术语和配置思路，但已经不是可以无条件互换的两个文件名。选内核时，应核对具体功能，而不是仅凭共同来源判断兼容。

图形客户端不等于代理内核

v2rayN 负责桌面上的服务器管理、订阅更新、设置编辑与内核运行控制，实际的数据处理由选定内核承担。v2rayNG 是安卓端常用的 Xray 客户端选择，v2flyNG 则提供 V2Fly 内核方向的备选。客户端界面是否有某个按钮，与内核是否支持相关协议是两件事；外观相近的记录，在不同内核下也可能生成不同的配置。

桌面端优先使用 v2rayN，可以将订阅分组、日志与系统代理操作集中在一个界面中。若使用它的核心类型设置，应先确认目标协议需要什么实现，再切换内核。安卓端则更适合按应用所使用的内核家族选择客户端，不要把在桌面上切换核心的操作路径，直接套到安卓菜单中。具体入口以当前安装的界面为准。

共享字段不代表完整配置兼容

两类内核都可能识别地址、端口、用户、路由规则等基础概念，但支持的传输名称、协议扩展、配置结构和默认行为可能不同。REALITY 与 Vision 等能力，应在 Xray 支持范围内核对；不能因为 V2Fly 能读出 VLESS 类型，就推断它能处理所有 Xray 的 VLESS 组合。反向迁移时，同样需要检查来源配置中的特有功能。

订阅经过客户端解析后，通常会生成适用于当前内核的配置。手动粘贴整份 JSON 则绕过了部分转换过程，容易把另一内核专用字段带进去。启动失败时，先读日志里的未知字段、未知协议或参数无效提示，再检查配置来源。不要为了让程序启动而批量删除报错字段，因为删掉的可能正是连接必需的认证或安全条件。

路由规则：语义与资源一起检查

路由配置依赖出站标识和规则数据库。即使规则写法可解析，目标出站标签不存在，或引用的 geosite 分类未包含在本地数据中，仍可能导致启动失败或分流不符合预期。下面是 Xray 路由对象的局部示例，用于说明私有地址优先直连的语义；它不是可独立启动的完整配置，合并前需确认存在名为 direct 的直连出站，并准备相应规则数据。

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

这条规则只处理已能按 IP 条件匹配的请求；AsIs 不会为了 IP 规则主动解析所有域名，因此它不能单独替代完整的局域网域名与解析方案。实际规则应根据本地服务访问方式补齐。数据库的来源、更新和引用写法，可接着阅读geoip.dat 与 geosite.dat 规则数据库说明，避免把数据库缺失误判为协议不兼容。

升级与切换的回退边界

内核升级可能修复问题、增加功能，也可能收紧旧配置的校验。升级前保存客户端配置与关键自定义项，升级后先用一条已知可用记录确认基础连接，再检查订阅、路由和特殊传输。切换内核时应先停止当前连接，避免把旧进程状态与新配置混在一起。日志能说明新内核是否真正启动，比只看界面名称更可靠。

开源协议也不应笼统合并描述。V2Fly 的核心项目通常采用 MIT 许可，Xray 的核心项目采用 MPL 2.0；客户端、依赖组件与附带数据各自可能有不同许可，应以对应发行内容的声明为准。对日常用户而言，开源意味着实现与许可可以查阅，并不替代配置核对、证书验证和对服务提供方的独立判断。

订阅格式与参数兼容性

订阅是配置分发方式，不是代理协议。订阅地址返回的可能是分享链接列表、经过 Base64 编码的文本，或某种客户端使用的结构化配置。客户端必须先理解外层格式，再把每条记录转换为自己的服务器模型，最后生成内核配置。因此“订阅地址能够打开”“列表能够导入”和“服务器能够连接”是三个不同阶段，任何一个成功都不能替代后续检查。

分享链接能够携带多少信息

常见分享链接使用协议前缀区分类型，但不同协议和历史实现对字段的编码方式并不完全相同。VMess 链接常见编码后的结构化内容，VLESS 与 Trojan 链接常用地址加查询参数表达传输与安全设置，SS 也存在不同的编码形态。备注通常是界面展示信息，不参与认证；查询参数里的路径、名称和安全字段则可能直接决定能否建立连接。

导入器可能识别一个协议前缀，却不支持链接中的某个扩展字段。此时界面能显示服务器，不代表完整保留了 flow、公钥、短标识、服务名称或插件参数。导入后应进入编辑界面，按协议、安全与传输三组逐项检查。对复杂记录，尤其要留意字段被置空、采用旧默认值，或客户端把未知内容忽略的情况。

Base64 是编码，不是访问保护

把链接列表编码为 Base64，可以便于文本分发，但不会让其中的账户信息具有保密性。订阅地址本身也可能包含具有访问权限的令牌，转发链接通常意味着转交更新权限。不要把完整订阅地址、二维码或服务器详情贴到公开日志中；请求帮助时保留协议类型、错误阶段与经过遮盖的字段名称，就能先完成大部分兼容性判断。

订阅更新后列表为空，可能是返回了登录页面、错误提示或不受支持的格式，不一定是节点真的被全部删除。先核对链接有效性与订阅格式，再检查更新是否需要经过已有代理。若当前代理恰好失效，而更新又依赖它，就可能形成循环。更完整的检查顺序见订阅更新失败与解析为空自查清单，不要连续删除分组后反复导入。

不同客户端之间如何迁移

迁移到 v2rayN、v2rayNG 或 v2flyNG 时，优先使用目标客户端支持的原始订阅，而不是先经过多个转换工具。每增加一次格式转换，都可能丢失目标格式无法表达的字段。若订阅提供方提供多种输出，应选择明确面向当前客户端和内核的形式；某种其他配置格式可下载，并不意味着这三款客户端一定能直接读取。

本地导出的单条分享链接适合少量记录迁移，但通常不包含全部路由、DNS、应用范围和界面偏好。导入服务器成功之后，仍需在新设备上重新检查这些本地设置。安卓的应用分流范围不会自然变成桌面系统代理设置；桌面的自定义路由也不一定随单条服务器链接带过去。把账户配置与设备策略分开备份，迁移时更容易核对缺项。

更新后的记录与手动修改

订阅分组中的记录可能在更新时被重新生成，因此直接修改订阅节点的端口、名称或安全字段，未必能够长期保留。需要测试调整时，先复制成独立记录，并清楚标注来源与修改目的。这样后续更新不会悄悄覆盖测试条件，也不会让用户误以为提供方已经修改了参数。恢复时删除副本即可，不必重建整个分组。

管理多组订阅时，用用途和来源区分分组，比仅按协议分类更便于维护。一个订阅内可以包含多种协议，它们也可能在不同时间调整参数。每次更新后先检查常用记录是否仍在、当前选中项是否变化，再执行一次真实访问。发现异常时保留更新前的可用副本，有助于分辨服务端变化、解析差异与本地内核问题。

安卓电量与后台行为

移动端电量不能只按协议名称判断。安卓设备运行代理时，耗电来自无线网络传输、CPU 处理、系统虚拟网络接口、后台应用请求以及连接保活等多个部分。大量小请求反复唤醒蜂窝网络，可能比一次连续下载更影响待机；较弱信号下重传和网络搜索，也可能掩盖协议之间的差别。因此应先区分“正在大量使用时耗电”与“息屏待机仍有持续活动”。

v2rayNG 与 v2flyNG 的选择边界

需要 Xray 特有组合时，安卓端优先考虑 v2rayNG；服务配置明确依赖 V2Fly 能力或需要沿用对应内核时，再评估 v2flyNG。两款客户端不应同时作为活动 VPN 运行，系统对 VPN 服务有自己的占用约束。对照测试时先停止前一款，再启动另一款，并保持相同应用范围与路由，否则比较出来的是两套不同业务负载，而非内核差异。

首次启动 VPN 服务时，系统授权确认属于本地流量接入过程，不代表服务端已经连接成功。建立后应访问一个实际目标，观察日志是否出现有效请求与正确出口。若只有部分应用无法访问，先检查应用代理范围和绕过设置。把应用排除在 VPN 之外后，它的访问行为不再能验证代理服务器是否正常，测试时需要明确自己正在使用哪条路径。

后台限制与连接稳定性的平衡

系统省电策略可能限制后台服务、网络活动或自动启动。若表现为息屏后连接中断、回到客户端立即恢复，可先查看系统是否限制了该应用的后台运行，再根据使用需求调整。不同设备菜单名称不同，应以系统电池管理页面为准。允许后台运行有助于持续连接，但不意味着应把所有相关应用都放开，调整范围应尽量小并可回退。

如果连接始终存在却持续发热，应先查看是否有后台同步、重试失败或异常 DNS 请求。反复失败的请求会造成连接重建，表面看像代理进程耗电，根因却可能是某个应用不断重试。临时缩小应用范围或使用已知正常的路由预设，有助于隔离来源。日志只需在排查期间提高详细程度，持续输出大量日志也会增加处理和存储活动。

DNS、UDP 与应用范围

域名解析策略会影响连接前的等待和请求数量。解析地址不可达、规则把解析流量送到错误出口，或本地与远端解析结果不一致，都可能导致重复尝试。不要为了“更快”同时添加许多解析服务器而不理解查询策略；先保留一套可解释的解析路径，确认普通域名、局域网服务和代理目标各自按预期处理，再逐项扩展。

实时通信和部分互动业务可能依赖 UDP。若协议、服务端或接入链路没有完整支持，应用可能回退到其他方式，或不断重试，进而影响体验与电量。网页浏览正常不能说明 UDP 正常。测试时应使用实际需要的业务，检查是否出现持续断续、长时间建立或异常重连，再结合内核日志判断，不要把所有问题都归因于安卓后台限制。

电量对照应覆盖真实待机

比较时选择相近信号与相近使用时长，保持屏幕亮度、应用范围和后台同步一致。一组观察主动使用，另一组观察息屏待机，并记录系统电池统计中的应用活动。系统百分比是估算值，短时间内的细小变化不宜作为结论；更有意义的是重复出现的待机唤醒、持续发热或连接重建现象，而不是一次测量里谁少了一个百分点。

若局域网设备访问异常，先确认私有地址与本地域名的路由，而不是把所有流量强制交给代理。需要按区域与用途组合规则时，可参考v2rayNG 分流配置实战。规则越符合实际业务，越容易减少不必要的远端绕行。稳定、可解释的设置通常比堆叠所谓省电参数更便于长期维护。

场景选型与连接验证

选型应从约束逐层收敛：先确认设备平台，再确认服务端提供的完整协议组合，随后选择兼容内核，最后根据业务决定路由和接入范围。协议不是独立购买的性能选项，而是客户端与服务端共同遵守的通信条件。若订阅只提供一种可维护配置，就先把这一种验证完整，再考虑是否有必要请求其他组合，避免为了名称更新而引入额外管理成本。

桌面常用、安卓移动与既有服务

Windows、macOS 与 Linux 桌面端优先选择 v2rayN，按处理器架构和系统包格式进入下载页。日常浏览与开发应用共用时，先使用清楚的系统代理与本地入口设置，确认哪些程序读取系统设置。某个程序需要显式 SOCKS 参数时，应在该程序中配置入口，不要把“全局路由模式”误解为自动接管所有应用的网络。

安卓端以服务端组合决定 v2rayNG 或 v2flyNG，再根据需要设置全部应用或指定应用范围。移动网络与无线网络切换后，底层连接可能需要重建，不能用旧连接瞬间中断就判断协议不稳定。若重建一直失败，再检查解析变化、远端可达性和后台限制。经常访问本地设备的用户，还应把局域网地址与相关域名作为单独验证项目。

已有稳定的 VMess、Trojan 或 SS 服务时，优先维护准确参数与订阅更新；服务端提供 VLESS 与 REALITY 时，选择明确支持其安全字段和 flow 的 Xray 路径。需要减少设备负担时，先排除不必要的转发层、异常重试和大量后台业务，而不是只更换协议。对低性能设备，简单且受支持的组合通常比复杂参数叠加更容易验证。

建立一份可复查的验收顺序

第一步看本地配置是否能启动。内核若直接退出，先处理字段无效、端口占用或数据库缺失；这时请求尚未正常发往远端。第二步检查地址解析与远端入口是否可达。第三步观察安全协商和协议认证。只有前三步完成，才继续排查目标站点、DNS 与分流。按阶段处理，可以避免把本地语法错误误认为服务器不稳定。

第四步验证具体业务：打开普通网页、访问需要的工作服务、检查局域网地址，并在确有需求时测试 UDP 应用。第五步验证空闲恢复与网络切换。每一步都记录使用的客户端、内核家族、协议组合和结果，不必公开账户内容。若某一步失败，保留当时的简短日志，比不断切换服务器后留下混杂日志更适合求助。

规则顺序与验证目标

路由通常按顺序匹配，前面的宽泛规则可能覆盖后面的精确条件。调整协议后若部分站点行为变化，应先确认实际生成的路由和默认出口，而不是只比较编辑器中的服务器类型。需要自定义域名与地址条件时，可阅读Xray 自定义路由规则与匹配顺序；规则应围绕具体业务建立，不要一次导入大量无法解释的例外。

验收通过后，保留一条已知可用配置作为基线。今后订阅更新、内核切换或系统升级，都先用它做最小验证，再恢复复杂分流与特殊选项。基线不是永远不更新，而是让每次变化都有可比较的起点。完成选择后，日常操作回到快速上手教程即可；本手册保留用于核对协议边界、兼容字段与故障阶段，不需要每次连接前重新调整全部参数。