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 的清单:
- 版本:至少用今天发布的 v26.11.9,近期还可能有 breaking change,客户端与服务端的版本必须相同;
- 搭配:为了减少文件数、确保安全,必须搭配 VLESS Multiplex+Encryption,mux.cool 的最小并发已被改成 128;
- 账号:建议用一个新的 Google 账号,并妥善保管 Google Drive 相关密钥;
- 分享:暂无分享链接,近期会探索适合分享的方案——也就是说现在还不适合把节点分给别人用;
- 搭建指南: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 |
再对照两件事:
- 面板用户先对照面板捆绑版本:3x-ui 最新稳定版 v3.11.0 捆绑的是 Xray-core v26.10.21,不是 v26.11.9,面板里显示的内核版本以面板实际捆绑的为准,不要把 v26.11.9 当成面板已经带上的版本;
- 要用 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,再重启服务让新版本生效。
依据来源
- Xray-core v26.11.9 发布页(XDRIVE 公开测试、Chrome 155+ 默认指纹):https://github.com/XTLS/Xray-core/releases/tag/v26.11.9
- Xray-core PR #7352(XDRIVE 发布说明与优化、部署清单、安全提醒、搭建指南 PDF):https://github.com/XTLS/Xray-core/pull/7352
- Xray-core issue #7208(隧道建立耗时、RTT 约 1.5 秒、速度跑满家宽上限的评论):https://github.com/XTLS/Xray-core/issues/7208
- Xray-core issue #7259(Chrome 155+ 指纹暂未被 TSPU 针对):https://github.com/XTLS/Xray-core/issues/7259
- 本站已有文章:Xray-core v26.10.31 紧急安全更新:https://vpsjq.com/2026/11/01/xray-core-v26-10-31-mptcp-security-update/
- 本站已有文章:VLESS Vision 拒掉 UDP 443 后真实 IP 泄露了怎么办:https://vpsjq.com/2026/11/06/vless-vision-udp443-real-ip-leak/