先看服务器要求,再选内核。VLESS、传输方式、TLS 或 REALITY、flow 是不同层的参数,不能只凭一个协议名称判断兼容性。本文适合准备在 v2rayN 中切换内核,或在 Android 上选择 v2rayNG、v2flyNG 的用户;重点给出字段核对方法、切换步骤和失败后的排查顺序。
两条内核分支,和客户端的关系
V2Fly 社区维护 V2Ray 核心,Xray-core 则是从 V2Ray 项目分出的另一条开发路线。两者有共同的配置历史,但后续协议实现、传输能力和配置字段各自演进。不能把 Xray 理解为 V2Fly 的一个界面,也不能认为两份 JSON 只改程序名就一定能运行。
客户端负责订阅、服务器列表、系统代理和配置生成;内核负责实际连接、协议处理与路由执行。v2rayN 是桌面客户端,具体能调用哪些内核,还取决于安装包、客户端版本及其配置生成能力。Android 上,v2rayNG 使用 Xray 内核,v2flyNG 使用 V2Fly 内核,它们不是同一个应用里的两个皮肤。
- 界面支持:编辑服务器时,能否填写所需的传输、安全与流控参数。
- 内核支持:实际启动的程序能否解析配置,并实现对应功能。
- 服务端匹配:服务器是否使用相同的协议组合、身份凭据和握手参数。
这三层必须同时成立。导入成功只说明客户端识别了分享内容;列表里出现服务器,不等于内核已经建立连接。遇到兼容性问题,先区分是导入时丢字段,还是启动时解析失败,最后才检查远端握手。
VLESS、XTLS 与 REALITY 分别是什么
VLESS 是代理协议;XTLS Vision 是 Xray 体系中的流控能力,常见配置值为 xtls-rprx-vision;REALITY 是另一层连接安全机制。它们可以出现在同一个服务器配置里,但不是三个可以随意互换的“协议按钮”。VLESS 本身不提供完整的传输加密,不能把 VLESS 名称当成 TLS 已开启的证据。
| 能力 | Xray 内核 | V2Fly 内核 | 核对重点 |
|---|---|---|---|
| VMess | 支持 | 支持 | 身份凭据、安全参数、传输方式仍须一致 |
| VLESS 基础协议 | 支持 | 已有实现,具体以所用版本和配置格式为准 | 支持基础协议不等于支持 Xray 扩展组合 |
| XTLS Vision | 支持对应的 VLESS 流控 | 不能按 Xray Vision 配置直接使用 | flow 与服务端要求一致 |
| REALITY | 支持 | 不能直接运行 Xray REALITY 配置 | 安全类型、服务器名称、公钥参数与短标识 |
| WebSocket + TLS | 支持常见组合 | 支持常见组合 | 路径、Host、服务器名称及证书验证 |
因此,“V2Fly 完全不支持 VLESS”过于笼统;“支持 VLESS 就能连接任何 VLESS 服务器”同样不成立。尤其是带 REALITY 或 Vision 的分享链接,应当按 Xray 的能力和客户端支持范围判断,不要仅凭 vless:// 前缀下结论。
结论:先读 security 和 flow,再选内核
服务器明确要求 REALITY 或 xtls-rprx-vision 时,选择能完整生成对应配置的 Xray 客户端组合;只有普通 VMess 或常见 TLS 传输时,再比较现有配置与维护需求。
按服务器需求选择内核
下面的推荐有明确前提:需要连接包含 REALITY 或 Vision 的服务器。它不是速度排名,也不表示同一条线路换成 Xray 就会降低延迟。线路质量、服务端负载、传输组合和本地网络都会影响结果,没有相同测试条件就不能给出性能百分比。
Xray 内核
推荐服务器要求 VLESS + REALITY 或 Vision 时,优先沿用 Xray 配置链路。桌面端确认 v2rayN 已安装可用的 Xray 核心,Android 端选择 v2rayNG,并检查导入后关键参数是否保留。
适合:服务端明确要求 REALITY、Vision,或已有可用 Xray 配置。
V2Fly 内核
已有 V2Fly 配置、VMess 或常见 WebSocket + TLS 服务器时,可以继续使用。迁移前先验证实际配置,不必仅因两个内核名称不同就重建全部服务器与路由规则。
适合:现有配置依赖 V2Fly,且服务器不要求 Xray 专有能力。
旧资料中的“XTLS”还可能指向早期配置写法,不应直接套用到 Vision。若订阅提供方只写“支持 VLESS”,需要进一步确认传输类型、安全类型和流控值。缺少这些信息时,不要通过反复切换内核来猜测服务器配置。
配置兼容性:逐项检查这张清单
分享链接是客户端之间传递参数的格式,不是完整内核配置。订阅导入后,客户端会把参数转换成自己的数据,再生成内核运行配置。任何一层漏掉字段,都可能出现“链接能导入,启动却失败”或“启动正常,连接失败”的现象。
| 检查位置 | 常见字段 | 处理方式 |
|---|---|---|
| 服务器地址与端口 | address、port | 使用服务端给定值;443 只是常见端口,不是强制要求 |
| 用户身份与流控 | id、flow | 核对身份凭据;Vision 使用服务端要求的流控值 |
| 传输层 | streamSettings.network | 按实际内核版本识别的传输名称生成,不能机械复制别的分支配置 |
| 连接安全 | streamSettings.security | 区分 tls 与 reality,不要互相替换 |
| 服务器名称 | serverName | 与服务端允许的名称匹配,不一定等于连接地址 |
| REALITY 参数 | realitySettings 内的公钥参数、shortId | 以当前客户端和核心支持的字段名为准,从提供方资料核对值 |
| WebSocket 请求 | wsSettings.path、headers.Host | 保留路径与请求头,不能只复制域名和端口 |
自定义 JSON 比普通服务器条目更需要谨慎。即使两边都有 inbounds、outbounds 和 routing,内部字段、默认行为及规则数据依赖也可能不同。先备份原文件,再用目标内核测试解析;不要把“JSON 语法合法”当成“内核配置合法”。
v2rayN 切换内核与 Android 选型
v2rayN 不同界面的菜单位置可能调整。常见入口为「设置」→「参数设置」中的「Core 类型设置」;应按协议查看对应的内核映射,而不是假定所有服务器都会一起切换。若当前版本没有该项,先确认安装包支持的内核类型,不要在服务器的协议下拉框里把 VLESS 改成 VMess。
- 保留回退配置。备份服务器与订阅信息,记下当前可用服务器、内核名称和本地监听端口。不要在第一次测试时同时修改路由、DNS 与安全参数。
- 确认程序可执行。检查目标核心是否已安装,是否匹配系统和处理器架构。Windows、macOS、Linux 的程序文件不能互换使用。
- 调整协议映射。在 Core 类型设置中检查目标协议使用的内核,保存后重新启动核心;自定义配置还要单独确认其指定的核心类型。
- 读取启动日志。核对实际启动的核心及版本信息。先确认没有字段解析错误,再检查远端连接,避免把启动失败误判为线路不可用。
- 分别测试代理与应用。若本地 SOCKS 端口实际设为 10808,测试工具应连接该端口;不要假定 HTTP 端口一定是 10809,应以本机设置为准。
部署方案:桌面核对映射,Android 按内核选应用
桌面端:v2rayN
- 在参数设置中核对协议与核心的对应关系。
- 保存配置后重启核心,并从日志确认实际执行程序。
- 切换期间保留原来的 DNS、路由和本地监听设置。
Android:v2rayNG / v2flyNG
- 需要 Xray 能力时选择 v2rayNG。
- 沿用 V2Fly 配置时评估 v2flyNG 的实际支持范围。
- 导入同一订阅后检查字段,并核对系统 VPN 授权。
订阅地址可以相同,生成的配置与可用服务器范围不一定相同;两端都要完成一次实际连接验证。
切换后连不上:按错误阶段排查
排查顺序应当是“解析配置 → 本地监听 → 连接服务器 → 握手认证 → 路由和 DNS”。前一步没有通过,就不要先调整后一步。记录报错附近的字段和出站标签即可;向他人求助前,移除订阅地址、身份凭据及服务端敏感信息。
切换后提示 unknown field,是服务器坏了吗?
这通常发生在配置解析阶段,还没有连接服务器。先从日志确认当前核心,再检查报错指出的字段是否属于另一条内核分支;在客户端重新保存服务器以生成配置,避免直接复制不兼容的自定义 JSON。
同一条 VLESS 链接,为什么换成 V2Fly 就失败?
打开服务器编辑窗口,检查是否启用了 REALITY,或流控是否为 xtls-rprx-vision。存在这些要求时,恢复支持该组合的 Xray 内核;不要删掉安全参数来强行通过启动。
内核启动正常,但日志一直握手失败怎么办?
逐项核对服务器地址、端口、身份凭据、服务器名称、REALITY 公钥参数与短标识,并确认设备时间准确。若使用 WebSocket + TLS,另外检查路径和 Host;每次只修改一类参数,保存后重新测试。
日志提示 address already in use,还需要换内核吗?
先检查本地监听端口。例如实际配置为 10808 时,退出占用该端口的其他进程,或在参数设置中修改本地监听端口,并同步更新应用代理设置。这是端口冲突,不是 Xray 与 V2Fly 的协议差异。
最终判断标准是:目标内核可以解析配置、监听成功、完成服务端握手,并让实际应用按预期路由。若只有浏览器失败,而代理连接测试正常,再检查系统代理与浏览器设置;若只有部分域名失败,再检查 DNS 和路由规则。不要把所有问题都归结为“内核选错”。