V2Ray 协议与内核
技术参考

先拆开协议、传输与安全层

一个节点不是一个协议名称

客户端列表里显示“VLESS”或“VMess”，只是连接结构的一部分。完整节点至少包含服务器地址、端口、用户身份、代理协议、底层传输和安全参数。以 VLESS 为例，它可以直接运行在 TCP 上，也可以经由 WebSocket、gRPC 等传输承载；外层可以使用标准 TLS，也可以组合 REALITY。两条都叫 VLESS 的节点，如果传输层和安全层不同，握手次数、首包大小、连接复用方式以及故障特征都会不同。

分层理解的价值在于缩小排查范围。客户端提示“连接超时”时，问题可能位于域名解析、TCP 建连、TLS 握手、REALITY 参数匹配或代理协议认证。若只反复切换 VMess 与 VLESS，真正错误的服务器名称、端口或传输路径不会因此改变。正确顺序是先确认网络层可达，再确认安全层可以完成握手，最后检查协议身份和路由规则。

常见连接栈如何组合

VMess 自带用户标识与时间相关认证，常见组合包括 VMess over TCP、VMess over WebSocket 并叠加 TLS。VLESS 将协议层做得更轻，通常把机密性和服务端身份确认交给 TLS 或 REALITY。Trojan 的常见形态是 Trojan over TLS，认证信息在受保护的连接中传递。Shadowsocks 使用约定的 AEAD 加密方法直接保护数据流，配置项相对集中。REALITY 则不是与 VMess、VLESS 平级的代理协议，它是 Xray 体系中的传输安全方案，最常与 VLESS 组合。

WebSocket、gRPC、HTTPUpgrade 和原生 TCP 也不是认证协议。它们决定数据如何装入底层连接。WebSocket 兼容成熟的 HTTP 基础设施，但会增加帧封装；gRPC 基于 HTTP/2，适合复用和流式传输，但需要客户端、服务端及中间链路保持一致；原生 TCP 路径短，参数少，通常更容易定位问题。QUIC 类传输建立在 UDP 上，能否表现良好取决于网络对 UDP 的质量和超时策略，不能只根据理论特性判断。

比较时保持其他变量一致

协议测试需要控制变量。服务器硬件、线路、加密算法、传输方式、并发数和测试目标必须尽量一致。把一条近距离 VLESS 节点与一条远距离 VMess 节点直接比较，只能说明两条完整链路的结果，不能证明协议本身更快。下载测速还会受到服务器出口带宽和目标站限速影响；短连接测试更偏向握手开销；长时间大流量传输更能观察持续吞吐和 CPU 占用。

客户端中的“延迟”也需要区分。ICMP ping、TCP 建连时间、真实代理握手和经代理访问测试地址是不同指标。详细原理可参阅延迟测试原理拆解。选型时应优先看真实连接是否稳定、常用应用是否正常，以及连续使用后的资源变化，而不是只取列表中最小的一个数字。

五类方案的背景与设计取舍

VMess：完整认证机制与成熟兼容面

VMess 是 Project V 生态早期形成的核心协议之一。它把用户身份、请求元数据和动态认证纳入协议结构，配置中最常见的身份字段是 UUID。VMess 的优势不是参数最少，而是长期积累形成的客户端支持和配置经验。许多既有订阅、面板输出与旧配置仍以 VMess 为基础，因此在需要兼容已有环境时，它经常是稳妥选择。

VMess 认证与系统时间存在关联。设备时间偏差过大时，即使地址、端口和 UUID 全部正确，也可能无法完成认证。因此遇到“同一节点在一台设备可用、另一台设备立即失败”时，需要把系统自动校时列入检查项。VMess 还存在不同加密或安全选项，客户端自动值通常用于适配内核能力；手工指定时必须确认服务端支持，不能把旧教程中的固定值直接套入所有配置。

VLESS：简化协议层，依赖外部安全层

VLESS 的设计重点是减少协议自身承担的加密和认证负担。它保留轻量的身份识别与代理请求表达，把传输机密性主要交给 TLS 或 REALITY 等安全层处理。这样做减少了重复加密的可能，也让协议层与安全层的职责更清楚。代价是配置不能只停留在 UUID：流控、传输、安全类型、服务器名称和公钥等字段都会影响最终连接。

VLESS 本身并不等于“已加密”。如果订阅显示 VLESS，需要继续查看 security 字段。使用 TLS 时要核对服务器名称和证书关系；使用 REALITY 时还要核对公钥、短标识、指纹和服务器名称。客户端界面把这些字段分散在不同区域时，用户容易只复制地址与 UUID，结果是节点被成功保存但无法建立连接。

Trojan：以 TLS 作为基本组成部分

Trojan 的典型配置以密码形式完成身份验证，并依赖 TLS 保护连接。它的概念模型相对直接：先正确完成 TLS 握手，再在受保护的数据中处理认证和代理请求。对使用者而言，最关键的字段通常是服务器地址、端口、密码、服务器名称和证书验证设置。若域名与证书不匹配，协议认证还未开始，连接就会在 TLS 层终止。

Trojan 的实际性能高度依赖 TLS 会话、网络往返时间和底层实现。它不因为名称简单就必然比 VMess 或 VLESS 更省资源。长连接下，握手成本会被持续传输摊薄；大量短连接下，TLS 会话复用和客户端连接池更重要。比较 Trojan 时，应观察客户端日志中失败发生在 TLS 还是认证阶段。

Shadowsocks：紧凑的加密代理结构

Shadowsocks 常被简称为 SS。它使用密码和加密方法派生会话所需信息，现代配置应使用受当前内核支持的 AEAD 方法。其配置字段较少，数据路径直接，适合希望降低配置复杂度的环境。需要注意的是，加密方法名称必须精确一致。把相近名称误认为同一算法，或使用客户端内核未实现的方法，都会导致连接失败。

Shadowsocks 的订阅表达存在多种历史形式。有的链接直接携带方法、密码、主机和端口，有的再附加插件参数。客户端能识别基础 SS 并不代表能识别所有插件组合。导入后应检查“加密方式”和“插件”字段是否完整，尤其不能只看节点名称已经出现在列表中就判断解析成功。

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

REALITY 属于 Xray 功能体系，通常与 VLESS 组合。客户端内看到的“VLESS REALITY”表示 VLESS 负责代理语义，REALITY 负责传输安全。其关键参数包括服务端公钥、短标识、服务器名称以及客户端指纹。公钥不是证书文件，短标识也不是用户 UUID；这些字段承担不同角色，互换后不会产生可用连接。

REALITY 的配置精度要求高，但并不意味着日常使用复杂。订阅完整、客户端内核支持且字段未被中间工具丢失时，导入后通常可以直接连接。问题主要出现在旧客户端无法识别字段、订阅转换器删除新参数，或手工录入时把 publicKey、shortId 和 serverName 放错位置。若使用 V2Fly 内核的客户端，需要先确认目标方案是否属于其支持范围，不能默认所有 Xray 扩展都可直接运行。

连接速度、吞吐与资源占用

首包速度主要受握手链路影响

用户感知的“打开速度”通常由 DNS 查询、底层连接、传输握手、安全握手、协议认证和目标站响应共同组成。协议层只占其中一部分。在高往返时延链路上，多一次需要等待对端响应的握手会明显放大首包时间；在本地低时延网络中，这种差异可能只有很小的体感。TLS 会话恢复、HTTP/2 连接复用和内核连接池会进一步改变结果。

VMess、VLESS、Trojan 与 Shadowsocks 都能维持长连接，但客户端和应用是否复用连接并不完全相同。浏览器可能复用 HTTP/2 或 HTTP/3 会话，命令行工具可能频繁新建连接，消息类应用则常驻少量长连接。测试一个网页不代表所有应用。选型时至少需要覆盖短连接页面、持续下载和常驻应用三类行为。

持续吞吐通常由线路与加密能力主导

进入稳定传输后，线路丢包、拥塞控制、服务器出口、设备单核性能和加密实现往往比协议头部大小更重要。VLESS 的协议层较轻，但如果外层传输产生额外复制或队头阻塞，最终吞吐未必更高。Shadowsocks 数据路径紧凑，但选用的加密方法是否具有硬件加速，会直接影响低功耗设备上的 CPU 占用。

桌面处理器通常具有较充足的单核性能，几种常见方案在普通浏览和视频场景中的差异容易被网络波动覆盖。路由器、低功耗主机和旧款 Android 设备更敏感。此时应关注持续高负载下 CPU 是否长期满载、设备是否降频、网络中断后能否迅速恢复，而不是只看一次测速峰值。有关路由设备的硬件门槛，可继续阅读V2Ray 内核在路由器与旁路由上的部署概览。

封装层会增加带宽和处理成本

原生 TCP 的封装路径通常最短。WebSocket 会增加帧头与 HTTP 升级过程，但兼容性成熟，很多场景下这部分开销相对业务数据很小。gRPC 基于 HTTP/2，能够利用多路复用，不过流控窗口、连接复用和中间链路对 HTTP/2 的处理都会影响实际表现。传输层越复杂，需要核对的参数越多，出现故障时也越需要分层查看日志。

小包密集应用更容易受到封装和调度影响。语音、游戏或实时控制流量对抖动和丢包敏感，平均下载速度不能代表体验。UDP 经代理时，还要考虑协议是否支持 UDP、客户端是否启用相关能力、网络是否频繁回收 UDP 映射，以及路由规则是否把相关域名和 IP 送入同一出口。任何一处不一致，都可能表现为登录正常但实时功能异常。

建立可复现的比较方法

测试时应固定设备、网络、服务器位置和目标文件，并关闭会改变路径的其他代理工具。先连续执行多次真实连接测试，记录中位数而不是最小值；再进行足够长的下载观察稳定吞吐；最后检查客户端进程和内核进程的 CPU、内存变化。若两种协议来自不同服务器，就只能评估节点整体质量，不能归因到协议设计。

还应区分冷启动和热连接。首次启动包含内核载入、DNS 缓存建立与安全会话创建；后续访问可能复用已有连接。若使用场景是频繁切换网络，冷启动和重连更重要；若设备长期在线，稳定性和后台资源更重要。没有一种协议能在所有这些指标上固定领先。

Android 设备的电量与后台行为

耗电不只来自加密运算

移动设备上的代理耗电由无线网络唤醒、CPU 计算、虚拟网卡转发、DNS 查询、连接保活和应用后台流量共同构成。协议加密只是其中一项。屏幕关闭后，如果大量应用持续建立短连接，蜂窝网络会反复从低功耗状态恢复，产生的能耗可能高于协议本身。反过来，少量稳定长连接即使使用 TLS，也可能保持较平稳的功耗。

v2rayNG 使用 Xray 内核，适合需要 VLESS、REALITY 等 Xray 功能的订阅；v2flyNG 使用 v2fly 内核，可作为面向 V2Fly 配置的选择。两者都可能通过 Android 的 VPN 接口接管流量。实际耗电取决于启用的路由范围、应用数量、DNS 策略和连接状态，不能仅凭客户端名称或协议名称判断。

虚拟网卡模式与系统代理的差异

Android 客户端通常通过系统提供的 VPN 接口转发应用流量。每个数据包需要经过用户态处理、路由判断和出站连接，规则越复杂、并发连接越多，调度负担越明显。桌面端 v2rayN 可以只设置系统代理，也可以使用 TUN 模式接管不遵循系统代理的程序。TUN 的原理和权限要求可参阅TUN 模式接管全局流量的设置说明。

移动设备没有必要让所有应用始终进入代理。若客户端支持按应用分流，可只选择确实需要处理的应用，减少无关后台流量。路由规则也应保持可解释：先定义局域网和必要直连，再处理代理规则，最后设置默认出口。大量重复或互相覆盖的规则不仅难以维护，还会让故障定位变得困难。

连接保活、重连和网络切换

Wi-Fi 与蜂窝网络切换时，原有 TCP 连接通常需要重新建立。客户端如果保留失效连接过久，应用会经历较长等待；如果过于频繁地探测和重连，又会增加唤醒次数。协议没有单独决定这一行为，内核的连接管理、Android 后台限制和应用自身重试策略都会参与。稳定使用时不建议同时开启多个周期很短的连通性测试。

WebSocket、gRPC 和原生 TCP 对网络切换的恢复方式不同，但结果仍依赖应用是否重新发起请求。QUIC 或其他基于 UDP 的传输具有不同的连接语义，不过移动网络对 UDP 的映射回收可能更积极。若表现为锁屏后恢复缓慢，应先确认客户端是否被系统限制后台运行，再观察日志中是网络不可达、DNS 超时还是远端连接被关闭。

DNS 策略会影响唤醒和失败重试

DNS 配置不一致会产生重复查询、超时和回退。客户端同时配置本地 DNS、远程 DNS、系统 DNS和应用自带加密 DNS 时，请求路径可能比预期复杂。更稳妥的方法是明确哪些域名由本地解析，哪些通过代理出口解析，并避免多个规则同时接管同一类查询。若节点服务器使用域名，还要确保用于连接服务器的解析不会被自身代理链路循环处理。

出现“浏览器可用但部分应用持续耗电”时，应查看这些应用是否不断访问失败域名，或是否使用未被当前代理方式接管的网络接口。核心日志中的重复超时行通常比电池统计中的单个百分比更有定位价值。日志若持续出现相同目标的快速重试，应先处理路由或 DNS，而不是立即更换协议。

如何做有意义的电量比较

比较两套配置时，应使用同一台设备、同一网络和相近的业务流量。充电状态、屏幕亮度、信号强度和后台同步都会干扰结果。至少观察一个完整的日常使用周期，并结合系统电池统计、客户端日志和设备温度判断。短时间打开页面后查看电量变化，样本不足，无法分离无线通信和协议计算的影响。

如果目标是降低资源消耗，优先减少无效连接、缩小代理应用范围、修正 DNS 超时并选择设备支持良好的加密实现。协议层应以兼容和稳定为前提。一个理论上头部更小、但在当前客户端持续报错重连的方案，实际耗电一定不会更好。

V2Fly 与 Xray 的内核家族关系

共同来源与不同演进方向

V2Fly 与 Xray 都源于 Project V 技术生态，保留了许多相似的配置概念：入站、出站、路由、DNS、策略和传输设置。两者能够处理 VMess、Shadowsocks 等多类常见配置，也都采用结构化配置描述连接关系。相似不等于完全相同。随着各自演进，新增协议能力、传输选项、字段名称和默认行为会出现差异。

Xray 在 VLESS、流控和 REALITY 等方向提供了相应能力，因此 v2rayN 与 v2rayNG 常使用 Xray 处理这类节点。v2flyNG 面向 v2fly 内核，更适合订阅本身按 V2Fly 能力生成的情况。客户端界面只是配置入口，最终能否连接取决于当前实际启动的内核是否理解这些字段。

配置相似不代表可以原样互换

基础出站结构在两个家族中可能十分接近，但扩展字段会构成兼容边界。例如一份包含 REALITY 设置的 Xray 配置，不能因为外层仍是 JSON 就推断 V2Fly 可以读取。未知字段可能导致启动时直接报错，也可能被忽略后产生与预期不同的行为。配置迁移必须按功能逐项确认，而不是只修改可执行内核名称。

即使协议名称双方都支持，传输细节也可能不同。需要核对 network、security、flow、streamSettings、TLS 参数和 DNS 结构。客户端自动生成配置时会按所选内核调整字段；手工导入完整 JSON 时，这层转换未必存在。因此普通用户应优先导入订阅或分享链接，让客户端生成运行配置，而不是长期维护跨内核的大型配置文件。

v2rayN、v2rayNG 与 v2flyNG 如何对应

桌面端首选 v2rayN，覆盖 Windows、macOS 与 Linux。它提供订阅管理、系统代理、路由模式和内核日志入口，适合统一管理多种桌面环境。Android 上，订阅包含 VLESS、REALITY 或明确依赖 Xray 的字段时，优先使用 v2rayNG；订阅按 V2Fly 能力输出，或需要验证 V2Fly 行为时，可以选择 v2flyNG。

这三款客户端并不是三种协议。客户端负责界面、配置生成、系统网络接管和内核进程管理；内核负责解析配置与转发流量；协议则描述客户端内核与服务端如何交换数据。把三层区分开后，很多问题会变得明确：分享链接无法导入属于客户端解析问题，内核启动失败属于配置兼容问题，握手失败则通常进入协议或安全层排查。

从日志判断兼容性问题

内核启动失败时，先读取日志第一条错误，而不是末尾重复的退出信息。未知字段、无法识别的协议类型、缺少必要参数和 JSON 语法错误通常会在启动阶段明确出现。具体方法可阅读从日志第一行定位内核启动失败。如果内核已经启动，但连接时失败，则继续查看 DNS、拨号、TLS 和认证相关行。

迁移配置后若只有部分节点失效，应把可用与不可用节点按协议、安全层和传输层分类。全部 REALITY 节点失败而 VMess 正常，优先检查内核能力；同协议中只有某一传输失败，优先检查 streamSettings；所有节点都无法启动，则检查配置文件整体结构、端口占用和权限。这样的分类比逐个删除重建节点更有效。

订阅格式与分享链接兼容性

订阅是容器，不等于协议

订阅链接通常返回一组节点描述。节点可以是 VMess、VLESS、Trojan 或 Shadowsocks，也可能包含客户端专用字段。订阅地址本身只负责定位内容，不能说明内部协议。客户端更新订阅后，需要先下载文本，再识别编码与格式，最后把每个节点转换为本地配置。任一阶段失败，用户看到的结果都可能是“没有节点”。

常见内容包括多条分享链接、经过编码的链接集合或结构化配置。不同客户端对扩展字段和组合格式的处理范围不同。订阅服务若输出 REALITY 参数，而中间转换步骤只保留基础 VLESS 字段，导入后节点仍会出现，但公钥、短标识或指纹已经缺失。这种情况比完全解析失败更隐蔽。

分享链接能表达什么

VMess 分享内容一般包含地址、端口、用户标识、传输和安全设置；VLESS 链接通过查询参数表达 encryption、security、type、flow、serverName、publicKey、shortId 等信息；Trojan 链接需要密码、地址、端口及 TLS 相关参数；Shadowsocks 链接主要表达加密方法、密码、服务器与端口，并可能附带插件参数。

链接参数名称区分明确。以 VLESS REALITY 为例，pbk 通常对应服务端公钥，sid 对应短标识，sni 对应服务器名称，fp 对应客户端指纹。某些客户端界面使用完整名称显示，订阅则使用短参数。导入后应对照字段含义，不要按显示顺序猜测。

vless://用户标识@example.invalid:443?encryption=none&security=reality&type=tcp&sni=www.example.invalid&fp=chrome&pbk=示例公钥&sid=示例短标识#VLESS-REALITY-示例

上面的结构用于说明字段位置，域名和身份信息是明确的示例值。真实节点必须使用服务端提供的完整参数。手工编辑链接时还要注意 URL 编码：节点名称中的空格、中文和特殊符号需要正确编码；密码中若含有保留字符，也不能直接按可见文本拼接。

导入成功不等于配置完整

客户端能够创建节点记录，只能证明最外层格式被识别。下一步应打开节点详情，检查协议类型、地址、端口、身份字段、传输方式和安全层。对于 WebSocket，要检查 path 与 Host；对于 gRPC，要检查 serviceName；对于 TLS，要检查 serverName；对于 REALITY，要检查 publicKey、shortId、fingerprint 与 flow。

若更新订阅后原有节点可用、新增节点不可用，应比较两者字段差异，并确认客户端内核能力。若全部节点消失，先确认订阅返回内容是否为空、地址是否被截断以及客户端是否识别当前格式。六类高频原因与检查顺序见订阅链接失效或解析失败的自查说明。

订阅更新与本地修改的覆盖关系

多数客户端在更新订阅时，会依据订阅分组重新生成节点。本地手工修改可能在下次更新后被覆盖。需要长期保留的自定义路由、DNS 和系统代理设置，应放在客户端提供的独立配置区域，而不是逐个修改订阅节点。临时修改节点用于验证问题时，建议复制为本地节点并改名，避免与订阅源混淆。

节点名称不是稳定标识。订阅提供方可以调整名称或排序，客户端也可能按地址、协议或内部标识去重。排查时应记录协议、服务器、端口和关键传输参数，而不是只说“第二个节点”。日志中的目标地址和出站标签更适合建立对应关系。

选择客户端时看字段保真度

桌面环境使用 v2rayN，可以在同一界面检查多类协议字段和运行日志。Android 订阅包含 Xray 扩展时使用 v2rayNG；明确面向 V2Fly 配置时使用 v2flyNG。若订阅同时包含多种协议，客户端应能逐条保留字段，而不是把所有节点强制转换为单一协议。

遇到复杂订阅时，最安全的判断方法不是反复经过多个转换环节，而是直接在目标客户端中导入原始订阅，并抽查不同协议各一条节点。确认字段完整后再进行连接测试。每增加一次格式转换，就增加一次字段丢失、默认值改变和编码错误的机会。

协议参数核对与故障定位

地址、端口和身份字段

排查任何协议都从最基础的三项开始：服务器地址能否解析，端口是否正确，身份字段是否完整。VMess 与 VLESS 常使用 UUID；Trojan 使用密码；Shadowsocks 使用密码和加密方法。复制时应清除首尾空格，但不能改变内容内部字符。端口必须是有效数字，并与服务端监听一致。

服务器地址是域名时，先确认客户端所在网络能够得到解析结果。若配置同时填写 IP 和 serverName，要理解两者用途不同：IP 决定连接目标，serverName 用于 TLS 或 REALITY 握手。把 serverName 替换为 IP 可能导致安全层失败；把连接地址改为证书域名，也可能改变实际线路。

TLS 与服务器名称

TLS 配置中，serverName 通常用于服务端身份确认和握手。它应与服务端配置及证书关系一致。客户端提供“跳过证书验证”一类选项时，不应把它当作常规修复方法。证书错误通常说明域名、时间、证书链或中间网络存在问题，关闭检查会掩盖根因，并使后续迁移更难判断。

系统时间也会影响证书有效期判断。若多种 TLS 节点同时失败，而非 TLS 节点正常，应检查设备时间、时区和证书相关日志。只有一个域名失败时，重点检查该节点的 serverName、目标地址和服务端证书配置。

REALITY 的四组关键参数

REALITY 客户端配置至少需要正确理解 publicKey、shortId、serverName 和 fingerprint。publicKey 来自服务端对应密钥；shortId 是服务端允许值之一；serverName 必须符合服务端设置；fingerprint 表示客户端握手指纹类型。VLESS 身份 UUID 仍然单独存在，不能用 publicKey 代替。

flow 字段也可能参与 VLESS 配置。服务端与客户端必须使用兼容值。订阅若明确给出 flow，应原样导入；若服务端未启用对应流控，不应依据其他节点经验自行添加。错误的 flow 可能让基础连接建立后仍无法正确传输，日志通常比客户端弹出的通用错误更具体。

WebSocket、gRPC 与路径字段

WebSocket 主要核对 path 和 Host。path 是否以斜杠开头、是否包含查询部分，应按服务端原值处理；Host 与 TLS serverName 可以相同，也可能承担不同作用。gRPC 主要核对 serviceName，并确认客户端与服务端对多路模式等选项理解一致。把 WebSocket 的 path 填入 gRPC serviceName，名称看似相近，协议行为完全不同。

当连接日志显示底层 TCP 已建立、TLS 也成功，但随后返回 HTTP 状态错误或流被关闭，应重点检查传输路径。若服务端前方存在反向代理，还要确保其支持对应升级或 HTTP/2 转发。客户端只负责发出配置指定的请求，无法自动推断正确路径。

使用最小变量法排查

先选择一条已知配置完整的节点，关闭自定义路由和额外 DNS 规则，使用客户端默认代理模式测试基础连接。基础连接成功后，再逐项恢复路由、TUN、应用分流和自定义 DNS。若一开始就同时修改协议、传输、路由与系统代理，失败后无法判断是哪一项造成。

日志需要从首次错误开始读取。重复重连会产生大量相似行，末尾通常只记录进程退出或上下文取消。保存一次干净测试：清空日志，启动内核，访问一个明确目标，等待错误出现后停止。这样可以把 DNS、拨号、握手和认证按时间顺序排列。

按使用场景选择协议与客户端

已有订阅优先保持原始配置

如果订阅已经给出可用节点，第一原则是按原始协议和参数导入，不要为了追求某个名称而手工转换。VMess 节点不能只改类型就变成 VLESS，Trojan 密码也不能直接作为 Shadowsocks 密码使用。协议转换需要服务端同时提供对应监听和参数，客户端单方面修改不会完成转换。

桌面用户优先选择 v2rayN，再根据订阅内容选择节点。Android 用户遇到 VLESS、REALITY 或其他 Xray 扩展时使用 v2rayNG；订阅明确按 V2Fly 内核生成时可使用 v2flyNG。对应安装入口集中在客户端下载页，平台说明包含 Windows、macOS、Android 与 Linux。

兼容旧环境时选择 VMess

已有服务器、订阅系统和客户端都稳定支持 VMess 时，没有必要仅因出现新协议就立即迁移。VMess 的配置资料和兼容经验较丰富，适合需要继续使用现有 WebSocket、TLS 或 TCP 组合的环境。需要重点维护系统时间、UUID、传输字段和安全设置。

如果计划逐步迁移，可以让服务端并行提供新旧入口，在相同线路和设备上测试。先验证功能与稳定性，再处理订阅切换。迁移期间保留可工作的原配置，能够区分新协议问题与服务器整体问题。

需要清晰分层时选择 VLESS

VLESS 适合希望把轻量协议层与 TLS、REALITY 等安全层明确组合的环境。使用标准 TLS 时，证书、serverName 和传输配置必须完整；使用 REALITY 时，需要 Xray 内核以及匹配的公钥、短标识、指纹和流控参数。它的优势来自完整连接栈的合理组合，不是单独把协议名称改为 VLESS。

在 v2rayN 和 v2rayNG 中导入 VLESS 分享链接后，应抽查 streamSettings。若订阅经过转换，尤其要确认 REALITY 参数没有被删除。配置准确时日常操作并不比其他协议复杂；配置来源不完整时，排查字段会比基础 VMess 更多。

以 TLS 配置为中心时考虑 Trojan

服务端已经按 Trojan 方式提供密码与 TLS 参数时，客户端直接使用对应节点即可。选型重点是证书和服务器名称是否正确、TLS 会话是否稳定，以及当前传输是否与服务端一致。Trojan 适合偏好清晰密码认证和 TLS 连接结构的环境，但不能绕过证书、网络和服务器配置的基本要求。

大量短连接场景应观察首包和会话复用，持续下载场景应观察稳定吞吐。不要仅根据协议结构推断性能。若 Trojan 节点与其他协议节点不在同一服务器，测试结果主要反映完整线路差异。

追求较少配置项时考虑 Shadowsocks

Shadowsocks 的基础配置集中在地址、端口、密码和加密方法，适合服务端已经提供受客户端支持的现代 AEAD 方法，并且不依赖复杂扩展的场景。低功耗设备上还应确认所选算法具有良好实现，不能把“参数少”直接等同于“任何设备都更快”。

如果分享链接带插件参数，需要确认客户端是否支持该插件和选项。基础 SS 可导入但插件字段丢失时，节点仍可能不可用。UDP 应用还要单独确认客户端、内核、服务端和网络链路都支持相应转发。

移动端优先稳定连接和清晰分流

Android 设备上，协议差异经常小于后台限制、信号强度和 DNS 重试造成的差异。先选择客户端内核明确支持的节点，再限制不必要的代理应用，保持路由规则简单，并观察网络切换后的恢复。若锁屏后异常，不要立即归因于协议。

需要长时间后台运行时，选择稳定、不会频繁重连的完整配置。一次测速略高但持续出现握手重试的节点，不适合作为后台默认连接。通过日志确认重连原因后，再决定是修正参数、换传输还是换节点。

最终决策顺序

第一步确认服务端实际提供什么协议和完整参数；第二步确认目标客户端与内核支持该组合；第三步导入后核对字段是否完整；第四步用真实连接、持续吞吐和常用应用测试稳定性；第五步再观察 CPU、内存、电量和网络切换。这个顺序能够避免把格式解析问题误判为协议问题，也能避免用单次延迟数字替代长期体验。

如果只需要完成安装、订阅和连接，返回快速上手教程按步骤操作。需要选择安装包时前往V2Ray 客户端下载页。遇到订阅解析、内核启动或延迟指标问题，可继续阅读本页已链接的专题文章。协议选择没有脱离服务端、内核和网络条件的统一答案，完整兼容与稳定运行应排在理论差异之前。