Xray-core 是代理平台：一个 Go 程序用 JSON 描述入站、路由和出站。它不是 VPN 协议。截至 2026-10-11，GitHub Latest 是 v26.3.27；标签 v26.10.10 被标为预发布。本文只核对边界和协议名字，不提供配置，也不讨论报文外观。

Xray 是什么

一个可独立引用的定义句：Xray-core 是 Project X 维护的代理平台，用同一份 JSON 格式描述客户端或服务端角色下的入站、路由与出站。

仓库描述写着 “An open platform for various uses”，同一句里还有与 v2ray-core 比较的宣传用语。宣传句不是本文的结论。文档首页把 Xray 和 XTLS 分开说：XTLS 是他们研究的一组 TLS 想法，Xray 是他们维护的实现。

和它经常被混在一起的几件事：

说法文档或仓库里的对应事实
它是一种新的 VPN 协议项目是平台。某种隧道可以是其中一种入站或出站
装了某个图形程序就等于核心本身README 把图形程序列在核心之外。本文没有审核那些名单
支持某个协议名就具备该协议的全部性质核心「会说话」和这条连接在具体网络里的表现是两件事
它自带节点或账号官方仓库不提供节点列表，也不是接入服务

代理和 VPN 各改哪一层，见 HTTP 代理与 VPN 有何不同 与 SOCKS5 与 VPN 有何不同。

仓库、分叉点与版本标签

下列事实来自 2026-10-11 读取的 GitHub、文档站和 v2fly 上的那一次提交。

项目可核对的记录
代码仓库XTLS/Xray-core，创建于 2020-11-09。GitHub 不把它标成 fork
组织XTLS，创建于 2020-09-19，显示名是 Project X Community
文档xtls.github.io
模块路径github.com/xtls/xray-core
v1.0.0发布于 2020-11-25。README 的 Credits 写明，这一版从 v2fly-core 提交 9a03cc5 分出
该提交的内容2020-11-20 的一次依赖版本更新，不是一份「宣布分叉」的说明
GitHub Latestv26.3.27，2026-03-27，prerelease 为 false。该标签的 go.mod 写 go 1.26
更新的标签v26.10.10，2026-10-10，prerelease 为 true。该标签的 go.mod 写 go 1.27

v1.0.0 的发布说明写过「配置上完全兼容」。2026-10-11 的文档首页改成另一句：最初源自 v2ray-core，但已经长期独立演进，不应再视为完全兼容的替代品。两句都来自项目，适用的年份不同。

文档配置页的警告是：文档与最新 release 同步；一键脚本常安装 GitHub 标记为 Latest 的版本，而 Latest 有时不是最新 release。因此「文档站上的字段」和「本机 xray 的版本」要以所装标签为准，不能互相代替。

文档首页对「我们是谁」的回答是：是谁并不重要。本次读取的贡献计数里，RPRX 为 428，yuhan6665 为 210，其后还有其他账号。计数会变，也不是职务名单。

许可证

仓库 LICENSE 是 Mozilla Public License 2.0 全文。GitHub 的 SPDX 标识是 MPL-2.0。文档首页也写 MPL 2.0。

MPL 2.0 的结构是：对 Covered Software 的修改要以同一许可证提供源码；把这些文件放进更大的作品时，更大作品的其他文件可以使用不同条款。这是许可证文本里的区分，不是对项目的评价。

LICENSE 末尾附有 Exhibit A 和 Exhibit B 的模板。模板出现在许可证全文里，不等于每一个源文件都加了 Exhibit B 的 “Incompatible With Secondary Licenses” 声明。本文没有逐文件核对。

README 另有一段再分发说明：Windows 的 ZIP 里可选地带有官方预编译的 Wintun，版权属于 WireGuard LLC，许可证是其预编译二进制自己的 PBL，只在 Windows 的 TUN 入站被加载时使用。那是第三方组件，不是 Xray 的 MPL 覆盖了 Wintun，也不是 Xray 等于 WireGuard。

架构：一份 JSON 里的角色

2026-10-11 的配置引言把配置写成 JSON，并写明客户端与服务端的格式没有区别，差别在内容。该页列出的顶层名字包括 env、log、api、dns、routing、policy、inbounds、outbounds、stats、fakedns、metrics、observatory、burstObservatory、geodata、version。这些是分区名称，不是一份可以照抄的样例。

四个分区说明它为什么叫平台：

  • Inbound：连接从哪里进来。可以是本机代理端口、虚拟网卡，或某一种服务端协议。
  • Outbound：连接往哪里走，包括直连、丢弃、环回，以及某一种客户端协议。
  • Routing：按规则把连接送进某个出站。
  • DNS：有自己的处理路径。DNS 出站文档写明，它只接收路由送来的传统明文 DNS（UDP 或 TCP），不适用于 DoH、DoT、DoQ。加密 DNS 的概念见 DoH/DoT 与 VPN DNS。

虚拟网卡如何接管系统流量，见 TUN 全局代理是什么。那是操作系统接口，不是一种 IETF 隧道。

2026-10-11 文档索引里的协议名字

下表来自当天文档站的入站索引与出站索引。文档站声明与最新 release 同步，因此这张表不一定等于 GitHub Latest（v26.3.27）的二进制。

入站索引：Tunnel、HTTP、Shadowsocks、Socks、Trojan、VLESS、VMess、WireGuard、Hysteria、TUN。

出站索引：Blackhole、DNS、Freedom、HTTP、Loopback、Shadowsocks、Socks、Trojan、VLESS、VMess、WireGuard、Hysteria。

其中一部分是公开标准，一部分是各项目自己的协议，一部分只是核心内部的动作：

类别索引中的例子规范或文档落在哪里
本地代理入口Socks、HTTPSOCKS 第 5 版见 RFC 1928；HTTP 代理常用 CONNECT，语义见 RFC 9110
逻辑出站Freedom、Blackhole、Loopback、DNSXray 自己的配置模型。Freedom 首段把它写成直连并终结流量；Blackhole 首段写成阻碍全部出站数据；Loopback 首段写成送回路由
既有隧道WireGuard用户态实现。文档首段写：把收到的 TCP 和 UDP 转成核心内部的代理请求。协议本身见 WireGuard 与 OpenVPN
本项目重点的代理协议VLESS、VMess见下一节。二者都没有 IETF RFC
其他已列出的协议Trojan、Shadowsocks、Hysteria各有自己的项目。索引只说明「这一版文档列了这个类型」

Tunnel 页写明：旧称 dokodemo-door，监听本地端口并把收到的数据经出站送到指定地址，用于端口映射。v26.3.27 与 v26.10.10 的源码树都仍有 proxy/dokodemo 目录。本文没有逐版本核对二进制接受的协议字符串是否已经从旧名改成 tunnel。

v26.10.10 的 proxy/ 下还有 masque 目录。当天的入站、出站索引都没有 MASQUE。本文不能把它写成已对用户开放的协议名。

Shadowsocks 在索引里是一项。v26.10.10 的 shadowsocks.go 会按方法字符串改走 shadowsocks_2022 包。这是实现内的分支，不是索引上的第二个协议名。本文没有核对 2022 版方法的规范文本。

Hysteria 同时出现在协议索引和传输索引里。入站页的提示是：协议本身无认证，users 只在搭配 hysteria 传输层时生效。这是页面上的边界，不是配置步骤。

传输与安全：只记录名字

传输索引在同一天列出的传输方式是：RAW、XHTTP、mKCP、gRPC、WebSocket、HTTPUpgrade、Hysteria。传输安全列出 REALITY 与 TLS。附加配置里还有 FinalMask 与 Sockopt。

同一文档树里还存在 h2、http、quic、tcp、splithttp 等页面，它们没有全部出现在上述索引中。v26.3.27 的 transport_internet.go 在解析 network 时接受的名字包括 raw/tcp、xhttp/splithttp、kcp/mkcp、grpc、ws/websocket、httpupgrade、h2/h3/http、quic、hysteria。索引、页面文件和某一个标签的源码不是同一份清单。

同一文件里，security 接受空字符串、none、tls、reality。值为 xtls 时返回「已移除功能」的错误，错误文本指向 xtls-rprx-vision。本文不解释这些名字在报文外观上的做法。

文档首页把 VLESS、XTLS、XUDP、XHTTP、REALITY 并列称为原创协议，并用「流量伪装」描述其中一部分。那些页面讨论外观、回落和识别。本文不转述。XUDP 只出现在这句并列里，本文没有另开它的规范页，因此不描述它的报文。

VLESS 与 VMess 在文档里各是什么

VLESS 入站页的定义是：无状态的轻量传输协议，分成入站和出站，作为客户端与服务器之间的桥梁；与 VMess 不同，它不依赖系统时间；认证方式同样为 UUID。该页警告：除对端是私有地址且链路处于受信网络，或已启用该页所称的 VLESS Encryption 之外，必须配合传输安全层。Encryption 的算法本文没有展开。

VMess 入站页的定义是：加密传输协议，通常作为客户端与服务器之间的桥梁。该页要求系统 UTC 时间误差在 120 秒以内，并写明与时区显示无关。时间偏差如何影响依赖时间的握手，见 系统时间不准时 VPN 为何握手失败。如何对时不在本文范围。

两个名字都只表示文档列出了这个类型。它们没有统一的 RFC。

文档里的典型角色

这些是程序角色的描述，不是选型建议：

  • 本机客户端：应用或虚拟网卡进入核心，再由路由选择出站。
  • 服务端：用某一种入站接受对应协议。同一个二进制可以担任这一侧，差别在配置，不在另一份软件。
  • 直连或丢弃：Freedom 与 Blackhole 是出站类型，不是新的隧道协议。

它不包含账号、计费或节点运营。图形界面是否调用了这个核心，要以该客户端自己的说明为准。README 罗列了一批第三方程序，本文没有核实，因此不转述名单。

文档首页还把 Splice 写成降低转发开销的手段。本文没有做性能测试，也不把这句话当成测量结论。

和相关项目差在哪

差别指的是项目边界，不是高下。

项目官方材料里的重心与 Xray-core 的边界
Xray-core代理平台一份 JSON 覆盖入口、路由、出口和 DNS
v2fly/v2ray-core分叉来源v1.0.0 的起点是其中一个提交。现行文档拒绝「完全兼容替代品」这个说法
sing-box另一个通用代理平台同样使用 JSON 风格的入站、出站与路由，字段和协议重心并不通用。见 sing-box 是什么项目
WireGuard一种隧道协议可以是 Xray 的一种入站或出站，协议规范不属于 Xray
strongSwan 等 IKE 实现IKE 与 IPsec协商的是 IPsec 安全关联，不是多协议代理核心

读版本时先分开的四件事

  1. 安装的是 GitHub Latest（2026-10-11 为 v26.3.27），还是某个标了预发布的更新标签，或文档站当天的页面。
  2. 某个名字出现在入站、出站还是传输。Hysteria 在两类索引里都有；Tunnel 的旧名仍留在源码目录里。
  3. security 的 xtls 在 v26.3.27 源码里已被拒绝。文档首页仍把 XTLS 当作一组想法的名字。
  4. 图形程序是第三方客户端还是核心。核心版本以该程序实际调用的二进制为准。本文没有逐个客户端核对。

本文只整理公开资料。在中国大陆，提供或使用代理软件还受电信管理和具体服务条款约束；这里不讨论如何绕过管理措施。

主要资料