Project V 是项目体系，V2Ray 是其中的核心软件，V2Fly 是延续 V2Ray 开发的社区，Xray 是从相关代码发展出来的独立分支；v2rayN、v2rayNG、v2flyNG 则是用户操作的图形客户端。本文适合正在选客户端、辨认订阅协议或准备切换内核的用户，重点说明这些名称分别处在哪一层，以及如何按现有配置做选择。
先分四层：项目、内核、客户端、协议
搜索“V2Ray 下载”时，结果可能同时出现项目介绍、命令行程序和带界面的客户端。这些名称有关联，却不是同一种东西。判断一份教程能否照着操作，第一步不是比较名称相似度，而是确认它讲的是哪一层。
| 层次 | 常见名称 | 实际职责 |
|---|---|---|
| 项目与社区 | Project V、V2Fly | 组织项目、维护代码、文档与相关工具。 |
| 代理内核 | V2Ray、Xray | 监听本地入口，执行路由、DNS 与协议连接。 |
| 图形客户端 | v2rayN、v2rayNG、v2flyNG | 管理订阅、编辑配置、启动内核并呈现日志。 |
| 连接协议 | VMess、VLESS | 规定客户端与服务端之间的认证及数据交互方式。 |
以桌面端为例：用户在 v2rayN 里选择服务器并开启系统代理，应用连接到本地代理入口，内核再按规则选择出站。界面负责生成和管理配置，真正与远端建立协议连接的是内核。更换界面不等于更换协议，更新订阅也不等于更新内核。
Project V 到 V2Fly、Xray：分支关系怎么理解
Project V 的发展可追溯到 2015 年前后，V2Ray 是这一项目体系中的重要实现。其设计并不只围绕单一协议展开，而是把入站、出站、传输、路由等能力组合起来。因此，V2Ray 既不是 VMess 的另一个名字，也不只是一个订阅管理界面。
2020 年前后，原项目维护节奏发生变化，V2Fly 社区承接并延续 V2Ray 核心及相关生态的开发。随后，Xray 在同一技术谱系上形成独立分支，围绕包括 XTLS 在内的连接技术继续演进。这里的“分支”是代码与历史关系，不代表两边后续每项功能都同步发布。
Project V 项目体系
└─ V2Ray 核心及相关工具
├─ V2Fly 社区延续 V2Ray 开发
│ └─ v2flyNG：Android 图形客户端，集成 V2Fly 核心
└─ Xray：从相关代码发展出的独立分支
└─ v2rayNG：Android 图形客户端，集成 Xray 核心
v2rayN：桌面图形客户端
└─ 可管理不同内核；实际可选项取决于发行包与配置这张关系图表达的是主要来源与常见搭配，不是上下级管理结构。v2rayN 并非 V2Fly 或 Xray 的另一个名称，两个 Android 客户端也不是把同一个程序换了图标。它们会分别适配所集成内核的配置能力、订阅解析和系统网络入口。
- V2Fly 不等于新协议：看到这个名称，优先把它理解为社区及其维护的 V2Ray 实现。
- Xray 不等于 V2Ray 的通用新版：它是独立发展的分支，升级路径和配置细节需要分别确认。
- 同源不代表配置完全通用：相同 JSON 字段可能存在支持范围、默认值或行为差异，迁移前应验证。
三款客户端分别搭配什么内核
客户端选择可以先按系统分组，再按订阅需求筛选。桌面端的 v2rayN 面向 Windows、macOS、Linux，具体安装包与可用功能以对应发行内容为准；Android 端主要在 v2rayNG 与 v2flyNG 之间选择。下面的推荐场景限定为“服务端明确使用 Xray 特性”，不是对所有连接环境做性能排名。
v2rayNG：Android 与 Xray 核心
推荐集成 Xray 核心。已有 VLESS、REALITY 或 XTLS Vision 配置时，优先检查其当前发行版是否支持服务端要求的完整参数，再导入使用。
适合：Android 用户，且订阅明确要求 Xray 相关能力。
v2flyNG：Android 与 V2Fly 核心
集成 V2Fly 核心，适合沿用已经在 V2Fly 环境验证过的连接配置。选择依据应是协议、传输与参数兼容性，而不是客户端名称与 V2Ray 更接近。
适合：Android 用户，现有服务和配置按 V2Fly 能力提供。
v2rayN：桌面端与可选内核
负责桌面端订阅、路由与内核运行管理。使用 Xray 或 V2Fly 相关配置前，应确认发行包提供的内核、该配置的内核选择，以及实际启动结果。
适合：Windows、macOS、Linux 用户，需要在桌面管理连接。
选择顺序：系统 → 服务端要求 → 实际内核
先确定设备能安装哪款客户端，再核对订阅要求的协议组合，最后从启动日志确认内核身份；不要因为客户端名称含有“v2ray”，就推断它一定运行 V2Fly 核心。
图形客户端升级与内核升级也是两件事。新的界面可能改进订阅解析，但连接仍由实际加载的内核处理。排查时应同时记录客户端名称、当前内核名称、日志显示的内核版本，而不是只截取窗口标题。
VMess、VLESS、REALITY：别把协议名当成完整配置
VMess 与 VLESS 属于代理协议层，WebSocket 等属于传输方式，TLS、REALITY 涉及连接安全机制，XTLS Vision 则与特定流控配置有关。这些字段处在不同层，不能在导入失败时随意互换。尤其不能把一条 VMess 配置的协议改成 VLESS，期待服务端自动适配。
| 配置组合 | 需要核对的参数 | 选择时的重点 |
|---|---|---|
| VMess 与 WebSocket、TLS | 地址、端口、用户 ID、路径、Host、服务器名称 | 常见内核具备相关支持，但各字段仍须与服务端一致。 |
| VLESS 与 TLS | 用户 ID、传输方式、服务器名称、流控要求 | 不能只看 VLESS 标签，要核对当前实现支持的具体组合。 |
| VLESS 与 REALITY、Vision | 服务器名称、公钥、short ID、指纹、flow | 通常按 Xray 相关配置处理，并检查两端支持情况。 |
例如远端端口写成 443，只能说明连接目标使用这个端口，不能证明它一定是普通 HTTPS，更不能据此省略 TLS 或 REALITY 参数。VMess 的用户 ID 正确但 WebSocket 路径错误，仍可能握手失败；VLESS 的地址可达但公钥或服务器名称不匹配，也无法靠切换路由模式解决。
- 先检查服务说明：确认要求的客户端、内核能力和完整参数，而不是只看分享链接开头。
- 再检查导入结果：打开节点编辑页，确认传输、连接安全和流控字段没有丢失。
- 最后检查日志：区分配置无法解析、握手失败与连接超时，不把所有失败都归结为内核不兼容。
REALITY 并不是“安装 Xray 后自动启用”的功能。服务端必须采用对应配置，客户端还要得到匹配的参数。类似地，订阅里有 VMess 条目，并不意味着必须使用某一个固定内核；应以实际支持情况与连接结果判断。
桌面与 Android 共用订阅：配置如何保持一致
一条订阅链接可以分发给不同设备，但“同一个订阅地址”不保证“导入后每个字段和每条记录都相同”。客户端解析能力、过滤选项、更新时刻与内核支持范围都会影响结果。应先验证一条配置，再批量更新其余条目。
方案：同一订阅来源，分别确认本地入口
桌面端：v2rayN
- 导入订阅后，核对一条代表性配置的协议、传输与安全参数。
- 启动连接，从日志确认实际调用的内核。
- 使用系统代理时，检查应用是否遵循系统代理设置。
Android：v2rayNG 或 v2flyNG
- 根据服务端要求选择对应内核的客户端。
- 首次启动连接时完成系统 VPN 授权。
- 检查分应用设置，确认目标应用包含在接管范围内。
订阅统一的是远端配置来源；本地端口、系统代理、VPN 授权和分应用范围仍需在各设备分别设置。
桌面系统代理与 Android 的 VPN 接管不是同一个入口机制。前者通常依赖应用读取代理设置，后者通过系统授权的虚拟网络接口处理流量。即使两端选中了同一条远端配置，哪些应用进入内核、DNS 在哪里解析、私有地址如何直连，也可能不同。
- 记录两端同一条配置的地址、远端端口、协议、传输和安全类型；不公开用户 ID、订阅地址或密钥。
- 分别更新订阅，核对更新时间，并查看是否存在过滤后未显示的条目。
- 用同一个目标网站验证，先确认入口接管，再看内核出站与 DNS 日志。
- 连接正常后再调整路由，避免同时更换内核、DNS 和规则，导致无法定位变化来源。
生态选型常见问题：从哪里检查
装的是 v2rayN，为什么日志里出现 Xray？
这是客户端和内核分工的正常表现。先查看启动日志开头的内核名称，再检查当前配置选择的内核。需要核对具体参数时，可从 v2rayN 的「设置」→「参数设置」进入相关设置；不同发行版的分组文字可能调整，以当前界面为准。
v2rayNG 和 v2flyNG，能直接复制整个数据目录吗？
优先在目标客户端重新导入订阅或分享链接，不直接覆盖内部数据目录。导入后打开一条配置检查关键字段，再重新完成 VPN 授权与分应用设置。订阅入口只解决配置来源，不会替你迁移系统权限。
订阅能导入，为什么启动时还是报错？
导入成功只代表客户端解析了订阅格式。打开运行日志，若提示未知字段或配置无效，核对当前内核及协议组合；若提示地址已被占用，检查本地监听端口。例如 10808 已有进程监听时，应停止冲突进程或修改入口端口，并同步调整使用该入口的应用。
换成 Xray，就一定能提高速度吗？
不能仅凭内核名称判断。固定同一远端、同一网络和同一目标，每次只改一个设置，记录是否连接成功及日志错误。服务端负载、网络丢包、传输方式和路由都可能主导体验；不兼容的配置应先修正，再讨论性能。
切换内核前，保留一条可恢复路径
理解谱系的最终用途是减少盲目试错。已有连接正常时，不必为了名称更新而替换内核；遇到服务端提出新能力要求时，也不要只升级界面。更稳妥的做法是保留原配置，新增测试配置，验证通过后再切换日常使用项。
- 备份范围：导出客户端配置，记录订阅分组、当前路由模式、DNS 设置与本地入口端口。
- 测试范围：先测一条配置和一个目标，再检查需要直连的私有网络地址是否仍按预期处理。
- 日志记录：保存内核启动信息与首条相关错误；分享日志前隐藏订阅令牌、用户 ID 和密钥。
- 恢复条件：若新配置无法启动或关键应用无法使用，先恢复原配置，再单独核对不兼容字段。
归纳起来，Project V 说明技术来源，V2Fly 与 Xray 说明内核的发展路线，三款客户端说明在哪个平台管理连接。实际选型只需回到三个问题：设备装什么、服务端要求什么、运行时真正加载了什么。需要进一步设置入口与分流时，可接着阅读入门指南或配置进阶。