V2Ray 协议手册
协议类型与内核选型

01 · 协议分层与 VMess

节点名称不是完整的连接定义

客户端里的一个服务器条目，通常包含服务器地址、端口、代理协议、传输方式、传输安全和认证凭据。协议回答如何标记目标、认证用户和组织请求；传输回答字节通过哪种承载方式送达；安全层负责连接身份与传输保护。订阅备注可能只写一个协议名，但实际连接依赖整组参数。仅把下拉框从 VMess 改成 VLESS，不能把原有服务转换成另一种协议。

排查前先把配置拆成三层记录：出站协议是什么，底层传输是什么，安全设置是什么。例如 VMess 可以搭配 WebSocket 和 TLS；VLESS 可以搭配直接传输和 REALITY。两条配置即使地址相同，也可能由不同端口或入口接收。页面中的组合只是结构解释，能否使用仍由服务端配置决定。客户端负责按约定发起连接，不能自动补齐远端不存在的能力。

VMess 的设计背景与认证特点

VMess 是 Project V 早期建立代理体系时采用的核心协议之一，将用户认证和代理请求封装放在协议层处理，并可与不同传输组合。它不是单一的套接字转发格式，也不等于某一种外层加密连接。理解这一点有助于解释：同样叫 VMess 的配置，可能在握手流程、外层保护、连接复用与网络行为上明显不同，不能只凭名称推断实际性能。

现代 VMess 配置应以支持 AEAD 认证的实现为基础。旧资料中的额外身份数量和旧认证路径，不应直接沿用到新配置。客户端若仍展示 alterId 一类历史字段，应核对订阅来源与内核说明，常见现代配置使用零值。这里的认证方式与负载加密算法不是同一个概念，不能把安全下拉框中出现的算法选项当成认证代际的证明。

系统时间对 VMess 的认证过程有实际影响。设备长期休眠、手工修改时间或时间同步失效，可能让地址与凭据都正确的配置仍被拒绝。先确认时区显示与实际时间的区别：界面时区不同不必然有问题，真实时钟偏差才需要处理。排查时先恢复系统自动校时，再重试连接，避免把时间错误误判为服务器失效或协议不兼容。

字段检查顺序与适用边界

导入后先检查地址、端口与用户标识，再检查传输类型，最后核对 TLS、服务器名称及传输路径。用户标识属于认证材料，应完整保存，但不应出现在公开截图中。传输路径并非本地文件路径；WebSocket 的 Host 也不总是服务器地址。它们可能参与远端入口匹配，因此不能因为看起来重复就删掉，更不能把域名字段全部替换成解析得到的地址。

VMess 的负载加密选择取决于内核实现、处理器能力和服务端设置。带硬件加速的处理器可能更适合某类算法，移动设备的实际表现还受系统调度影响。自动选择通常适合作为基线；只有在双方明确支持且有可复现测试时，才值得手工指定算法。关闭某一层负载加密不意味着整个连接已经获得另一层保护，外层安全需要独立确认。

已有稳定 VMess 配置时，不必仅为更换名称而迁移。若需要新能力，先检查现有内核是否支持，再向配置提供方取得完整的新入口。比较迁移前后表现时，应保持设备、网络、目标和测试时段尽量一致。否则，远端入口变化带来的差异很容易被错误归因于协议本身，最终留下难以复现的速度结论。

02 · VLESS 与 REALITY

轻量协议不等于省略传输保护

VLESS 在 V2Ray 生态中以精简认证与请求封装为设计方向。与 VMess 相比，它不在基础协议层承担同样的负载加密职责，而是依靠配套的传输安全方案保护连接。因此，“协议更轻”描述的是职责划分，不是允许在任意网络上直接明文使用。常见 VLESS 配置中的 encryption 为 none，表示该字段的协议设置，并不表示整条连接没有安全层。

客户端选中 VLESS 后，还需要确认远端使用 TLS、REALITY 或其他明确支持的组合。安全下拉框不能根据个人偏好切换，因为远端握手入口必须采用相同方案。用户标识相同，也不足以证明两个入口可以互换。若导入器把未知安全类型降为默认值，表面上仍会生成服务器条目，但实际握手可能已经偏离原配置，应立即回到参数页核对。

REALITY 是安全方案，不是独立代理协议

REALITY 属于 Xray 生态中的传输安全方案，常与 VLESS 配合。它改变的是安全握手及其认证方式，不负责替代代理协议的目标地址与用户请求语义。订阅里写“REALITY 节点”，通常是对整组连接的简称。选型时仍需问清其基础协议、传输和流控设置，而不是在协议列表中寻找一个能够替代 VLESS 的 REALITY 类型。

与常见证书部署流程相比，REALITY 使用自身的认证参数和握手机制。客户端一般需要服务器名称、公钥相关认证参数、短标识，以及实现要求的客户端指纹。公钥不是客户端用户标识，短标识也不是任意备注。部分客户端与内核对这些字段的显示名称会变化，应按导入来源和当前实现对应检查，不应只凭字段位置照抄旧教程。

服务器名称参与握手与身份校验相关流程，通常应在服务端允许的范围内。它不要求与连接地址在文本上完全相同，却也不能随意换成任意域名。连接地址决定客户端先连向哪里，服务器名称影响安全握手如何构造和验证。把两者合并为一个“域名”理解，会使排查方向混乱；地址可达而认证失败，就是应当分层检查的典型情况。

Vision、指纹与传输的组合约束

XTLS Vision 常通过 flow 字段表达，典型值为 xtls-rprx-vision。它处理特定连接组合中的数据流方式，不是越填越快的通用加速开关。是否启用，取决于服务端、内核和传输组合。尤其不要把适用于直接传输的配置机械搬到 WebSocket 等承载方式上；若提供方没有指定流控，不能仅因另一条配置有该值就自行补上。

客户端指纹控制部分 TLS 客户端握手特征，但它不等于安装了对应浏览器，也不保证所有应用行为都随之改变。指纹选项需要内核支持，名称相同的界面控件也可能由不同实现处理。遇到连接失败时，先恢复订阅原值并查看日志中的安全层错误，再判断是否属于不支持的指纹、认证参数错误或服务器名称不匹配。

需要 REALITY 或 Vision 时，Android 端优先核对 v2rayNG 所带 Xray 的支持情况，桌面端在 v2rayN 中确认实际启用的内核。已有 VLESS 配置但缺少关键认证参数时，应重新获取完整分享内容，而不是尝试猜测。有关实现家族的进一步区别见内核家族章节；协议名称一致，只能作为兼容检查的起点。

03 · Trojan 与 Shadowsocks

Trojan：依托 TLS 的认证与代理请求

Trojan 的设计把代理认证和请求放在 TLS 连接之内，常见配置以密码作为用户认证材料。它的直观特点是协议层与外层安全边界较清楚：先建立符合设置的 TLS 连接，再交换代理请求。选择 Trojan 并不代表证书问题会自动消失。服务器名称、证书信任链与设备时间仍须正确，任何一项异常都可能在代理认证开始前终止连接。

标准 Trojan 连接通常不需要填写 VMess 那样的用户标识。若从其他协议复制配置后保留了不相关字段，客户端可能忽略它们，也可能生成错误设置。正确做法是新建对应协议条目，按原始分享内容填写密码、地址、端口与安全参数。密码中包含特殊字符时，手工拼接分享链接容易产生转义错误，优先使用客户端提供的导入和导出功能。

证书验证失败时，不应把跳过验证当作常规处理。先检查连接地址与服务器名称是否混淆，再检查系统时间、证书有效期、证书链以及远端是否确实提供 TLS。允许不安全连接会改变身份验证边界，可能使错误端点也被接受。若只为定位原因临时调整，应明确记录并及时恢复；长期配置应解决验证失败的根因。

Shadowsocks：方法与密钥共同定义兼容性

Shadowsocks 常被简称为 SS，设计上采用相对紧凑的加密代理封装。它与 VMess、Trojan 的认证和数据组织不同，不能用密码字段相似来判断兼容。选择 SS 时，至少要确认服务器地址、端口、加密方法和密码或密钥。方法名称是协议约定的一部分，不是客户端可以独立替换的本地偏好，双方必须采用匹配的算法及密钥解释。

较早的流加密方法、后来的 AEAD 方法以及 Shadowsocks 2022 系列，存在不同的设计与配置要求。现代部署通常应优先考虑仍受当前实现支持的 AEAD 方案，但“支持 SS”不等于支持所有代际。尤其是较新的方法可能要求特定格式和长度的密钥，不能把任意短密码填入后期待内核自动推导成兼容值。具体格式应以远端方法说明为准。

SS 的分享链接也有多种历史编码方式。有的把方法与密码一起编码，有的把认证部分单独编码，后面还可能附带备注或插件参数。导入失败时，应先确认链接完整、编码没有被聊天软件截断，再判断是否为当前客户端不支持的扩展。把编码内容反复解码后随意拼回去，往往会破坏特殊字符与分隔符，造成新的错误。

不要把额外封装当成协议默认能力

某些 SS 配置依赖额外插件或专门的外层封装。原始协议支持与插件支持是两项不同能力；图形客户端能识别方法名称，也不代表已经具备对应的插件运行环境。本手册不把额外客户端列入推荐清单。遇到依赖额外组件的分享内容，先确认 v2rayN、v2rayNG 或 v2flyNG 的当前实现是否能够完整承载，再决定是否保留该配置。

UDP 是另一条需要单独核对的路径。某个协议规范允许转发 UDP，不等于订阅入口、远端服务、客户端模式和本地应用已经全部开启。网页访问成功只能证明部分 TCP 请求可用，无法证明实时音视频或其他数据报业务正常。出现应用特定故障时，应检查是否发生回退、目标端口是否受支持，以及路由规则是否把两类流量分到了不同出站。

在已有完整兼容配置的前提下，Trojan 适合希望沿用常见 TLS 运维方式的入口；SS 适合已有对应部署且明确掌握方法要求的场景。它们都不能仅凭封装看起来较少就被判定为更快。若需要更换协议，应取得远端为新协议实际开放的入口，而不是保留原端口后只修改客户端类型。

04 · 连接速度、资源与移动端电量

把首个请求与持续传输分开比较

一次访问的耗时可以来自域名解析、连接建立、安全握手、代理认证和目标响应。协议只影响其中一部分。短连接较多的应用对握手成本敏感，大文件传输则更容易受链路带宽、拥塞控制和远端出口限制。比较协议前，应先明确测的是打开页面、首次响应还是持续吞吐；把这些指标混为一个速度值，无法解释问题发生在哪一层。

外层传输可能引入额外请求或握手，也可能因为连接复用减少后续开销。启用 TLS、采用 WebSocket 或使用支持多流的传输，并不对应固定的快慢顺序。网络往返时间较长时，额外往返的影响可能更明显；连接已复用时，单次新请求又可能不再承担完整初始化成本。因此，同一配置第一次打开与连续刷新得到的体验并不能直接相互替代。

持续传输中的处理器开销取决于算法实现、硬件加速、缓冲区处理和数据复制等因素。桌面处理器与移动芯片即使使用同一协议，也可能呈现不同瓶颈。只有在处理器确实持续繁忙、链路仍有余量时，才适合讨论加密或封装开销。若所有配置都在相近位置停住，应先检查网络与远端资源，而不是继续轮换协议名称。

Mux 不是通用性能开关

Mux 将多个逻辑连接放入较少的承载连接，可能降低频繁建立连接的成本，也可能让多个请求共同承受同一条链路的阻塞。它的收益取决于协议、传输、内核实现和业务类型。某些组合自带多流机制，额外叠加传统 Mux 未必有价值；某些流控方案还存在组合限制。测试时应先使用原配置，再一次只改变一个复用设置。

移动端的电量消耗不只来自加密计算。VPN 服务持续运行、应用后台轮询、域名解析重试和网络切换，都可能唤醒处理器或无线模块。若客户端自身耗电上升，同时其他应用也在大量联网，应先观察业务来源。某个应用通过代理访问时，它触发的网络成本可能部分计入 VPN 服务，不能直接把系统统计中的全部消耗解释为协议效率问题。

后台限制、保活与网络切换

电池优化限制过严会终止后台服务，导致连接中断后反复重建；全部放开限制也可能延长不必要的后台运行。合理做法是先确认是否真的存在服务被回收，再对客户端调整必要的后台权限。不要同时修改系统保活、Mux、DNS 和分应用规则。一次调整过多变量，即使耗电下降，也难以判断是业务减少还是协议配置发生了改善。

从无线局域网切换到移动网络时，原连接通常需要重建，解析缓存和网络接口状态也可能变化。此时短暂失败不一定是认证错误。先等待网络稳定，再手动重连一次，并记录日志发生在解析、连接还是握手阶段。若仅在某类网络下失败，应检查该网络的地址族、路径 MTU 与可达性，避免为了掩盖链路问题反复更换认证参数。

可复现的比较需要固定设备、应用、目标和网络环境，分别观察冷启动访问、连续请求与空闲后台。每轮只换一个因素，并给连接足够时间稳定。测试期间避免后台下载、系统更新和其他高负载任务。无需追求一个适用于所有人的排名；有价值的结论应当能回答：在当前设备和这类业务中，哪组设置减少了失败、重建或持续资源占用。

分应用代理可以减少不需要代理的应用经过 VPN 转发，但需要考虑应用间跳转、登录组件和系统服务依赖。只代理主应用而遗漏认证组件，可能出现页面能开、登录失败的情况。性能优化应以功能完整为前提。确认业务可用后，再减少不必要的代理范围和后台活动，比单纯选择听起来更轻的协议更容易获得稳定结果。

05 · Project V、V2Fly 与 Xray

客户端界面与内核不是同一层

Project V 是理解 V2Ray 生态的背景入口。V2Fly 延续 V2Ray 的社区开发，Xray 则从相关代码体系分出并发展出自己的功能方向。两者共享部分历史和配置概念，但已经不能当作同一程序的不同名字。协议名称、JSON 字段或目录布局相似，只说明存在共同基础，不意味着新功能会在两个实现中同时出现，或相同配置始终具有相同行为。

图形客户端承担订阅管理、配置编辑、路由选择和启动控制等工作，内核负责实际建立与转发连接。界面可以提供多个选项，但真正运行时仍受所选内核限制。某个输入框能够填写，不代表内核接受；配置能够保存，也不代表该设置被传递到了最终运行文件。排查时必须同时确认客户端、内核家族和实际生效配置，而不只看窗口标题。

三款客户端的选择边界

桌面端首推 v2rayN，覆盖 Windows、macOS 和 Linux 的安装入口。它适合作为订阅、路由与桌面代理管理的统一界面，但不同系统的界面细节与系统集成不必完全一致。涉及协议能力时，要检查其当前启用的核心实现及实际打包内容。不能因为另一台设备上的 v2rayN 能用某种组合，就推断当前安装也已具备同样能力。

Android 端的 v2rayNG 采用 Xray 内核，适合需要相应协议组合的配置；v2flyNG 使用 V2Fly 内核，可作为对应实现的备选。选择依据是现有配置需要哪些能力，而不是把名称相似理解为可以任意替换。若订阅明确要求 REALITY 或 Vision，应优先确认 Xray 路径；若维护的是 V2Fly 配置，则应按 V2Fly 的当前字段与行为检查。

两套内核都存在广泛使用的协议与传输能力，但支持范围和具体语义会随实现演进。REALITY 与 Vision 属于核对 Xray 能力时的重要项目，不能把带这些字段的出站原样交给 V2Fly。反过来，某个 V2Fly 特有的传输或配置结构，也不应默认被 Xray 兼容。更换内核应逐项核对，不宜把整个文件覆盖后仅看是否能够启动。

配置迁移应检查结构和语义

内核配置通常包含入站、出站、路由、DNS 和日志等部分。迁移只复制出站时，可能遗漏出站标签所引用的路由或 DNS 策略；复制全量配置时，又可能带入本机不存在的监听地址、端口和文件路径。应先保留可用备份，再分模块转移。即使字段校验通过，也要检查目标流量是否进入预期出站，以及域名解析是否仍由原策略处理。

日志中的未知字段、无法识别的安全类型或不支持的流控，属于兼容性线索，不应通过删除报错字段来强行消除。删掉一个关键字段可能让程序启动，却让连接失去原先需要的语义。应先查明该字段由哪个实现提供，再决定改用匹配的内核，还是重新取得适配当前内核的配置。两种处理都比盲目删字段更容易维持可解释性。

更新客户端和更新内核也应区分。界面更新可能修复导入解析，内核更新可能改变协议支持，二者解决的问题不同。更新前保留订阅与本地规则，更新后先测试一条已知配置，再恢复复杂路由。若发生回归，应记录具体阶段与字段，而不是只记录“升级后不能用”。详细家族关系可继续阅读Xray 与 V2Fly 的差异和配置兼容性。

06 · 传输参数、路由与 DNS

路径、Host 与服务器名称各司其职

传输方式决定代理字节如何承载。直接基于 TCP 的连接结构相对直观；WebSocket 引入 HTTP 升级过程；gRPC 等传输则有各自的请求与多流语义。这些方式不是客户端独立决定的装饰选项，而是远端接收入口的一部分。服务端只接受某种传输时，本地改为另一种通常会在认证前失败，因此比较性能必须先确保对照组合都真实存在。

WebSocket 的路径用于请求路由，Host 可能参与反向代理的虚拟主机匹配，TLS 服务器名称则用于安全握手。三者可能相同，也可能按部署需要分别设置。路径中的大小写、前导斜杠与特殊字符都应完整保留。若反向代理没有把请求转发到正确的后端，即使证书握手成功，也可能只收到普通网页或错误响应，不能据此判断代理协议工作正常。

gRPC 常见的服务名称同样必须与远端匹配，它不是客户端中便于阅读的备注。ALPN 则用于安全连接中的应用协议协商，错误地限制候选项可能阻止所需传输建立。除非部署说明明确要求，不应照搬其他节点的 ALPN 列表。排查应沿地址可达、安全握手、承载协议、代理认证逐层推进，先确定失败位置，再调整对应字段。

路由顺序影响协议使用范围

选中一条代理出站，不代表所有流量都会使用它。系统代理、VPN 接管、应用自设代理与内核路由共同决定流量走向。系统代理只影响遵循相关设置的应用；VPN 或虚拟网卡模式接管范围更广，但也受排除项与权限限制。若某个应用始终表现不同，先确认请求有没有进入客户端，再研究出站协议，避免在入口层问题上浪费时间。

路由规则通常按顺序匹配。较宽泛的规则放在前面，可能使后面的精细规则永远没有机会生效；默认出站又会接收未匹配流量。下面展示的是规则片段，不是可独立运行的完整配置。它需要已有的 direct 与 block 出站，以及相应规则资源。合并时应检查标签是否存在，不应仅因语法是合法 JSON 就认定可以直接替换整个文件。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

DNS 与出站必须一起验证

DNS 不只是填入一个解析器地址。需要确认谁发起解析、解析请求走哪条出站，以及返回的地址如何参与后续路由。应用可能自己使用加密 DNS，系统也可能保留独立解析路径；内核 DNS 设置不必然接管这些请求。因此，在客户端填写远程 DNS 后，仍应验证实际请求路径，不能只根据设置页中的文字判断解析已经跟随代理。

远程解析还可能产生启动依赖。如果代理服务器本身使用域名，而解析该域名的解析器又必须通过尚未建立的代理访问，就会形成循环。应为服务器域名提供明确可达的解析路径，同时避免让这条启动路径意外接收全部业务域名。区分服务器地址解析与目标站点解析，有助于解释为什么某些配置只有清空缓存后才暴露故障。

FakeDNS 以合成地址帮助保留域名关联，适用于特定接管与路由组合，但不是简单开启就完成的防泄漏选项。合成地址必须回到能够识别它的处理路径；若被不相关的应用或出站当成真实地址使用，就会连接失败。缓存、地址族与规则也需协同。具体验证方法见DNS 请求路径检测与配置实操，修改前先保存原设置。

完成传输与 DNS 调整后，至少分别验证按域名访问、需要解析的代理入口，以及业务所需的数据报连接。若只用一个网页判断，缓存可能掩盖解析问题，复用连接也可能掩盖握手问题。测试应包含一次新建连接，并在日志中确认命中的出站标签。这样才能区分协议不可用、规则未命中和解析路径错误三类常见原因。

07 · 订阅格式与跨客户端兼容

订阅是分发格式，不是通信协议

订阅链接用于取得一组服务器描述，客户端再把这些描述转换为实际运行配置。它本身不定义数据如何传输，也不代表订阅中的每个条目都适合当前内核。一次更新成功，只能说明内容获取和解析流程完成了某些步骤。随后仍须检查条目数量之外的质量信息：协议类型是否正确、安全参数是否保留，以及当前内核能否解释这些字段。

常见内容包括逐行分享链接、经过编码的链接集合以及面向特定实现的完整配置。扩展名或网址外观不足以确定真实格式，客户端应根据实际返回内容识别。若拿到的是网页、登录提示或错误文本，复制更多次也不会变成订阅数据。排查时先确认来源是否需要授权、返回内容是否符合约定，再处理解析兼容性，而不是首先重装客户端。

能识别前缀，不代表保留了全部语义

VMess 分享内容常携带结构化字段；VLESS 与 Trojan 分享链接通常通过地址及查询参数描述安全和传输；SS 又有不同历史编码方式。各客户端对别名、可选参数和扩展字段的覆盖范围可能不同。导入器若忽略未知参数，仍可能显示一个看似完整的条目。因此，跨客户端迁移后应打开编辑页面逐项对照，而不能只看名称和地址一致。

最容易遗漏的是服务器名称、流控、指纹、短标识、传输路径和服务名称。某些参数仅在特定安全或传输类型下出现，类型一旦识别错误，后续字段就可能被隐藏或清空。发现原始分享中有字段而界面没有对应项时，应先确认客户端和内核是否支持。不要把未知参数塞进备注，也不要用外观相似的另一个输入框替代。

订阅通常描述连接入口，不一定包含完整路由、DNS、系统代理和分应用规则。两台设备导入同一订阅后，访问行为仍可能不同，因为本地策略并未同步。桌面到 Android 的迁移尤其需要区分这两部分：先迁移服务器，再单独审查路由与 VPN 设置。相关流程见多设备订阅、分享码与备份导入方案。

更新、分组与本地修改的边界

自动更新通常由订阅源重新生成对应分组中的条目。本地手工修改可能在下次更新时丢失，具体行为取决于客户端实现。需要长期保留的实验配置，宜复制到明确的手动分组，并记录它与订阅原条目的关系。不要在同一分组中混放来源不明的修改，再依赖备注猜测哪些条目会被更新覆盖。更新前后应抽查关键安全参数，而不仅观察排序。

订阅过滤和备注正则只影响条目如何进入或显示在列表中，不会自动验证协议可用性。过滤条件过严，可能把原本可用的入口排除；名称相似也不代表配置相同。排查“更新后找不到服务器”时，先关闭筛选并检查分组，再判断来源是否真的删除了条目。管理方式可参考订阅分组与服务器过滤，避免把展示问题误判为内核故障。

二维码只是文本的另一种载体，并不会增加协议支持。扫码失败可能来自图片识别，扫码成功后导入失败则可能来自文本格式，两者应分开处理。可先在设备本地查看识别结果的协议前缀与结构，避免把含凭据的内容提交给不明转换服务。超长分享文本经过聊天软件转发时，也要留意换行、标点替换和末尾截断。

可靠的迁移记录应包含来源类型、客户端、内核家族和关键组合，而不只是一张服务器列表截图。迁移后先验证一条结构简单且来源明确的配置，再批量导入；验证通过后再恢复筛选、自动更新与复杂规则。若失败，可以沿获取、解析、生成、启动、握手五个阶段定位，避免反复替换全部配置而丢失最初的故障线索。

08 · 按使用场景完成选型

先列约束，再比较协议

选型的第一项不是速度排名，而是现有远端开放了哪些入口。随后确认设备系统、客户端、内核家族、所需业务和维护方式。若服务端只提供一种完整配置，就应先保证这条配置正确运行，再讨论是否有必要申请其他协议。客户端无法凭空转换远端能力；在本地修改协议类型，通常只会得到一个没有对应接收端的新配置。

桌面日常使用可先选择 v2rayN，导入原始订阅并保持默认可解释设置。需要 REALITY 或 Vision 时，确认选用支持该组合的 Xray 路径；已有稳定 VMess、Trojan 或 SS 配置时，先核对具体字段与内核支持，不必为了统一名称迁移。安装包和系统架构的选择留在下载页处理，本页的重点是安装之后如何判断配置是否匹配。

Android 与电量敏感场景

Android 端需要 Xray 特性时，优先检查 v2rayNG；维护 V2Fly 配置时，可以选择 v2flyNG 并按对应实现核对参数。首次测试先保持 Mux 和分应用规则处于易于解释的状态，再逐步调整。若后台断连，先检查系统是否回收 VPN 服务；若连接稳定但耗电增加，再观察应用请求和网络重建，避免把系统调度问题归到协议头部开销上。

电量敏感的设备应减少不必要的持续网络活动，而不是单纯追求最少字段。选择能稳定连接、较少重建且满足业务需求的组合，再根据实际应用范围设置分应用代理。需要实时音视频或数据报业务时，单独确认 UDP 路径。若仅有网页需求，可以先用普通浏览请求建立基线，但不要把这个基线扩展成所有应用均可用的结论。

已有稳定配置与新部署的不同判断

对已有稳定配置，维护成本应纳入决策。更换协议可能牵涉远端入口、安全参数、订阅生成和所有设备的兼容性，收益却未必来自协议本身。只有出现明确需求，例如当前内核缺少所需能力、握手成本确实成为瓶颈，或现有方法不再适合维护时，迁移才有清晰目标。目标应能通过测试验证，而不是一句笼统的“更新一些”。

对新部署，先选择双方都明确支持、文档齐全且便于检查的组合。需要常见 TLS 运维方式时可评估 Trojan 或匹配的 VLESS 组合；已有 SS 基础时，核对现代方法、密钥格式与数据报支持；使用 VMess 时，确认现代认证路径和时间同步。REALITY 的选择则应同时评估 Xray 支持及认证参数管理，不应只看客户端是否出现该名称。

用故障阶段收敛选择范围

若导入就失败，优先处理分享格式和客户端解析；若内核无法启动，检查字段结构与功能支持；若地址无法连接，检查解析、端口和链路；若安全握手失败，检查服务器名称、证书或 REALITY 参数；若握手成功但应用不可用，再检查代理认证、路由和接管范围。每个阶段都有不同证据，不应统一归纳为“协议不行”后直接更换全部设置。

保留一条已知可用配置很有价值。它可以帮助判断故障来自整台设备、当前网络，还是单个入口。对照时不要同时切换网络、内核和协议；先在原环境复测，再逐项替换。日志分享应隐藏凭据，但保留发生顺序与错误类别。若需要按操作步骤重新建立基线，可回到使用指南，具体问题再到FAQ按类别查找。

协议选型没有脱离环境的唯一答案。可维护的结果，是能够说明每个关键字段的来源，知道流量由什么方式进入内核，能区分解析与握手失败，并在更新后复现基本测试。把协议、安全层、传输和本地策略分别管理，再作为整体验证，才能在迁移设备或调整内核时保留稳定行为，而不是依赖一次偶然成功的连接。