XDRIVE transport: The first remote-storage-service-based proxy, ignoring IP whitelists

[RPRX]

2021 年初的想法（IP 白名单），和 REALITY 的想法同一时期（SNI 白名单），去年在频道提过一嘴，现在该给俄罗斯、伊朗上了

新传输层 XDRIVE，第一个利用正经远程存储服务的代理（Google Drive、OneDrive、Yandex Disk 等网盘，S3 stores、FTP 等）

当然也可以兼容不正经的，比如伊朗能用的 ChatGPT，甚至改个用户名也算，此前有个利用 AMP 缓存的 Champa，不过速度就

优点是能过 IP 白名单，毕竟理论上任何网站都可以被“滥用”，且不需要自有公网 IP，两个大内网机器都能代理，内网穿透拉满

如果服务自带境内外同步，或服务在境内但境外能访问到也行，此时客户端的连接甚至不会过墙，其实 jsDelivr 也行不过不妥吧

缺点是权限管理要谨慎，因为要在客户端填密钥，最好只拿来自建，如果拿这种东西开机场那很有想法了，以及看不到客户端 IP

目前的代码只是搭了个基础框架并把 #5581 (comment) 的代码 copy 了过来，接下来几天再做整合，如果谁有空替我写完也行

暂时三个参数：远程文件夹、服务名、密钥列表，还有发包间隔、大小限制等也会加，这个也能上下行分离走不同的服务/权限

Donation & NFTs

Collect a Project X NFT to support the development of Project X!

• TRX(Tron)/USDT/USDC: TNrDh5VSfwd4RPrwsohr6poyNTfFefNYan
• TON: UQApeV-u2gm43aC1uP76xAC1m6vCylstaN1gpfBmre_5IyTH
• BTC: 1JpqcziZZuqv3QQJhZGNGBVdCBrGgkL6cT
• XMR: 4ABHQZ3yJZkBnLoqiKvb3f8eqUnX4iMPb6wdant5ZLGQELctcerceSGEfJnoCk6nnyRZm73wrwSgvZ2WmjYLng6R7sR67nq
• SOL/USDT/USDC: 3x5NuXHzB5APG6vRinPZcsUv5ukWUY1tBGRSJiEJWtZa
• ETH/USDT/USDC: 0xDc3Fe44F0f25D13CACb1C4896CD0D321df3146Ee
• Project X NFT: https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1
• VLESS NFT: https://opensea.io/collection/vless
• REALITY NFT: https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/2
• Related links: VLESS Post-Quantum Encryption, XHTTP: Beyond REALITY, Announcement of NFTs by Project X

[Fangliding]

34847 KB → 37301 KB

[RPRX]

34847 KB → 37301 KB

这依赖项看得我也麻了，你研究一下咋替换成简单实现吧，不然每支持一个服务都要多引入一套 SDK

[RPRX]

我打算每 500ms 新建一个文件，服务端会读取 10s 内新创建的文件并删掉 10s 以前的文件，两端的 idle timeout 也为 10s（由于强制使用 mux，连续 10s 收不到对方的数据包的概率极低），且我自己不打算使用 Google Drive 去测试，而是使用本机文件系统测试，写一个 interface 具有登录、上传、查询列表、下载、删除功能，与网盘 API 的整合则交给你们去实现

[RPRX]

@Fangliding 此外我收到了一份烧火棍版 Google Drive API 代码，预计不会引入现有这些依赖项

[Meo597]

OpenList 有一大堆云盘的实现，甚至还有逆向的
@j2rong4cn

[RPRX]

https://t.me/projectXray/4635055 如果觉得支持多个网盘麻烦可以考虑参考一下rclone的代码，它支持很多网盘协议后端，而且是go写的，开源协议友好，可以拿来直接用

https://t.me/projectXray/4635057 那我直接 import

我先把本地的写好吧，还没开始写就是说

[RPRX]

群里有一个致力于帮助土库曼斯坦的俄语群友提到了 domain fronting（任意 SNI 但目标网站只看内层 HTTP host），我突然觉得 XDRIVE 有大用处，因为众所周知除了 fastly 外绝大多数 CDN 是不支持这个的，但是其它网站基本上都有默认证书且只看内层 HTTP host，XDRIVE 将只自动填写 HTTP host，连接目标为 address，且使用 TLS 处填的 SNI、verifyPeerCertByName、是否 h3 等

这下完美融入 Xray-core 的框架了

[RPRX]

我都把计划写得这么详细了剩下的交给 AI 试一下，先让它写个基于本机文件系统的 XDRIVE

[RPRX]

#5654 Claude Opus 4.5 写的还真像那么回事，等我 deVibe 一下

[RPRX]

这 GitHub 刚刚改版了导致我顶格写的 PR description 每一行都超出一两个字

[RPRX]

https://t.me/projectXtls/1505 AI 还没有看到后面我写的“不正经用法”，我再解释下：

1. 绝大多数网站支持 domain fronting（CDN 一般只支持同一个账号下的），再加上大站都有 anycast 提供了合理性，也就是说比如即使 SNI www.googleapis.com 被封，你使用 www.google.com 作为 SNI 也能连上，审查者看不到内层 HTTP host 所以无法阻断连接，除非封掉整个 IP，附带伤害拉满
2. 绝大多数网站的 TLS 配置，若 SNI 不存在于服务器上则会返回“默认证书”，也就是说你甚至可以使用 www.example.com 作为 SNI，然后 verifyPeerCertByName，审查者需要实时维护一份庞大、精确的 IP-SNI 列表才能封掉这种方法（CDN 的话只有少数比如 fastly 支持这种任意域前置）
3. XDRIVE 理论上可以利用任何网站而不止是“正经远程存储服务”，比如伊朗能用 ChatGPT，那么完全可以把流量 base64 后作为草稿写入、另一端读取，所以审查者搞 IP 白名单已经没用了，想要封掉 XDRIVE 只能完全断外网

[RPRX]

Local 不只是示例吧我觉得，网盘客户端基本上都自带“本地文件夹多端同步服务”，XDRIVE 的想法最初也是由此启发，这也意味着不一定需要 API 且可以“滥用”几乎所有网盘，只是延迟可能会有十秒