选择内核时，先确认节点要求的协议、传输和安全层，再检查客户端能否正确生成配置。本文适合正在使用 v2rayN，或准备在安卓端选择 v2rayNG、v2flyNG 的读者，重点说明 REALITY 与 Vision 的依赖、两类配置不能直接互换的原因，以及切换内核时怎样保留可回退的工作状态。
先分清客户端、内核与服务端
v2rayN 是桌面图形客户端，负责订阅管理、节点编辑、代理开关以及配置生成；Xray-core 和 V2Fly 维护的 V2Ray 则负责实际的连接处理。客户端窗口能正常打开，不代表内核已经成功启动；节点能显示在列表中，也不代表它的全部字段都被当前内核支持。
Xray 与 V2Fly 有共同的技术历史，但已经沿各自路线演进。把 Xray 理解为“任何情况下都能替换的新版 V2Ray”并不准确；反过来，也不能因为两个配置都出现 inbounds、outbounds 就认为它们具有完整兼容性。
- 桌面端：使用 v2rayN 时，要核实当前客户端版本支持的内核与节点类型，并通过启动日志确认真正运行的内核，而不是只看安装目录里的文件名。
- 安卓端：v2rayNG 依托 Xray 内核；v2flyNG 依托 V2Fly 内核。它们不是同一个应用里的两个外观主题。
- 服务端：客户端不一定要与服务端使用同名内核，但双方必须支持同一协议组合，并使用一致的认证、传输与安全参数。
协议支持差异：不能只看 VLESS 或 VMess 名称
一个节点的完整能力要求，通常由代理协议、传输方式和安全层共同决定。VLESS 是代理协议，WebSocket 是传输方式，TLS 与 REALITY 涉及连接安全机制，Vision 则是 Xray 中相关场景使用的流控机制。它们不在同一个层级，不能互相替代。
| 节点要求 | Xray | V2Fly | 选择前检查 |
|---|---|---|---|
| VMess + WebSocket + TLS | 常见支持组合 | 常见支持组合 | 认证参数、路径、Host 与 TLS 名称 |
| VLESS 基础协议 | 支持，并有自身扩展能力 | 部分版本或配置体系中有相关实现，需核对所用版本 | 不能仅凭 VLESS 名称推断完整兼容 |
| VLESS + REALITY | 属于 Xray 的典型使用场景 | 不能按 Xray REALITY 配置直接使用 | 公钥、服务名称、短标识与传输要求 |
| xtls-rprx-vision | 需要受支持的 Xray 版本与组合 | 不兼容该 Xray 流控值 | 服务端是否明确要求此 flow |
| SOCKS / HTTP 本地入口 | 支持常用本地代理入口 | 支持常用本地代理入口 | 监听地址、端口与应用代理设置 |
尤其要避免把“V2Fly 是否支持 VLESS”压缩成不带版本条件的永久结论。实际排查应落到当前二进制、配置格式和节点要求上；但如果订阅明确带有 security=reality 或 flow=xtls-rprx-vision，就不能把它作为普通 VLESS 节点交给 V2Fly 运行。
结论：先按节点能力筛选内核
节点明确要求 REALITY 或 Vision 时，选择支持该组合的 Xray 环境；已有 VMess + WebSocket + TLS 节点稳定可用时，不必仅为更换内核名称重建配置。
配置字段兼容：JSON 能读取不等于连接能建立
两边配置中可能出现相似字段，但字段所处位置、取值约束和运行语义可能不同。V2Fly 的不同配置格式也不能混为一谈。客户端生成的完整配置通常还包含 DNS、路由和本地入站，复制单个出站对象并不等于完成迁移。
下面两张卡展示的是需要逐项核对的参数组合，不是可直接导入的节点，也没有包含服务器地址与认证信息。WebSocket 路径 /ws 只是示例，必须以服务端设置为准。
VLESS + REALITY + Vision
- 协议
- VLESS
- 传输
- TCP，界面命名随版本可能不同
- 安全层
- REALITY
- Flow
xtls-rprx-vision- 核对项
- 服务名称、公钥、短标识
此组合依赖相应 Xray 能力；不要通过删除安全字段来尝试兼容另一内核。
VMess + WebSocket + TLS
- 协议
- VMess
- 传输
- WebSocket
- 路径示例
/ws- 安全层
- TLS
- 核对项
- UUID、Host、服务名称
两种内核均有常见支持场景，但仍需按各自配置格式生成字段。
- 协议字段：核实 UUID、加密参数与 flow，不把一个协议的认证字段照搬给另一个协议。
- 传输字段：路径、请求头与传输名称都要对照当前版本；旧教程中的名称不能保证适用于新配置。
- 安全字段：TLS 的服务名称与 WebSocket 的 Host 作用不同，即使示例中写成同一域名，也不能认为两者总是相等。
- 路由字段：检查出站标签是否仍存在。规则引用了旧标签时，问题可能发生在路由阶段，而不是协议握手阶段。
订阅导入与路由分流：切换后需要重新验证
订阅链接是节点分发入口，不是运行内核本身。订阅能更新成功，只能说明下载和解析的某些步骤完成了；某些客户端版本可能忽略不认识的字段，或无法生成对应出站。因此，看到服务器数量增加之后，还要打开节点编辑界面核对关键参数。
- 保留原分组：先导出必要设置并妥善保存订阅地址，在新分组中测试，不覆盖唯一可用的配置。
- 检查导入结果：对照提供方说明，核实协议、端口、传输、安全层与 flow。REALITY 节点还要检查公钥、服务名称和短标识。
- 确认运行内核：重新启动连接并读取日志中的内核身份、启动错误和监听信息。仅修改节点备注不会切换内核。
- 分别验证出站：先验证指定节点是否能访问测试目标，再验证直连域名与代理域名是否命中预期规则。
路由分流依赖规则顺序、DNS 解析策略、域名与 IP 规则数据以及嗅探设置。两次测试若使用了不同规则文件或不同 DNS，结果差异不能直接归因于 Xray 或 V2Fly。系统代理和 TUN 的接管范围也不同，测试内核时应保持接管方式一致。
本地端口与握手错误：按连接阶段定位
“切换后无法联网”并不是一个足以判断内核优劣的结论。先区分内核启动失败、本地入口不可用和远端握手失败，通常比反复更换节点更有效。下列数字是说明链路用的配置示例，不代表所有客户端的默认值。
| 日志或现象 | 优先检查 | 下一步操作 |
|---|---|---|
unknown field 或配置加载失败 | 字段位置、配置格式及内核版本 | 让当前客户端重新生成配置，不盲删未知字段 |
address already in use | 本地监听端口是否被占用 | 退出重复运行的代理进程，或同步更改监听与应用端口 |
connection refused | 错误指向本地还是远端地址 | 本地先查监听，远端再查服务是否开放及端口是否正确 |
| 证书名称不匹配 | TLS 服务名称、证书与系统时间 | 修正名称与时间，不以跳过验证作为常规修复 |
| 握手失败或连接超时 | 协议参数与网络可达性 | 核对参数后再检查网络；单凭错误短语不能确定原因 |
例如，应用连接 127.0.0.1:10808 就被拒绝时，应先确认内核有没有监听该地址，不必立即怀疑远端 443。如果本地入口可用，但日志显示远端握手失败，再检查 UUID、服务名称及安全参数。这两个阶段的处理方向完全不同。
更新节奏与性能比较：一次只改变一个变量
Xray 与 V2Fly 分别维护自己的发布记录，版本编号不能横向比较大小，也不能仅按发布日期判断哪一个更适合当前节点。实际可用性还取决于图形客户端是否支持新增字段、附带内核是否匹配，以及服务端是否采用对应能力。
性能同样不能脱离环境下结论。线路拥塞、服务端负载、传输方式、DNS 与路由都可能影响测速；把不同协议、不同线路的测试放在一起，不能得出某个内核固定快多少的结论。
- 建立基线：记录客户端与内核实际版本、节点参数、代理模式和路由配置；保存当前可用安装文件与配置备份。
- 控制变量：只在双方支持的相同协议组合下比较，固定服务器、测试目标和接管方式。
- 重复观察：每个方案至少进行 3 次相同条件测试，分别记录连接是否成功、响应时间和持续传输表现，不只看一次延迟数值。
- 核对更新内容：确认新版本解决的问题与当前场景有关，升级后重新检查启动日志、DNS、直连和代理访问。
结论：保留可回退状态，再做升级验证
只升级客户端或只替换内核都可能产生配置生成与执行能力不匹配。先按客户端说明确认支持范围，再在备份基础上测试；出现问题时恢复已知可用组合，而不是连续修改多个设置。
按实际节点选择：三类使用场景
内核选择最终应回到“现有节点需要什么”与“当前客户端能正确生成什么”。不需要为了统一名称而替换全部设备，也不应为了保留某个旧配置而忽略服务端已经改变的连接要求。
- 节点要求 REALITY 或 Vision：桌面端在 v2rayN 中确认使用受支持的 Xray 组合；安卓端选择匹配该能力的 v2rayNG，并逐项核实导入字段。
- 已有 V2Fly 配置稳定运行：如果节点采用受支持的协议组合，且没有新增能力需求，可以继续使用；安卓端的 v2flyNG 适合与该内核能力匹配的节点。
- 准备跨内核迁移：优先从原始订阅或服务端参数重新生成配置，分别检查协议、安全层、DNS 与路由，不把整份旧 JSON 当成通用配置文件。
判断是否选对的标准是：内核正常启动、节点参数完整、目标连接成功、分流结果符合预期。满足这些条件后，再考虑更新便利性与配置维护成本，比按项目名称做笼统排名更实用。