Xray-core 与 V2Fly-core 内核差异:XTLS、REALITY 支持及配置兼容性

梳理两大内核的分支由来,对比 XTLS Vision 与 REALITY 等 Xray 独有特性,并说明同一份配置在两种内核之间切换时需要留意的字段。

本文速览

内核选择首先取决于节点需要哪些协议、传输和安全层,而不是客户端界面的名称。本文适合准备在 v2rayN 中调整内核,或比较 v2rayNG 与 v2flyNG 的用户:先区分 VLESS、Vision 和 REALITY,再核对字段、资源文件与本地端口,最后通过配置检查和连接日志验证切换结果。

分支由来:客户端、内核与节点配置的关系

V2Fly 是围绕 V2Ray 持续开发的社区项目,其核心程序通常称为 V2Fly-core。Xray-core 在 2020 年从 V2Ray 代码基础分支发展,此后形成了独立的功能演进与发布节奏。两者有共同来源,因此不少配置结构相似,但不能据此认为新特性、默认行为和字段名称始终一致。

v2rayN 是桌面客户端,负责订阅管理、节点编辑、生成配置和启动所选内核;实际建立代理连接的是内核进程。安卓端的 v2rayNG 使用 Xray 内核,v2flyNG 使用 V2Fly 内核。客户端名称中带有相似字样,不代表其接受的节点能力完全相同。

导入节点 生成配置 内核校验 路由匹配 出站握手

订阅中的分享链接也不是可以直接交给任意内核执行的完整配置。客户端需要把节点参数转换成对应内核的出站对象,再补齐本地入站、DNS 和路由。订阅能够导入,只能说明客户端识别了链接格式;是否能够启动和完成握手,还要分别检查生成结果与服务端要求。

功能对比:VLESS、XTLS Vision 与 REALITY 分属不同层

VLESS 是代理协议,Vision 是 Xray 中与 VLESS 配合使用的流控方案,REALITY 则属于连接安全层。常见的“VLESS + TCP + REALITY + Vision”实际组合了四类设置。不能把 REALITY 当成 VLESS 的另一个名称,也不能看到 VLESS 就断定节点一定需要 Xray。

能力或设置Xray-coreV2Fly-core切换时的判断
VMess、VLESS 基础协议支持支持还需核对传输与安全层
Trojan、Shadowsocks支持支持具体加密方法和扩展需逐项核实
常见 TCP、WebSocket 与 TLS支持支持路径、请求头、SNI 等仍要一致
XTLS Vision支持不支持 Xray 的 Vision flow检查 flow
REALITY支持不支持 Xray 的 REALITY检查 security 和密钥参数
DNS 与路由有独立实现与扩展有独立实现与扩展不能只替换出站节点就结束迁移

Vision 的配置通常体现为用户对象中的 flow: "xtls-rprx-vision",不是把 security 写成“Vision”。REALITY 则通常体现为 streamSettings.security: "reality",并带有对应的 realitySettings。常见 Vision 组合使用 TLS 或 REALITY;不要把 Vision flow 随意加到 WebSocket 节点上。

判断:先找不可替代字段,再决定是否换内核

如果服务端要求 REALITY 或 xtls-rprx-vision,应选择支持它们的 Xray;不要通过删除字段让配置勉强启动。删除客户端字段并不会同步改变服务端的握手要求。

配置兼容性:逐项核对流控、安全层与传输

下面两张卡是参数核对示例,不是完整连接配置。第一组说明 Xray 特性节点的关键设置;第二组说明两种内核常见的交集。地址、身份信息与安全参数应来自实际服务端配置或订阅,不能仅凭节点名称推测。

VLESS + REALITY + Vision

协议
vless
传输
TCP,具体字段拼写按内核版本
安全层
reality
Flow
xtls-rprx-vision
服务端口
443,仅作示例

保留服务端提供的 SNI、指纹、密钥参数与 shortId,交由支持该组合的 Xray 处理。

VMess + WebSocket + TLS

协议
vmess
传输
ws
安全层
tls
WebSocket 路径
/ws,仅作示例
VMess 设置
alterId: 0,使用 AEAD

两种内核均有对应能力;路径、Host、SNI 与服务端配置一致才有连接基础。

老教程中单独称作“XTLS”的配置,可能指向早期方案,不等同于当前的 Vision。迁移时应辨认实际 flow 值及安全层,避免把历史配置逐字复制进新版本。客户端升级后,还要确认实际启动的内核版本,而不是只记录客户端版本号。

v2rayN 内核切换:先备份,再做最小验证

v2rayN 不同版本的菜单名称与内核选择位置可能调整。操作时先在「设置」→「参数设置」中查找内核相关选项;若当前版本按节点类型提供内核选择,应以该版本界面的“Core 类型”或同类字段为准。不要把所有协议统一切到一个内核后,再同时修改 DNS、路由和系统代理。

  1. 记录基线。备份当前客户端配置,记录客户端版本、日志中的内核版本、选中节点、本地监听地址与端口。敏感订阅地址只保存在本地。
  2. 挑选交集节点。优先用已有的 VMess + WebSocket + TLS 等两边都支持的节点验证。如果手中只有 REALITY 节点,就不具备切换到 V2Fly 的等价测试条件。
  3. 只改一项。修改对应协议的内核选择,停止并重新启动连接。先确认新进程已启动,再确认日志所示的实际内核,避免旧进程仍占用端口。
  4. 检查本地入口。保持应用的代理类型与端口不变,进行一次实际网页请求。延迟测试能返回数字,并不证明浏览器的系统代理入口正确。
  5. 分层恢复功能。基础连接通过后,再恢复自定义路由、DNS 与其他高级设置,每恢复一项就重复测试,便于定位兼容性问题。
127.0.0.1
本机回环监听地址示例
10808
本地代理端口示例
443
远端服务端口示例

上述数字用于区分本地入口与远端出口,不代表客户端固定默认值。实际端口以当前设置为准;本地 HTTP、SOCKS 或混合监听的类型也必须一起核对。远端使用 443,并不意味着浏览器应把系统代理指向本机 443。

启动与连接排错:配置通过不等于握手成功

手工维护完整配置时,可先执行内核自带的配置检查。下面分别是 Xray 与 V2Fly v5 命令行形式的常见用法,client.json 指本地已经保存的完整配置文件。其他版本先运行帮助命令确认参数;客户端自动生成的临时文件应先复制备份,再用于离线检查。

xray version
xray run -test -config client.json

v2ray version
v2ray test -c client.json

配置检查能发现语法错误、部分无效字段与不支持的组合,但不会证明远端可达,也不会证明身份信息正确。内核启动成功后,还需要实际发起连接,观察出站握手与请求是否完成。下表按失败阶段划分,避免把所有错误都归为“节点失效”。

现象优先检查下一步操作
加载配置即退出字段类型、协议名、flow 与安全层读取第一条配置错误,核对当前内核支持范围
提示端口已被占用旧内核进程与重复运行的客户端停止重复实例,确认监听端口后重启
启动正常但握手失败SNI、身份信息、REALITY 参数、系统时间与原始节点逐项对照,不先改路由
基础节点可用,部分域名失败DNS 策略、路由规则、数据文件暂用基础路由验证,再逐条恢复规则
客户端测试可用,浏览器失败系统代理、浏览器独立代理设置核对应用是否连接到当前本地监听端口

路由中的 geosite: 与 geoip: 还依赖数据文件的内容及加载路径。两边都认识某种规则语法,不代表本机数据里一定存在对应类别。迁移时应连同 domainStrategy、DNS 服务器、出站标签和最终兜底规则一起核对,否则可能出现“能够启动,但分流结果不同”。

常见问题:内核选择与性能判断

把 REALITY 节点改成普通 TLS,就能给 V2Fly 用吗?

不能只改客户端。普通 TLS 与 REALITY 的握手条件不同,需要服务端提供对应入口和参数。应取得一份确实支持目标内核的节点配置,再进行导入测试,而不是把 security 改名。

v2rayNG 导出的节点,v2flyNG 为什么导入后连不上?

先展开节点详情,查看安全层是否为 REALITY、流控是否为 Vision,以及传输是否属于两边的交集。若有 Xray 专用能力,改用支持该组合的客户端;若没有,再核对导入后路径、SNI 和端口是否保留。

换成 Xray 就一定更快吗?

不能这样推断。比较时保持同一服务器、线路、测试目标与代理入口,先预热,再做至少 3 轮相同时长的下载测试,同时观察 CPU 占用、重传和失败次数。不同协议节点的结果不能直接归因于内核。

两种内核可以同时开着测试吗?

可以,但本地监听端口必须不同,系统代理只能明确指向其中一个入口。更容易复现的做法是顺序测试:停止前一个内核,确认端口释放,再启动另一个,保持其他设置不变。

选择依据:服务端能力优先,配置可复现其次

需要 REALITY 或 Vision 时选择 Xray;使用共同支持的协议组合时,以实际版本的配置检查、连接结果和维护需求决定。保留一份已验证配置,比同时调整内核、节点和路由更有利于稳定排错。

v2rayN下载