先按节点参数判断内核,不要只看客户端名称。VMess、WebSocket、TLS 等常规组合通常可在两类内核之间迁移;带有 xtls-rprx-vision、REALITY、shortId 或特定 Xray 传输字段的节点应使用 Xray。本文适合需要选择 v2rayN、v2rayNG、v2flyNG,或正在排查订阅导入后节点无法启动的用户。
Project V、V2Fly 与 Xray 的关系
先把客户端和内核分开。v2rayN、v2rayNG、v2flyNG 负责订阅管理、节点列表、系统代理和图形设置;Xray-core 与 v2ray-core 才负责解析运行配置、建立连接、执行 DNS 与路由规则。界面能识别一条分享链接,不代表当前内核一定能运行链接中的全部字段。
V2Fly 延续 Project V 体系中的 v2ray-core。配置仍围绕 inbounds、outbounds、routing、dns 与 transport 展开。它适合 VMess、SOCKS、HTTP、Shadowsocks,以及 WebSocket、gRPC、TLS 等已经稳定使用多年的组合。维护方向强调通用代理平台和配置接口的持续演进。
Xray-core 从相同配置体系发展而来,保留了大量 V2Ray JSON 结构,同时扩展 VLESS、XTLS Vision、REALITY 和面向新传输方式的字段。两者因此不是完全无关的两个项目,也不能按“配置文件改个程序名就一定可用”理解。
VMess、VLESS、XTLS 与 REALITY 支持差异
VMess 是两类内核的共同基础。服务器使用 VMess,加上传统 TCP、WebSocket 或 gRPC 传输时,Xray 与较新的 V2Fly 通常都能完成连接。迁移时仍要核对 alterId、加密方式、Host、路径和 TLS 服务名;任何一个字段缺失都可能表现为握手失败。
VLESS 不能只按协议名称判断。现代内核可能都能处理某些基础 VLESS 配置,但 VLESS 与 XTLS Vision、REALITY 组合后,实际依赖的是 Xray 的扩展字段和握手流程。分享链接中出现 flow=xtls-rprx-vision、security=reality、pbk、sid 或 fp 时,应直接选 Xray。
| 节点组合 | Xray | V2Fly | 迁移注意项 |
|---|---|---|---|
| VMess + TCP | 支持 | 支持 | 核对 UUID、端口与加密字段 |
| VMess + WebSocket + TLS | 支持 | 支持 | 核对 Host、path、SNI 与证书域名 |
| VLESS + TCP + TLS | 支持 | 依版本与配置而定 | 先删除 Xray 专属 flow 字段再测试 |
| VLESS + XTLS Vision | 支持 | 不可直接互换 | 必须保留 flow=xtls-rprx-vision |
| VLESS + REALITY | 支持 | 不可按普通 TLS 节点替代 | 公钥、shortId、serverName 必须匹配 |
Xray 内核
推荐覆盖 VMess 与常见 VLESS 配置,并直接处理 XTLS Vision、REALITY 及对应分享链接字段。
适合:日常主力、新订阅、VLESS 与 REALITY 节点
V2Fly 内核
适合结构明确的 VMess、WebSocket、gRPC、TLS 配置,也便于维持已有 v2ray-core 部署。
适合:现有 VMess 节点、固定 JSON 配置、V2Fly 服务端
结论:看完整参数,不只看 VLESS 字样
基础 VLESS 与 VLESS、Vision、REALITY 的组合不是同一个兼容范围。只要订阅包含 security=reality 或 flow=xtls-rprx-vision,客户端侧就应固定使用 Xray,避免导入成功但启动失败。
传输层与 JSON 配置兼容范围
两类内核都沿用分层配置思路:入站接收本地流量,出站连接远端服务器,路由决定流量进入代理、直连或阻断出口。常见的 routing.rules、dns.servers、inbounds 与 outbounds 结构相似,所以简单配置经常可以复用。
兼容边界主要出现在 streamSettings。Xray 节点可能在 security、realitySettings、tlsSettings、grpcSettings 或其他传输对象中增加专属字段。V2Fly 遇到未知字段时,可能在启动阶段直接报告配置错误,也可能因版本差异忽略部分内容。忽略字段并不等于连接参数正确。
订阅链接也不是由内核直接保存和更新。客户端先读取订阅,将 vmess:// 或 vless:// 内容转换为运行配置,再调用选定内核。由此会出现两层兼容问题:客户端是否认识分享字段,以及内核是否实现字段对应的协议行为。
{
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "node.example.net",
"port": 443,
"users": [
{
"id": "11111111-2222-3333-4444-555555555555",
"encryption": "none",
"flow": "xtls-rprx-vision"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "reality",
"realitySettings": {
"serverName": "www.example.com",
"fingerprint": "chrome",
"publicKey": "examplePublicKey",
"shortId": "6ba85179e30d4fc2"
}
}
}
]
}
- 先复制原配置,保留可恢复版本,不要直接覆盖正在使用的文件。
- 执行内核的配置测试或从客户端启动一次,优先处理 unknown field、failed to parse config 与 invalid user 等错误。
- 检查出站协议、network、security、flow 四项。REALITY 配置不要改写成普通 TLS 后继续使用。
- 确认本地监听端口未冲突。本文测试使用 SOCKS 10808、HTTP 10809;同一端口只能由一个进程监听。
- 连接后查看内核日志。若 TCP 已建立但 TLS 或 REALITY 握手失败,应回查 serverName、公钥、shortId 与系统时间。
v2rayN、v2rayNG 与 v2flyNG 默认搭配
桌面端优先使用 v2rayN。当前常用版本以 Xray 作为主要内核,适合同时保存 VMess、VLESS、XTLS Vision 与 REALITY 节点。需要核对时,打开「设置」→「参数设置」→「Core 类型」,确认目标协议被分配给 Xray,而不是仅检查系统代理开关。
Android 端的 v2rayNG 采用 Xray 内核,适合与 v2rayN 共用包含 REALITY 节点的订阅。v2flyNG 对应 V2Fly 内核,更适合现有服务端明确使用 v2ray-core、节点以 VMess 和常规传输为主的环境。两款客户端界面接近,但内核能力不能据此视为完全相同。
推荐方案:桌面与 Android 共用一条订阅
桌面端(v2rayN)
- 将 VLESS、Vision、REALITY 分配给 Xray
- 本地混合代理端口保持 10808
- 更新订阅后测试延迟并查看 Core 日志
Android 端(v2rayNG)
- 导入同一条订阅链接
- 保留节点中的 flow 与 REALITY 参数
- 按应用范围设置代理,不改写订阅原始字段
两端都使用 Xray 时,VLESS 分享字段的解释更一致;节点变更只需分别执行一次订阅更新。
选择 v2flyNG 的条件
- 服务端明确运行 V2Fly,现有节点以 VMess、TCP、WebSocket、gRPC 或普通 TLS 为主。
- 订阅中没有 xtls-rprx-vision、REALITY 公钥、shortId 等 Xray 专属参数。
- 需要验证同一份 V2Fly JSON 逻辑,且路由规则依赖当前 v2ray-core 的行为。
- 愿意在新增节点时重新检查协议能力,而不是默认所有 VLESS 链接都能直接使用。
性能差异与实际选型方法
内核名称本身通常不是速度差距的主要来源。在相同服务器、相同 VMess WebSocket TLS 节点和相同路由规则下,吞吐量更容易受网络路径、TLS 握手、服务器负载与 WebSocket 额外开销影响。先确认协议兼容,再比较速度。
本文在 300 Mbps 下行、50 Mbps 上行、往返延迟 38 ms 的固定线路上测试 500 MiB 文件。VMess、WebSocket、TLS 组合中,Xray 平均下行 286 Mbps,V2Fly 平均下行 281 Mbps,五轮差距约 1.8%。该结果只说明相同传统协议下两者没有数量级差距,不能直接套用到其他线路。
切换到 VLESS、Vision、REALITY 后,重点变为功能可用性。Xray 完成五轮连接,平均下行 292 Mbps;V2Fly 无法把这组参数当作普通 VLESS TLS 配置等价运行。此时不应比较两者速度,因为兼容前提已经不成立。
结论:协议覆盖优先于微小吞吐差
传统 VMess 节点在同线路下的内核差距可能低于 5%;节点包含 Vision 或 REALITY 时,先选能完整解释配置的 Xray,再处理延迟、丢包和服务器负载。
- 查看订阅节点详情。出现 VMess、WebSocket、TLS,可在两类内核间做兼容测试。
- 出现 VLESS 后继续检查 flow 和 security。存在 Vision 或 REALITY 就选择 Xray。
- 分别测试 TCP 建连、TLS 握手与首字节时间,不要只看客户端显示的 ICMP 或 TCP 延迟。
- 连续下载固定大小文件三到五轮,记录平均速度与失败次数,排除单次线路抖动。
- 最后开启正式路由规则,检查 DNS 与分流是否改变结果。全局代理测试不能替代实际分流环境。
常见兼容问题与处理步骤
订阅能导入,为什么 REALITY 节点一启动就失败?
先确认当前客户端调用的是 Xray。v2rayN 打开「设置」→「参数设置」→「Core 类型」,检查 VLESS 对应项;再核对节点详情中的 publicKey、shortId、serverName、fingerprint 和 flow,任一项被订阅转换过程截断都会导致握手失败。
VMess 节点换成另一个内核后超时,应该看哪里?
依次核对 address、port、UUID、security、network、Host 和 path。WebSocket 路径需要保留开头的斜线,TLS 的 serverName 应与服务端证书配置一致。随后查看日志中是 DNS 失败、TCP 超时还是 TLS 握手错误。
v2rayNG 可以连接,v2flyNG 使用同一订阅却失败?
展开失败节点,查看是否包含 VLESS、xtls-rprx-vision 或 REALITY 参数。v2rayNG 使用 Xray,v2flyNG 使用 V2Fly,两者对扩展字段的支持范围不同。该类节点应继续放在 v2rayNG 中,不要删除安全字段后强行导入。
内核启动时报端口已被占用怎么处理?
退出重复运行的客户端,或修改本地监听端口。若 SOCKS 使用 10808,HTTP 可使用 10809;修改后还要同步更新浏览器、命令行工具或系统代理设置,避免程序仍连接旧端口。
更换内核后分流规则没有生效?
先检查规则引用的 outboundTag 是否与出站标签一致,再确认 GeoIP、GeoSite 分类名能被当前内核识别。保存后完全停止旧内核并重新启动,通过日志验证域名最终进入 proxy、direct 或 block 出站。
最终选型清单
- 新建桌面配置、订阅协议混合:使用 v2rayN 与 Xray。
- Android 需要 VLESS、Vision、REALITY:使用 v2rayNG。
- 既有 V2Fly 服务端、VMess 与常规传输为主:可使用 v2flyNG。
- 同一订阅跨设备使用:尽量保持两端内核能力一致。
- 迁移 JSON:先做配置测试,再连接节点,最后恢复 DNS 与路由规则。