代理协议与内核参考

客户端、内核与服务端的边界

图形客户端负责展示服务器列表、读取分享链接、管理订阅和保存设置。内核负责建立入站监听、执行路由规则、连接远端并转发流量。远端服务则按约定的协议接受连接。v2rayN 里能看到某个编辑选项，不等于当前选中的内核一定支持它；客户端能够导入一条链接，也不等于服务端会接受其中的所有参数。排查兼容性时，需要同时核对客户端如何解释字段、内核实际生成什么配置，以及服务端允许什么组合，不能只看界面上的协议名称。

本地应用通常先连接系统代理或虚拟网络接口，再由内核送往远端。浏览器访问失败可能发生在本地入口、名称解析、路由选择、远端连接或目标站点任一阶段。协议只是其中的一段。把所有失败都归因于 VMess 或 VLESS，会遗漏端口被占用、系统代理没有生效、分流误命中等更直接的原因。首次测试应固定一个应用和一个目标，确认请求进入客户端，再观察错误发生在哪一层；不要同时切换节点、修改 DNS 和调整路由。

代理协议、传输方式与安全层

VMess、VLESS、Trojan 和 Shadowsocks 描述代理双方如何识别用户、表达目标地址与封装数据。TCP、WebSocket、gRPC 等属于承载或传输安排；TLS 和 REALITY 则涉及外层安全机制。VLESS 与 REALITY 不能作为两个同级协议直接比较，因为它们可以出现在同一条连接上。类似地，看到 WebSocket 不应直接推断正在使用 VMess，看到 TLS 也不能推断一定使用 Trojan。选型应比较完整组合，而不是把来自不同层次的名称放进同一张速度排行榜。

地址、服务器名称与应用目标

连接地址决定客户端首先向哪里建立网络连接，服务器名称通常参与安全握手与身份验证，应用目标则是浏览器原本想访问的站点。三者有时使用相同域名，但职责不同。修改连接地址不应顺手覆盖服务器名称；调整 WebSocket 的 Host 也不等于改变应用目标。服务端使用反向代理时，路径、Host 和服务器名称可能共同参与转发。漏掉其中一个值，往往表现为入口可达但请求无法进入正确服务，而不是单纯的账户错误。

实际查阅时，先把现有配置按层记录下来：协议是什么、底层传输是什么、是否启用外层安全、认证字段从何而来。对不熟悉的开关保留原值，并保存一份原始导入记录。分享链接里的短字段名与界面中文名称不一定逐字对应，不能凭名称相近就互换。最可靠的依据是服务端提供的完整参数及内核文档中的对应含义。下面各章沿用这套分层方法，分别讨论设计取舍和客户端中的核对顺序。

VMess：认证与数据保护相结合

VMess 来自 Project V 的协议体系，将用户认证、请求信息和数据保护纳入协议设计。常见配置以 UUID 标识用户，并包含相应的加密选择。较新的实现使用 AEAD 认证方式，旧教程中的额外标识与旧式认证参数不能直接当成通用推荐值。导入后应让客户端按当前格式生成配置，而不是为了套用历史截图去改回旧字段。设备时间也需要保持准确；当认证过程涉及时间条件时，明显的时钟偏差可能导致网络可达却认证失败。

VMess 的适用性主要取决于现有服务和客户端支持情况。已有稳定的 VMess 服务时，没有必要仅因另一个名称较新就更换协议。需要核对的是传输方式、用户标识、加密设置和外层安全是否一致。VMess 可以与不同传输组合，实际连接开销也随组合变化。一个采用多层封装的 VMess 连接，不能与另一条链路上的直连传输做简单对照，再把差异全部归于协议本身。比较时至少要固定服务器、目标、网络与测试方式。

Trojan：依赖 TLS 的代理认证

Trojan 的设计将代理请求置于 TLS 连接之中，再用协议自身的认证信息识别用户。它不以 UUID 作为统一的账户表达方式，客户端通常要求密码。使用时仍需区分远端地址与服务器名称，并检查证书是否与名称匹配。TLS 连接能够建立，不代表代理认证已经成功；相反，密码正确也不能修复证书名称错误。这两个阶段的日志应分别理解。不要把关闭证书验证当成常规安装步骤，这会削弱客户端确认远端身份的能力。

Trojan 常被认为配置字段相对集中，但实际维护复杂度仍取决于证书、域名和服务部署。连接复用、传输扩展或外部转发安排会引入额外条件。客户端支持 Trojan，并不意味着支持所有带有类似名称的扩展组合。迁移配置时，应先确认服务端使用的是哪种具体实现与传输，再检查客户端是否原样保留密码和服务器名称。密码可能含需要进行 URL 编码的字符，手动拼接分享链接时尤其容易在这一处出错。

Shadowsocks：方法与密钥必须成对匹配

Shadowsocks 通常以较紧凑的配置表达代理连接，关键内容包括服务器地址、端口、加密方法和密码。简称 SS 只表示协议家族，不能代替具体方法名称。经典 AEAD 方法与更新的 Shadowsocks 2022 方法在密钥要求和实现支持上存在差异，后者不能简单沿用任意长度的普通密码。一个客户端能识别 SS 链接，不代表其内核支持链接声明的所有方法。遇到导入成功但连接报错，应先核对方法名称和密钥格式，而不是反复更换服务器地址。

这三类协议各自解决认证与转发问题，不能只按字段数量判断安全性或资源占用。配置短不一定更省电，层次多也不一定更慢。对于已有服务，优先选择参数完整、客户端支持明确的组合；对于需要维护多台设备的场景，优先考虑所有设备能否使用同一种表达方式。有关四种代理协议的进一步横向比较，可阅读VMess、VLESS、Trojan、Shadowsocks 选型说明，并结合下一章理解 VLESS 的安全边界。

VLESS 不等于完整的加密连接

VLESS 的设计取向是精简代理协议本身，把部分职责交给外层机制。用户标识通常仍使用 UUID，但其工作方式不能照搬 VMess 的加密选项。常见 VLESS 配置里的 encryption: none 表示协议这一层不额外选择数据加密方法，并不自动意味着整个连接没有保护。完整连接是否受到保护，要继续查看传输配置中的 TLS 或 REALITY。反过来，如果配置确实没有外层安全机制，就不能因为协议名称是 VLESS 而推断存在加密。

因此，讨论 VLESS 时应写清完整组合，例如 VLESS 配合 TLS，或 VLESS 配合 REALITY，并说明承载方式。不同组合的服务器要求、握手字段和内核支持范围不同。选项中的 flow 也不是通用的提速按钮；它表示特定流控方式，必须与服务端和传输条件对应。任意填入 xtls-rprx-vision 并不会让不支持该组合的服务获得相应能力。若原始链接没有这个字段，不应仅依据教程截图自行补上。

REALITY 的客户端验证材料

REALITY 属于安全传输机制，不是替代 VLESS 的另一种用户账户协议。在常见 Xray 客户端配置中，需要核对服务器名称、公钥类验证材料、短标识与指纹设置等内容。界面名称会随客户端和内核配置模型变化，分享链接中也可能使用缩写。核对时应以导入后的实际含义为准，而非只看字段标签。客户端用于验证远端的材料与服务端保存的私有材料职责不同，服务端私有材料不应复制到普通客户端设置中。

短标识通常有十六进制格式和长度约束，空值是否允许由服务端决定。服务器名称必须属于服务端允许的范围，不能替换成任意熟悉的域名。指纹设置影响握手表现，也受内核实现支持限制；它不是更换设备身份的通用工具。原始配置能够连接而手动重建失败时，应逐项比较这些字段，再检查是否在复制过程中引入空格、全角字符或遗漏查询参数。先恢复原值，比同时尝试多个所谓优化组合更容易定位原因。

兼容性失败的识别顺序

若保存配置后内核直接退出，优先考虑字段不受支持、参数结构错误或组合不合法。若内核正常启动但远端握手失败，再检查地址、端口、服务器名称和验证材料。若握手成功而应用仍无法访问，则转向路由、DNS 和目标连接。这样的顺序能把本地配置解析与网络握手分开。客户端日志中出现某个安全层名称，只能说明正在处理相应阶段，不能单凭这一行确认用户认证和应用数据转发都已经完成。

对于新建的桌面配置，v2rayN 配合支持对应能力的内核是主要查阅路径；Android 使用 v2rayNG 时同样需要检查实际内核能力。不要把面向 Xray 的 VLESS 与 REALITY 配置直接交给另一内核家族并期待完全兼容。已有可用配置时，应先确认导入工具没有丢失字段，再考虑更换客户端。有关内核支持的边界见第五章，关于分享链接保留字段的方法见第六章，两者共同决定这类组合能否在设备间正确迁移。

连接建立、响应时间与吞吐量

连接性能至少包含三个不同问题：新连接需要多久建立、请求发出后多久收到响应、持续传输时能维持多大吞吐量。它们受不同因素影响。名称解析、TCP 建连、安全握手和代理认证会影响首次响应；往返时间、丢包、拥塞控制和服务端负载会影响持续传输。某个协议减少了应用层字段，不代表它在更差的链路上仍更快。只看一个测速结果，无法把协议实现、服务器位置和网络状态的影响拆开。

Tcping 一类测试通常只能反映某个 TCP 入口的连接情况，不会完整执行代理认证和目标访问。真连接测试则更接近应用经过代理访问测试地址的过程，但仍受到测试目标与客户端实现影响。两项结果不是同一指标。入口可连接而真连接失败，可能是认证、安全握手、目标访问或 DNS 问题；不能立即认定线路中断。具体操作可对照首次连接与真连接测试指南，使用固定测试目标重复观察。

封装、复用与资源占用

WebSocket、gRPC 等传输会带来各自的握手与封装安排，同时也能适配已有的服务部署方式。额外封装通常需要处理更多结构，但真实开销是否显著，取决于请求大小、连接存活时间和实现效率。对于短请求，连接建立过程可能比持续数据处理更重要；对于长时间下载，链路吞吐和丢包往往更关键。不能据此写出对所有网络都有效的固定排序，也不应把更少的配置字段等同于更低的处理成本。

连接复用能减少反复建立连接的成本，但不一定改善每一种任务。多个请求共享底层连接时，会共同受到该连接的状态影响；当链路不稳定或某个流占用较多资源时，其他请求也可能受到牵连。是否启用应考虑内核支持、服务端能力和任务类型，先记录默认表现再比较。CPU 占用还与加密方法、硬件指令、流量规模和日志级别有关。单独看到一个进程短时占用上升，不能直接推出协议不适合该设备。

Android 电量的实际影响因素

移动设备耗电不仅来自加密计算，还来自无线网络接口的活跃时间、后台唤醒、连接重试和应用流量。弱信号下反复重连可能比正常数据处理更消耗电量。若启用了全设备接管，原本不经过代理的应用也可能进入处理链路，流量覆盖范围扩大后，不能再把电量差异全部归因于协议。系统的后台限制还可能中断客户端，引发恢复连接与再次认证，表现为待机耗电增加、通知延迟或解锁后短时集中重连。

有意义的比较应固定设备、网络类型、应用集合与使用时长，并区分前台传输和后台待机。先关闭重复测速和高频日志，确认没有持续重试，再比较不同配置。记录系统电池统计时，同时查看屏幕、移动网络和目标应用的活动情况。若只更换协议却连同服务器、传输方式和代理覆盖范围一起变化，结果只能代表两套完整方案的差异，不能作为协议本身的功耗结论。v2rayNG 与 v2flyNG 的比较也应遵循这一原则。

实践中，优先修复错误配置、无效重试与不必要的全量接管，再考虑微调传输方案。对于日常网页和消息应用，一条参数正确、连接稳定的现有配置往往比频繁切换更容易评估。对于大文件任务，则应单独观察持续吞吐与失败恢复。没有可复现的测试条件时，保留现有可用方案比根据单次截图更换协议更合理；需要排除具体错误时，可结合常见问题按故障阶段逐项核对。

Project V 生态中的分工

Project V 是理解这一生态的起点，V2Ray 的配置模型和协议设计为后续工具提供了基础。V2Fly 持续维护 V2Ray 相关实现，Xray 则从相关代码与技术基础发展出独立演进的内核项目。两者保留了不少相似概念，包括入站、出站、路由和 DNS，但功能集合与字段模型会分别变化。不能把 Xray 简化成 V2Fly 的版本号升级，也不能把它们视为可以任意互换的同一个程序。真正的兼容范围需要按功能逐项判断。

客户端处于另一个层次。v2rayN 为桌面用户提供图形管理入口，具体协议处理由实际使用的内核完成；v2rayNG 的常见使用路径围绕 Xray 能力展开；v2flyNG 则是 Android 上围绕 V2Fly 内核的备选。选择哪款客户端，首先受平台和所需能力约束，不是单纯的界面偏好。桌面端优先从 v2rayN 开始，Android 需要 Xray 特有能力时先核对 v2rayNG，对既有 V2Fly 配置则检查 v2flyNG 的适配情况。

共享配置骨架与独立功能

inbounds 描述本地如何接收流量，outbounds 描述如何向外建立连接，routing 决定请求交给哪个出站。这些概念相近，不代表其下所有字段都一致。传输设置、安全机制、流控选项和 DNS 行为尤其需要核对。REALITY 与相关 Xray 连接能力不能仅因外层 JSON 看起来熟悉就直接迁入 V2Fly。某些字段在另一内核里可能无法解析，也可能存在名称相似但行为不同的设置。

路由数据资源也不是抽象地“装上就相同”。域名分类标签和 IP 分类标签依赖实际加载的资源内容，文件缺失或标签不可用时，规则可能导致启动失败或无法达到预期。迁移时既要看 JSON，也要看运行环境中的资源和路径。相对路径往往取决于客户端启动内核时的工作目录，不能把另一台机器上的绝对路径直接保留。对于图形客户端管理的资源，应优先使用其提供的更新与设置入口，避免覆盖后不清楚实际加载的是哪一份。

判断需要更新哪一层

界面无法识别链接字段，通常需要检查客户端的导入能力；配置生成正常但内核报告不支持选项，需要检查内核能力；内核运行正常而规则标签找不到，需要检查资源文件。这是三种不同问题。只更新图形界面不一定改变内核，替换内核也不一定修复客户端丢字段的问题。更新前保留原始订阅与可用设置，更新后先用一条已知配置验证，再恢复复杂规则。避免在同一次操作中同时更换内核家族、改写订阅和导入整套新规则。

开源属性说明代码能够被查阅并按相应许可使用，不意味着两个项目会保持永远一致的配置格式。选择依据应是所需功能、客户端支持和维护路径，而不是把某个家族视作所有场景的唯一答案。需要读懂配置各段时，可继续阅读Xray 配置文件结构拆解；需要更换设备安装包时，回到下载页按操作系统和处理器选择，不要把内核概念与安装包架构混为一谈。

单条分享链接与链接集合

分享链接用于描述一个服务器配置，常见前缀包括 vmess://、vless://、trojan:// 和 ss://。它们不共享完全相同的内部格式。常见 VMess 分享表达会对 JSON 内容编码，而 VLESS、Trojan 通常用 URL 的用户信息、地址和查询参数表达设置。Shadowsocks 也存在不同历史表达方式。客户端导入时需要先识别协议前缀，再按对应规则解析，不能把一种链接的解码方式直接套到另一种。

订阅地址则是获取一组配置的入口，不是某个服务器地址本身。常见订阅返回多行分享链接，或者返回这些链接集合的 base64 编码。base64 是编码方式，不是加密，也不是代理协议；成功解码只说明得到了文本，还要看文本是否属于客户端支持的格式。换行、字符编码和 URL 编码都可能影响解析。复制订阅时应使用提供方给出的完整地址，避免混入页面标题、说明文字、不可见空格或邮件工具添加的换行。

原生 JSON 与客户端管理配置

Xray 原生 JSON 可以描述整套运行行为，包括多个入站、多个出站、路由和 DNS。它不是一组分享链接的另一种外观。单条分享链接通常只覆盖远端连接所需的主要字段，并不承载完整的本地监听和复杂分流逻辑。因此，原生配置转成链接时可能丢失全局行为；链接导入后生成的配置，则会叠加客户端自身的默认入站与路由。两种结果可能都能连接，但实际处理的流量范围、DNS 路径和规则优先级并不相同。

客户端自己的设置文件还可能包含分组、显示名称、窗口状态和测速偏好，这些不属于内核通用格式。迁移时应先确定要保留的是远端参数，还是整套客户端工作环境。只想把一个服务器移到另一设备，使用该客户端能识别的分享形式通常更直接；需要保留复杂规则时，要另外记录路由与 DNS，不能期待分享链接自动携带。导入完整自定义配置时，也应确认客户端是否仍会接管系统代理与端口设置，避免误以为所有界面开关都能覆盖自定义内容。

格式转换与更新的边界

转换只能重排已有信息，不能补出缺失的服务器名称、公钥类材料、短标识或传输路径。一个转换器把结果输出成合法 JSON，不代表字段语义正确，更不代表目标内核支持该组合。对于较新的传输字段，旧解析器可能直接忽略未知查询参数，导入后界面仍显示一个正常的服务器条目。遇到这种情况，应对照原始参数检查导入后的详情，而不是以“列表里出现了名称”作为兼容性完成的依据。

订阅更新通常会重新生成由订阅管理的条目，手动改动可能在下次更新时被覆盖。需要做实验时，可将测试配置复制为独立条目，保留原订阅分组不动；客户端具体提供的复制与分组方式以界面为准。更新后出现重复名称，也不一定代表同一个端点，可能是地址、传输或用户参数不同。清理时先比较关键字段，再删除条目。若分组突然为空，先核对返回内容和格式，不要连续执行删除、重建和清空全部配置。

完整排查顺序是：确认订阅入口可访问，确认返回文本属于预期类型，确认客户端识别协议，确认关键字段被保留，最后测试内核连接。格式问题与远端认证问题应分开记录。想了解不同格式的结构与互转限制，可阅读base64 订阅、原生 JSON 与分享链接的区别。本页不提供在线转换表单；敏感配置应在可信的本地工具与客户端中处理，避免为了格式转换扩大信息暴露范围。

系统代理与 TUN 的覆盖范围

系统代理向应用提供代理入口，只有读取相关设置的应用才会按预期使用它。某些程序有自己的网络栈或独立代理设置，因此浏览器能够访问，不代表所有程序都已经经过同一路径。TUN 模式通过虚拟网络接口接收流量，覆盖方式更广，但同时引入路由、权限和 DNS 等条件。它不是更换代理协议，也不会自动修正远端参数。协议认证失败时，启用 TUN 只会改变流量进入客户端的方式，不能让服务端接受错误账户。

v2rayN 中的“自动配置系统代理”和“启用 Tun 模式”应按任务选择，而不是默认同时开启所有接管方式。先用系统代理验证一个遵循系统设置的应用，再按需要测试 TUN，能减少变量。Windows、macOS 和 Linux 在权限、虚拟接口及系统网络设置上存在差异，具体提示以客户端和系统为准。Android 客户端则通过系统提供的虚拟网络接管能力工作，需要确认相关授权和后台运行状态，并避免多个同类接管程序争用同一入口。

规则顺序、出站标签与域名解析

路由规则通常按顺序匹配，先命中的规则决定出站。精确规则应放在宽泛规则前，出站标签必须与实际定义对应。domainStrategy 控制路由匹配过程中如何处理域名与 IP 的关系，不等同于浏览器全部 DNS 行为。IPIfNonMatch 表示域名规则没有匹配时，可能继续通过解析所得 IP 尝试匹配。它不会自动创建任何地理分流规则，也不会保证所有域名都按期望归类；具体效果取决于已有规则和解析结果。

下面是可放入 Xray 原生配置中 routing 字段的 JSON 对象片段，不是完整运行配置。它把本地回环地址送到名为 direct 的出站，其余 TCP 与 UDP 流量送到名为 proxy 的出站。使用前必须已定义这两个出站，且代理出站需要支持实际请求的网络类型。示例只演示顺序与标签，不代替完整的局域网例外、DNS 策略或虚拟接口防回环安排，也不应覆盖客户端自动生成的整套路由。

{
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "ip": ["127.0.0.0/8", "::1/128"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "network": "tcp,udp",
      "outboundTag": "proxy"
    }
  ]
}

DNS、UDP 与失败定位

域名解析可能由应用、操作系统或内核执行，路径不同会影响路由能看到什么信息。应用已经自行解析成 IP 时，内核不一定仍能直接使用原始域名规则；流量嗅探也有能力和适用范围限制，不能被视作必然恢复域名的机制。配置 DNS 时应先明确谁发起查询、查询经过哪个出站、结果由谁使用。若解析依赖代理，而连接代理本身又必须先解析其地址，就可能形成循环依赖，需要为远端入口保留明确可用的解析路径。

UDP 还要求本地入口、内核、协议实现和远端服务共同支持。网页正常而某个实时应用失败，可能是 UDP 转发条件不满足，也可能是路由没有覆盖；不能仅凭协议名判断一定可用。测试时先观察失败应用是否进入客户端，再确认使用的网络类型与实际命中出站。远端连接稳定却只有部分域名失败时，优先检查规则和 DNS；所有应用都无法进入内核时，先处理本地入口。更多规则语法可查阅自定义路由规则与匹配优先级。

桌面与 Android 的选择路径

桌面端优先选择 v2rayN，再按 Windows、macOS 或 Linux 选择对应安装入口。Windows 的 Desktop 与经典 WPF 界面属于客户端形态差异，不是两种代理协议；macOS 需要区分 Apple Silicon 与 Intel，Linux 需要匹配处理器和软件包格式。这些选择决定程序能否正确安装运行，不决定远端协议是否可用。安装后仍要检查内核和导入参数。具体包入口以下载页为准，不应从协议教程中的示意名称推断安装文件。

Android 首先看配置依赖哪一类内核能力。需要 Xray 对应功能时，以 v2rayNG 作为主要选择；已有明确面向 V2Fly 的配置与维护流程时，可评估 v2flyNG。两款客户端不应仅凭名称相似就互相导入全部应用设置，尤其是自定义 JSON 与路由资源。处理器架构则与协议无关，现代设备常见 arm64，但仍应以系统实际架构和安装结果为依据。选择通用包也不能修复一个内核不支持的协议组合，架构与功能属于两条独立检查线。

已有稳定服务与新方案评估

已有稳定服务时，先保留当前协议，确认它满足需要的应用与网络类型。迁移的理由应是明确功能需求、设备兼容问题或维护困难，而不是只因为协议名称不同。若服务端只提供 VMess，客户端改选 VLESS 不会建立兼容连接；若服务端提供多种组合，才有条件在相同目标与网络下比较。应先确认每个组合都能正常认证，再比较首次响应、持续传输和后台稳定性。失败配置参与测速，只会把配置错误混入性能结论。

新方案评估应形成一张简短记录：客户端、实际内核、代理协议、传输方式、安全机制、流控字段、DNS 与接管模式。每次只改一个层次，并保留一个已知可用条目。需要长时间后台运行时，重点检查断网恢复与系统后台限制；需要处理大量短请求时，关注连接建立与复用；需要持续传输时，关注吞吐、资源占用和中断恢复。不同任务可能得出不同选择，没有必要用一个单项指标替所有场景作结论。

从报错阶段回到正确章节

导入时就提示格式无效，回到第六章检查链接与订阅表达；保存后内核无法启动，回到第五章检查支持范围和字段结构；入口可达但握手失败，回到第二、三章核对认证与安全设置；只有部分应用失败，回到第七章检查接管、路由和 DNS；连接可用但电量异常，回到第四章排除持续重试和高频测试。这套顺序比不断切换协议更可复现，也便于在保留敏感信息的前提下准确描述故障。

最终选择可以归纳为四个条件：服务端确实提供、客户端能够完整表达、内核明确支持、使用任务经过验证。满足这些条件后，再考虑管理习惯与资源表现。首次操作继续按快速上手完成导入、连接与验证；需要三款客户端的横向说明时，阅读选型指南；遇到具体症状时查阅常见问题。本手册用于解释这些选择背后的技术边界，不提供脱离服务端条件的统一协议排名。