Xray 内核与 V2Fly 内核差异:XTLS、REALITY 与配置兼容性

一、Xray 与 V2Fly：同源不等于配置通用

Project V 是围绕网络代理工具、协议与配置能力形成的项目生态，V2Ray 是其中的重要实现。V2Fly 社区继续维护 V2Ray；Xray 则在 2020 年从 V2Ray 代码基础分出，随后独立演进。因此，两者仍能看到相似的入站、出站、路由与 DNS 结构，但不能理解为同一个程序的两个名称。

内核承担实际连接工作：接收本地请求、选择出站、建立传输并完成协议交互。客户端负责界面、订阅管理、参数生成与进程控制。客户端能显示一个选项，并不代表当前启动的内核就能执行它；反过来，内核已支持的字段，也可能暂时没有对应的图形界面入口。

判断兼容性需要沿着这条链检查。分享链接能导入，只能证明客户端识别了链接格式；配置文件能加载，也只能证明语法和部分字段通过检查。只有实际建立连接、完成认证并收到目标站点响应，才能说明这条连接路径工作正常。

二、XTLS Vision 与 REALITY 分别解决什么问题

XTLS Vision 是 Xray 的流控能力，常见字段值为 xtls-rprx-vision。它针对代理连接中的 TLS 流量处理进行优化，在满足协议、传输与安全层组合要求时减少不必要的重复处理。它不是一个可以单独填写服务器地址使用的代理协议，也不是把任意节点提速的开关。

REALITY 是 Xray 提供的安全层方案，使用 TLS 握手机制并结合特定认证参数。它与普通 TLS 的配置和验证方式不同：客户端通常需要服务器名称、服务端提供的公钥材料、短 ID 等信息。常见 REALITY 部署不要求用户按普通 TLS 方式为代理入口配置自己的域名证书，但仍然依赖正确的目标站点、握手与认证设置。

Vision 和 REALITY 可以出现在同一个节点里，但不是同义词；Vision 也可用于受支持的普通 TLS 组合。较早资料中的其他 XTLS flow 名称，不能直接替换成 Vision。协议、流控、传输、安全层必须作为完整组合核对，具体支持范围还受两端内核版本影响。

三、配置对照：相同界面名称不代表相同 JSON

下面两张卡展示两种常见组合的核对点，不是可直接连接的节点。服务器地址、用户 ID 和认证材料应来自实际服务端配置。卡中的 /ws 是示例路径，只有服务端及反向代理也使用这个路径时才成立。

在常见 Xray 配置中，streamSettings.security 用于选择传输安全层，flow 则属于相应用户配置。两者不能互换。TLS 的服务器名称与 WebSocket 的 Host 虽然经常填写同一个域名，但一个参与 TLS 握手与证书验证，另一个属于 HTTP 请求信息，排障时应分别检查。

• 结构兼容：inbounds、outbounds、routing 等名称相似，不代表内部所有字段都相同。
• 协议兼容：VMess、Trojan、Shadowsocks 等常见支持也要落实到具体加密方法、传输组合与版本，不能只比较协议名。
• 版本兼容：V2Fly 的不同配置格式与 Xray 的字段演进各有变化。旧教程中的字段位置或名称，不应视为当前版本的固定接口。
• 资源兼容：使用 geosite:、geoip: 的路由规则，还需要相应数据文件与加载路径正确。

四、v2rayN、v2rayNG 与 v2flyNG 的内核关系

v2rayNG 是使用 Xray 内核的安卓客户端，v2flyNG 是使用 V2Fly 内核的安卓客户端。两者名称和部分界面相近，但不能把一种客户端导入成功的节点，直接视为另一种也能运行。尤其是 REALITY 与 Vision 节点，应先核对内核能力，再检查导入过程是否完整保留了参数。

v2rayN 是桌面客户端，界面与实际运行的核心程序需要分开理解。排障时以当前配置、启动日志和实际调用的内核为准，不能从客户端名称推断所有节点都通过同一种内核运行。菜单文字可能随桌面版本变化，记录设置时应同时记录所用客户端与内核信息。

1. 先确认客户端：在关于或版本信息页面记录客户端名称，不要只记录安装包文件名。
2. 再确认内核：查看启动日志中的内核名称与版本信息；若启动失败，先看配置解析错误。
3. 检查节点详情：逐项核对协议、传输、安全层、服务器名称和 flow，不只看节点备注。
4. 最后检查应用入口：安卓确认 VPN 连接授权与分应用设置，桌面确认应用使用的本地代理地址和端口。

五、迁移订阅与自定义配置：按层验证

订阅是配置分发方式，不是统一的内核配置标准。同一条订阅交给不同客户端后，可能经过不同的解析、字段映射与默认值补全。名称、地址和端口出现了，并不说明 REALITY 参数、流控或路由规则都已保留。迁移时先保留原客户端的可用配置，再在目标客户端中单独验证一个节点。

这两个端口分属不同连接阶段。远端入口可以使用其他端口，本地监听也可以修改；两者不需要相同。把浏览器代理指向远端的 443，或者把节点服务端端口改成本地的 10808，都不能修复内核不兼容。

1. 保存基线：记录一个已能连接的节点，保存原来的协议、传输、安全层及路由设置，敏感认证信息只留在本机。
2. 先验最小连接：暂不迁移复杂分流，先确认目标客户端能完成单节点连接。不要同时更换 DNS、路由和协议。
3. 核对导入字段：若源节点使用 Vision，检查 flow 是否仍为 xtls-rprx-vision；使用 REALITY 时核对服务器名称、短 ID 和公钥材料。
4. 恢复分流：逐条迁移路由规则，检查每个 outboundTag 是否对应已定义出站，并确认规则顺序。
5. 检查更新行为：手动刷新一次订阅，确认自定义修改是否被覆盖；长期调整应放在客户端提供的持久配置入口中。

服务器名称不能随意换成任意热门域名，REALITY 的公钥材料也不能由客户端临时生成后替代。它们都与服务端设置有关。遇到订阅缺字段，应先向配置提供方核对完整参数，而不是靠反复切换内核补齐。

六、报错定位：从解析、监听到远端握手

最有效的排查顺序是先看失败发生在哪一层。配置尚未解析成功时，测速和更换 DNS 都没有意义；内核正常启动却连接超时时，也不能仅凭超时就认定某个协议不受支持。以下报错片段只表示常见含义，实际日志措辞会随版本和操作系统变化。

临时提高日志详细程度可以帮助定位，但排查结束后应恢复常用等级。分享日志前删除服务器地址、用户 ID、订阅地址与认证材料。不要把关闭证书验证当作普通 TLS 的长期修复方案；证书链、服务器名称或系统时间存在错误时，应修正根因。

七、内核选择与常见疑问