V2Ray 协议与内核技术参考

一、先分清协议、传输、安全与客户端

一条连接经过哪些设置

在 v2rayN 的「添加服务器」窗口中，协议类型只是入口。客户端还要知道服务器地址、端口、用户身份、传输方式和传输层安全设置，才能构造完整连接。例如选择 VLESS 后，地址可以填写 your-server.example，端口由服务器配置提供；用户身份通常是 UUID；传输协议可能是 tcp、ws 或 grpc；传输层安全则可能是 tls 或 reality。这些字段各司其职，不能因为协议类型相同就互换整套服务器参数。地址与端口决定连接目标，身份字段决定双方能否互认，传输和安全字段决定连接如何建立。

「代理协议」在这里主要指客户端与服务器之间如何组织请求、标识用户和传递目标地址。VMess、VLESS、Trojan 与 Shadowsocks 属于这一层。「传输」描述数据承载方式：tcp 直接使用流式连接，WebSocket 增加自己的握手与消息封装，gRPC 则基于 HTTP/2 的流。选用哪种传输取决于服务器实际开放的方式，而不是在客户端里任意切换。即使地址和身份都正确，只要路径、服务名或传输类型不一致，连接仍可能在握手阶段结束。

REALITY 不应填进协议类型栏

tls 与 reality 是传输层安全相关的选择；REALITY 本身不是与 VLESS 并列的独立代理协议。常见配置会把 VLESS、tcp、reality 同时列出，意思是使用 VLESS 组织代理数据，在 TCP 传输上按服务器要求建立 REALITY 连接。判断一个配置时，先找协议字段，再找传输字段，最后找安全字段。若分享文本只写「REALITY 节点」而未写协议，仍需查看其原始链接或提供方说明，不能仅凭标签创建服务器条目。

「内核」是解释并执行上述配置的程序。v2rayN 是 Windows、macOS、Linux 的桌面图形客户端，v2rayNG 与 v2flyNG 是 Android 图形客户端；界面负责管理条目、订阅与系统设置，实际可用字段还受其所用内核及内核版本影响。配置在界面中可以保存，不代表内核一定能启动它。遇到字段不识别时，应同时核对客户端、当前内核和服务器所要求的功能，而不是只检查服务器地址。

用字段清单代替协议猜测

收到单个服务器参数时，可以依次记录协议、地址、端口、身份信息、传输、安全类型，以及传输专属参数。WebSocket 常涉及 Host 与路径；gRPC 要核对 serviceName；TLS 往往要核对服务器名称；REALITY 还需核对公钥、短标识及服务端给出的其他握手参数。缺项时，先向配置提供方取得原始信息。把「某协议通常使用某端口」当成固定规则并不可靠：端口是服务器设置，不能从协议名称反推。

本页讨论的是客户端字段如何对应服务端配置，而不是建议修改未知服务器的既有设置。导入订阅后，图形界面可能将复杂参数折叠到编辑窗口里。需要确认时先打开条目详情，不要仅看列表里的显示名称。显示名称可以由订阅方自行命名，既不是协议判据，也不能证明传输安全选项已经匹配。按层检查比反复切换模式更容易定位问题。

二、VMess 与 VLESS：两种字段模型

VMess 的设计背景与实际配置

VMess 是 Project V 生态中较早广泛使用的代理协议。它在协议层处理用户身份和数据封装，因而形成了一套自身的连接格式。用户在图形客户端中通常会看到地址、端口、用户 ID，以及与服务端配置相关的安全或加密选项。历史教程里出现的字段名称不一定与当前界面完全一致：一些选项属于旧配置格式，一些选项则被转移到传输或 TLS 设置中。录入时以当前服务器参数与客户端字段含义为准，不应为了复现旧教程而给现有配置补上未经提供的值。

VMess 可以配合不同的传输方式；「VMess」并不等于「WebSocket」，也不必然意味着启用 TLS。连接失败时，应区分协议身份字段不匹配与传输握手失败。如果服务端给出 ws 路径，客户端却设成 tcp，就算用户 ID 正确也无法完成相同的连接。如果服务端要求 TLS，还要核对所填写的服务器名称及相关安全设置。更换协议类型通常意味着服务器侧也需要提供对应配置，不能仅在客户端把 VMess 下拉项改为 VLESS。

VLESS 为什么把安全选择留给其他层

VLESS 延续了以用户 ID 标识连接的使用方式，但把协议层做得更轻，通常不在代理协议本身重复承担数据加密职责。需要传输安全时，使用与服务端一致的 TLS 或 REALITY 等选项。这种分层使协议字段与传输安全字段更容易分别讨论，也让 VLESS 能与不同传输组合。相应地，配置者必须明确检查安全层；看到「VLESS」三个字，并不能推断连接已经启用某项安全设置，更不能省去服务器提供的公钥或服务器名称。

VLESS 常见身份字段为 UUID。某些配置还会出现 flow；它表示特定工作方式的约定，不是随手填写的性能开关。只有服务端明确给出相同 flow、客户端内核也支持对应组合时才应使用。留空与填写某个值可能指向不同的服务端配置。若链接导入后 flow 丢失，应先检查订阅输出格式和解析结果，而不是为所有条目统一补值。对手动录入来说，把原始参数逐项对照编辑卡，比按一张通用截图填写更可靠。

怎样在两者之间选择

如果已有稳定使用的 VMess 服务端，且订阅能完整表达其身份、传输与安全字段，没有必要仅为追求新名称而改协议。新建配置时，可以先看服务端实际提供哪种类型，以及所需传输安全是否被目标内核支持。VLESS 的协议层相对简洁，但一次连接的总体开销仍包括 TCP、可能的 TLS 握手、所选传输以及应用流量；不能把「协议层更轻」直接解释为所有网络场景中都更快。对用户而言，配置一致和稳定连接通常比细小的封装差异更重要。

迁移已有服务器时，建议保留原条目以供对照，再导入新条目分别核对字段。若两个条目使用同一地址和端口，也不能据此判断它们共享相同认证方式。测试时固定同一设备、同一网络与同一应用，再观察连接是否建立；不要同时改协议、传输和系统代理，否则无法知道是哪一步产生变化。关于客户端界面中的具体导入操作，可接续阅读入门指南。

三、Trojan 与 Shadowsocks：密码字段背后的差别

Trojan 的 TLS 依赖

Trojan 使用密码进行身份验证，典型部署依赖 TLS 连接。客户端常见字段包括地址、端口、密码和服务器名称；证书验证应与服务器配置及域名对应。它与 VMess、VLESS 的 UUID 字段不同，虽然图形界面都把这些内容放在「用户信息」附近，实际含义不能混用。收到 Trojan 分享链接时，要特别确认服务器名称是否随链接完整传递：地址可能是域名，也可能是数字地址，而 TLS 握手需要使用服务端预期的名称。不能单凭目标地址推断每一项握手参数。

Trojan 也可能与额外传输设置组合，具体支持情况依内核和服务端而定。讨论它的速度时，不能只把代理协议的封装字节拿来比较；建立 TLS 连接、网络往返时间与连接复用方式都会影响首次请求。连接建立后的持续传输又受网络质量、服务器负载和应用数据量影响。对已配置好的条目，更有价值的检查是确认密码、服务器名称和 TLS 设置一致，再看应用是否真的通过客户端的本地代理发送请求。

Shadowsocks 的方法字段

Shadowsocks 常简称 SS，以密码和加密方法作为关键参数。其生态出现较早，客户端界面一般要求填写服务器地址、端口、密码与 method。不同方法之间存在实际的协议兼容边界：服务器采用的方法必须与客户端相同，不能只匹配密码。某些方法还对客户端和服务端实现提出特定要求，所以「支持 Shadowsocks」不表示支持任何方法。导入订阅后若条目存在却无法连接，打开编辑窗口检查 method 是否被正确识别，是优先于修改路由规则的步骤。

Shadowsocks 与 Trojan 都可能在界面里显示「密码」，但密码字段不能作为协议识别依据。两者的连接组织与服务端实现不同；把 SS 参数粘贴进 Trojan 编辑卡不会得到等价配置。Shadowsocks 的可选插件或额外传输层也不能被默认视为协议本体。遇到同时提供 method、插件参数和服务器名称的资料，应先确认原始格式，再按照具体条目类型逐层填写，避免把插件选项误放进传输层安全字段。

选择时关注已有服务端

现成服务器使用 Trojan，就在客户端选择 Trojan 并保留相应 TLS 参数；现成服务器使用 Shadowsocks，就选择 Shadowsocks 并核对加密方法。若自己管理服务端，则先确认目标客户端及内核支持所选方法，再确定服务器配置与订阅输出格式。SS 的字段较少，手动填写通常直观；但字段少不意味着出错点只有密码，method、端口与插件参数仍需要严格匹配。Trojan 的配置项看似简单，TLS 服务器名称和证书验证却是不可忽略的部分。

比较两者时还要考虑维护成本。多人共用一份说明的情况下，清晰标注协议类型、方法或 TLS 名称，比只发送「地址＋密码」更有助于避免录入错误。订阅来源更新参数后，应重新查看编辑详情，确认关键字段确实发生了预期变化。若需要区分订阅分组并过滤不同用途的条目，可参考订阅分组与节点过滤，不要靠修改协议名称整理列表。

四、REALITY：与协议并列展示，却属于安全层

先读懂常见组合

REALITY 是 Xray 生态中的传输层安全机制，常见于 VLESS 配置。服务提供方可能把一个条目简称为「VLESS · REALITY」，它实际上给出了两个维度：代理协议为 VLESS，安全类型为 reality。传输还需要单独确认，常见示例是 tcp。客户端若只有「VLESS」条目但没有相应安全选项，或所选内核不认识 REALITY 参数，就不能仅靠填写地址与 UUID 完成连接。因此，看到新安全字段时，先查内核支持，再查客户端编辑窗口有没有正确呈现。

REALITY 配置通常涉及服务端指定的服务器名称、公钥和短标识等值；某些组合还会涉及 flow 与其他握手参数。这些值不是由客户端根据域名自动计算出来的。公钥是服务端配置对应的公开参数，不应拿另一条服务器的值代用；短标识需要遵循服务端给出的内容，空值也可能具有特定含义。图形界面有时将这些字段放在「传输层安全」的展开区域，导入后应实际打开核对，尤其留意空字段与未被解析的字段。

把安全层问题与代理层问题分开

如果 REALITY 握手参数不匹配，连接可能在代理协议身份验证之前就结束。此时反复修改 VLESS 的 UUID 通常没有帮助。可以按顺序检查：服务器地址和端口是否正确；传输是否与服务端相同；安全类型是否选择 reality；服务器名称、公钥和短标识是否逐项一致；最后再核对 UUID 与 flow。这样的顺序有利于区分连接目标错误、握手错误和用户字段错误，但具体报错仍应以当前内核日志为准。

内核日志比列表状态更接近故障发生的位置，不过一条报错可能由前面多个字段引起。比如「握手失败」不能直接等同于公钥错误，网络连接中断或服务端设置变化也可能产生相近现象。记录排查时改动了哪一个字段，并在每次改动后重新连接。若同时从订阅导入多个条目，可挑一个原始参数完整的条目作对照，避免把订阅格式转换造成的字段缺失误认为服务器不可用。

适用边界与兼容检查

REALITY 不应被当作所有协议的通用勾选框。只有服务端明确使用相应机制，且客户端内核支持该组合时才选择它。已有 TLS 配置不会因为把安全类型改成 reality 就自动迁移；两者需要的参数不同。对于同一订阅中混合的普通 TLS 条目与 REALITY 条目，应逐条保留原始安全类型，不能批量覆盖。v2rayN 可通过所选内核执行相应配置；Android 上也需要核对 v2rayNG 或 v2flyNG 所用内核及其实际支持范围。

手动录入前，可以把原始链接中的协议、传输、安全字段抄成一张小清单，录入后逐项核对。客户端显示「已保存」只说明表单接受了输入，并不证明服务端能处理该组合。若内核启动阶段就报配置错误，先查内核及字段支持；若内核启动正常但连接失败，再检查服务端参数和网络路径。有关启动阶段的分支，可继续阅读Xray 内核启动失败排查。

五、V2Fly、Xray 与图形客户端的分工

同一生态中的不同内核家族

Project V 形成了协议、配置格式与客户端工具共同发展的生态。V2Fly 延续 V2Ray 项目的内核路线；Xray 则是独立发展的内核家族，在部分协议扩展、传输与安全能力上形成自己的实现。两者有共同的历史基础和相似的配置概念，但不能将其视为名称不同、功能完全相同的程序。「支持 VLESS」也不意味着支持 VLESS 的所有 flow、安全类型或扩展字段。判断兼容性必须落到具体字段组合，尤其是较新的安全机制与传输选项。

图形客户端负责把服务器条目、订阅与路由设置组织成内核可用的配置。v2rayN 面向 Windows、macOS、Linux，提供桌面上的服务器编辑、订阅管理、路由和系统代理入口；v2rayNG 是使用 Xray 内核的 Android 客户端；v2flyNG 则是使用 V2Fly 内核的 Android 备选。选择 Android 客户端时，若服务器配置依赖 Xray 特有的能力，应先检查 v2rayNG 的对应支持；若现有配置依赖 V2Fly 生态，可核对 v2flyNG 的适配情况。客户端名称不是协议名称，不能代替服务器参数。

配置兼容性分三个层面

第一层是概念兼容：两个内核可能都认识「出站」「路由规则」「用户 ID」等概念。第二层是语法兼容：相同概念在配置文件中可能有不同字段、取值或默认行为。第三层是功能兼容：内核能解析某个协议，不代表它实现了所有相关扩展。图形客户端还会在这些层面之上增加导入解析和配置转换。故而一份原生内核 JSON、一条分享链接与一份订阅文本，不应被理解为完全等价的三种包装。

当某条服务器在一台设备上可用、另一台不可用时，应先对照两端的编辑详情，而不只对照显示名称。重点看协议、传输、安全类型、flow、服务器名称和身份字段是否一致，再看 Android 客户端所用内核是否支持这些值。有的字段在导入时被忽略，界面仍会生成可见条目；有的字段在内核启动时才触发错误。区分「导入成功」「内核启动成功」「应用请求成功」三个阶段，可以明显缩小排查范围。

路由示例属于内核配置，不是订阅链接

以下片段展示一条按域名交给名为 direct 的出站处理的路由规则。它是 JSON 对象片段，只有放入具备同名出站的完整内核配置中才有意义；不能把它粘到客户端的订阅地址输入框。示例域名仅用于说明字段位置。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy 影响路由判断时如何处理域名；type 指明规则类型；outboundTag 必须能在完整配置中找到对应出站。路由决定请求交给哪个出站，并不改变该出站使用的服务器协议。若希望按域名和解析结果共同设计规则，应单独核对 DNS 与路由的关系，参见V2Ray DNS 分流解析配置。改路由之前先让基础连接正常，避免把解析问题与协议问题叠在一起。

六、连接速度、资源占用与移动端电量

首次连接与持续传输是两件事

「速度」至少包含连接建立时间、首次请求响应时间和持续传输吞吐量。协议层的封装与认证可能影响处理开销，但首次连接还受 DNS 解析、TCP 建连、TLS 或其他安全握手、传输握手及网络往返时间影响。WebSocket、gRPC 等传输增加各自的处理步骤，是否值得使用取决于已有服务端架构与应用需求。已建立连接上的大文件传输，又可能主要受线路带宽、拥塞、服务器负载和设备性能限制。仅凭 VMess、VLESS 或 Trojan 的名称排列绝对速度名次没有依据。

比较配置时要保持条件相同：同一网络、相近时段、同一服务端资源、相同的安全层与传输方式，并区分冷启动与已建立连接。若把一条 VLESS＋tcp 配置与另一台服务器上的 Trojan＋TLS 比较，观察到的差异同时包含服务器与网络差异，不能归因于协议。客户端界面的连接状态仅说明相应阶段是否完成；应用真实请求的结果才可用于判断该应用是否走了预期路径。排查桌面端时还要确认系统代理是否开启，以及应用是否使用系统代理。

CPU 与内存消耗来自整条处理链

内核处理连接时需要执行加解密、协议封装、路由匹配、DNS 处理与日志记录。大量短连接可能让握手和 DNS 开销更突出；持续大流量则可能让加密和数据复制占比提高。较复杂的路由规则、更详细的日志级别、同时存在的连接数量，也会改变资源占用。VLESS 的协议层相对简洁，不等于整个配置始终使用更少 CPU；如果同时改变安全类型和传输，整体计算路径已经不同。观察资源占用时，应记录正在运行的应用及流量类型，而不是只看客户端是否驻留。

Android 电量表现如何判断

在 Android 上，v2rayNG 与 v2flyNG 运行时，系统网络接口、后台保活、无线网络状态及频繁唤醒都可能影响电量。协议本身只是因素之一。持续播放或同步会让网络与处理器保持工作；应用反复建立短连接则可能增加唤醒与握手频率；移动网络信号不稳也会使无线模块消耗上升。因此不能声称某个协议必然最省电。比较时应让设备处于相同网络环境，使用相似应用负载，并查看系统电池统计中的实际活动时间。

若待机耗电异常，先区分客户端持续处理流量与系统反复重连。检查订阅是否设置过于频繁的自动更新，查看是否有后台应用持续发起请求，再观察网络切换时连接是否重复建立。需要减少开销时，可优先简化不必要的持续任务、核对系统的后台运行设置，并保持服务端配置与客户端内核一致；盲目更换协议而不改变这些条件，往往无法隔离原因。避免用一次短时间测试推断全天电量表现。

七、订阅与分享链接：能导入不等于字段完整

三种常见输入需要分别识别

客户端可能接收单条分享链接、由多条链接组成的订阅文本，或服务提供方定义的结构化订阅内容。单条链接通常以协议标识开头，并编码服务器字段；订阅地址则是获取内容的位置，不直接等于其中某台服务器。还有一些输出格式是供特定客户端读取的配置文件，不能因为网址可访问就认定 v2rayN、v2rayNG、v2flyNG 都能按相同方式解析。导入前先确认提供方标注的格式，再选择客户端里对应的导入入口。

兼容性至少包含两层：客户端是否认识订阅文本，以及解析器是否完整保留每条服务器所需的字段。列表出现条目只说明解析器提取到部分可展示信息。对 VLESS＋REALITY，应核对 UUID、传输、安全类型、公钥、短标识、服务器名称和可能的 flow；对 Shadowsocks，应核对 method、密码与插件参数；对 Trojan，应核对密码及 TLS 名称。批量导入后抽查不同协议的代表条目，比只测试列表第一项更能发现格式转换中的缺漏。

更新、分组和手动修改的关系

订阅分组用于组织来源，并可设置更新策略与过滤规则。更新通常会重新读取远端内容，条目的显示名称与参数都可能随来源变化。如果在订阅条目里手动修正了字段，下一次更新能否保留修改取决于客户端处理方式；因此更稳妥的做法是先纠正订阅来源，或将需要长期独立维护的条目与订阅生成条目分开管理。过滤关键词只影响列表整理，不应被当成修正协议参数的方法。

收到一个订阅地址却导入空列表时，先确认地址返回的是目标客户端能读取的内容，而不只是浏览器能打开的说明页。再检查分组过滤条件是否把条目全部排除、是否误把单条分享链接当作订阅地址，以及订阅内容是否只包含另一种格式。不要通过猜测服务器地址补造条目；原始格式若未携带关键字段，客户端无法从显示名称恢复它们。多个来源混用时，为分组设置明确别名，便于追踪条目来自哪里。

跨客户端迁移先核对共同字段

把桌面 v2rayN 中的服务器迁往 Android 时，优先使用目标客户端明确支持的分享链接或订阅格式，并核对导入后的编辑详情。桌面客户端能显示的路由分组、系统代理设置与 Android 的分应用代理设置属于客户端本地行为，不能指望随服务器分享链接一起迁移。服务器参数可以相同，设备侧代理范围仍需分别设置。使用 v2flyNG 时，还应核对条目是否要求 Xray 专有能力；如果要求的功能不受当前内核支持，改变订阅文本的编码也不能补上内核功能。

一次可靠的迁移可以分两步：先让目标设备导入并连接一个字段完整的代表条目，再迁移整个分组。若首个条目失败，保留原始链接与导入后的字段对照，确认问题发生在文本解析、内核启动还是应用请求阶段。分组数量较多时，参考订阅分组与节点过滤说明建立用途清晰的分组，再决定更新频率；这比反复删除并重新导入全部条目更容易保留排查线索。

八、按使用场景选择，并逐层验证

先看来源，再看设备

已有服务器或订阅时，首要原则是遵循来源给出的协议及完整参数，而不是先选一个偏好的协议名称再改造条目。桌面设备使用 v2rayN，按 Windows、macOS、Linux 的实际系统选择安装入口；Android 上优先核对 v2rayNG 与所需 Xray 功能，若现有配置面向 V2Fly 内核，再查看 v2flyNG 是否适合。可用的安装入口集中在客户端下载页。选好客户端之后，再确认其实际内核能够执行服务器要求的协议、传输和安全组合。

如果自己管理服务器并需要决定新配置类型，可从团队已经维护的服务端能力、现有订阅输出格式和设备覆盖范围出发。需要 REALITY 时，先确认所选内核与客户端的字段支持，再规划相应 VLESS 配置；已有成熟 VMess 或 Trojan 配置时，保持明确的字段文档比仅为统一名称而迁移更稳妥；选择 Shadowsocks 时，提前确认目标端共同支持的 method。任何方案都应先用一个代表条目完成连接，再批量生成订阅。协议没有脱离服务端和设备的单独「最佳」选项。

用三个阶段定位失败

第一阶段是导入：条目是否出现，编辑详情是否包含原始配置中的关键字段。第二阶段是内核启动：客户端日志是否报告未知字段、无效参数或本地端口占用。第三阶段是应用请求：内核启动后，目标应用是否使用了正确的本地代理或系统代理设置，路由规则是否把请求交给预期出站。第一阶段出错，查订阅格式；第二阶段出错，查内核与字段组合；第三阶段出错，再查系统设置、DNS、路由和应用行为。不要把所有失败都归入「协议不可用」。

桌面浏览器和终端命令行可能采用不同的代理设置。v2rayN 托盘菜单中的「自动配置系统代理」主要影响遵循系统代理的应用；终端工具还可能需要自己的环境变量或应用级设置。如果浏览器能使用而终端不能，先检查两者各自的代理来源，不必立即更换服务器协议。相关操作顺序见macOS 系统代理不生效排查；常见设置疑问可到常见问题按类别查找。

为可复查的配置留下记录

记录每个代表条目的协议、传输、安全类型、内核家族及配置来源，不记录可用于登录的敏感字段。更新订阅、切换内核或修改服务器设置后，先重新核对这些维度，再观察连接行为。发生问题时保留相关日志的错误类型与改动顺序，并注意在分享日志前移除地址、身份与密码等信息。这样的记录能回答「哪一层变了」，比只写「之前能用，现在不能用」更便于定位。

路由模式也应放在基础连接验证之后处理。先确认客户端能够用正确的服务器配置建立连接，再按需要设置绕过局域网、分流规则或 DNS 解析。若要让其他设备通过电脑共享本地代理端口，还需处理监听地址和系统防火墙，不能仅凭服务器协议类型决定是否可共享；操作细节见允许局域网连接设置。每次只更改一个层次，并使用同一个应用复测，结果才具有可解释性。

这套顺序同样适用于从手动条目迁移到订阅管理：先验证单条连接，再验证批量导入，最后配置路由和设备侧代理范围。初次操作可回到入门指南沿界面步骤完成；已经能够连接、只需辨认字段时，则按本页相应章节查阅。把协议选型、内核兼容和应用代理拆开处理，能避免一次调整多个设置后失去判断依据。