Xray-core v26.11.9 来了,XDRIVE 把 Google Drive 变成了传输层

本文依据 Xray-core 官方发布页与 PR #7352 整理,XDRIVE 的速度与延迟数字来自上游,未经本站实测。先说最关键的一句:这是一次公开测试,不是稳定功能,客户端与服务端版本必须相同,近期还可能有 breaking change。

XDRIVE 是什么:Google Drive 当传输层

XDRIVE 是 Xray-core 新加的一种传输层,后端可以是 Google Drive。它的核心卖点写在 PR #7352 里:

  • 服务端不需要公网 IP,可以放在境外家宽里;
  • 对外是真实的 Google IP,SNI 是 www.google.com,走 h2/h3,用 Chrome 155+ 指纹;
  • 除了 Google Drive,还支持 local、template、s3 这类后端,比如 Yandex Disk,但上游原话是这些后端尚未深度优化。

上游在 PR 里把话说得很满,称 XDRIVE 是“核武级别的更新”,理由是俄罗斯、伊朗这类地方也能用 Google——伊朗即使在今年最严时期仍有一个 Google IP 可用。这句是上游的说法,本文只转述,不替它背书。

部署前必须知道的几件事

按 PR #7352 的清单:

  1. 版本:至少用今天发布的 v26.11.9,近期还可能有 breaking change,客户端与服务端的版本必须相同;
  2. 搭配:为了减少文件数、确保安全,必须搭配 VLESS Multiplex+Encryption,mux.cool 的最小并发已被改成 128;
  3. 账号:建议用一个新的 Google 账号,并妥善保管 Google Drive 相关密钥;
  4. 分享:暂无分享链接,近期会探索适合分享的方案——也就是说现在还不适合把节点分给别人用;
  5. 搭建指南:PR 里附了一份官方搭建指南 PDF(XDRIVE with Google Drive setup guide v26.11.9.pdf),按那份走,别按网上二手教程。

VLESS Encryption 的设计能保证即使把节点分享给他人,客户端之间也无法知道别人访问了什么——这是 PR 里的原话,分享方案本身还没出来,这句先当作设计目标看。

速度与延迟:上游的说法,未经本站实测

这一节的数字全部来自上游 issue #7208 的评论,本站没有跑过:

  • 隧道建立需要几秒,之后 RTT 约 1.5 秒,主要受限于 Google Drive 单次写入耗时 600–800 毫秒;
  • 经过多轮优化,速度已经可以跑满普通家宽上限;
  • 连接数方面,考虑到 Google Drive 的 h2 策略,XDRIVE 默认对它开四条连接,h3 则为一条,可以手动改 XMUX 调整连接数。

RTT 1.5 秒这个数看着吓人,但它说的是隧道本身的往返,不是你每次打开网页的延迟——即便如此,XDRIVE 现在也不是为低延迟准备的,更像是在“能上网”和“不能上网”之间二选一时的方案。等本站实测过再补实测数,本文不替上游的数字背书。

先别急着当主力:公开测试阶段的提醒

上游自己列的风险,一个都别跳过:

  • 长时间连接 Google、h2/h3 实现、Google Drive 响应模式,都是潜在特征,可能会被针对或限速;
  • www.google.com 只是一个可选的 SNI,也可以填其他 Google SNI 或者干脆不做域前置,这有助于分散特征;
  • 账号与密钥的保管是自己的事:新账号、密钥别乱放,丢了就是丢了。

同版其他改动

v26.11.9 不只有 XDRIVE,发布页之外的改动按提交记录列在这里:

  • 默认指纹改为 Chrome 155+,uTLS 库也更新了;本版 uTLS 依赖在发布前还调整过一次,先切到 XTLS fork 注册 hellochrome_155,随后又临时切回官方版——最终默认指纹以发布页口径为准,细节若有出入以后续版本为准;
  • mux.cool 默认最大并发改为 128、最大复用次数改为 1024,主要是为 XDRIVE 服务;同版还给 mux.cool 加了 MutexWriter,避免并发写底层连接;
  • TUN 入站在 Windows 上配不好 IPv6 时,改为记日志而不是直接退出;
  • Geodata 支持下载 .dat.gz;
  • WireGuard 代理端点查询加上 deadline,查不到就放弃,不一直等。

注意区分:mux.cool 的 MutexWriter 和 #7336 的 VisionWriter 加锁是两回事,别混淆——后者见下一节。

和 #7335 泄漏修复的关系:没有关系

顺带说一句,免得有人升完级就以为泄漏修好了:v26.11.9 里没有 #7335 真实 IP 泄漏的修复,修复提交 4c6093c8 既不在这一版里,也不在当前 main 里;#7337 的改动在 PR 页面上显示已合并,但当前 main 代码里没有那几行加锁。详情见本站那篇VLESS Vision 拒掉 UDP 443 后真实 IP 泄露了怎么办,规避办法还按那篇来。

升级前核对清单

动手之前先跑下面这条,确认自己现在到底是哪个版本:

1
/usr/local/bin/xray version

再对照两件事:

  1. 面板用户先对照面板捆绑版本:3x-ui 最新稳定版 v3.11.0 捆绑的是 Xray-core v26.10.21,不是 v26.11.9,面板里显示的内核版本以面板实际捆绑的为准,不要把 v26.11.9 当成面板已经带上的版本;
  2. 要用 XDRIVE 就升到 v26.11.9,客户端与服务端一起升,别只升一端。

用官方一键脚本升级的命令,本站已有文章里写过,沿用官方脚本的标准用法(本文作者未在本地实测):

1
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

升级完再跑一遍 xray version,确认版本号确实变成了 v26.11.9,再重启服务让新版本生效。

依据来源