TG2Cloud：Telegram 文件自动转存到网盘，支持 CloudDrive2 与 OpenList

项目来源与致谢

TG2Cloud 基于 whyhhh20/TG115 二次开发，感谢原作者和贡献者提供的开源基础。项目沿用 MIT 许可证，并保留原有版权信息。这里介绍的是在该基础上继续完善的 TG2Cloud，而不是把原项目包装成从零开发的作品。项目来源与许可可参见仓库说明和许可证。

项目仓库 · 部署器下载 · 详细使用说明 · 版本发布说明

本文根据 2026 年 9 月 21 日可查的仓库文档和 TG2Cloud v1.0.2 发布说明整理。后续版本的界面、命令和默认配置可能变化，请以对应 Release 为准。文中的传输耗时为明确假设下的估算，不是实测成绩。

一、为什么需要 TG2Cloud？

在 Telegram 中收到一份需要保存的资料，传统操作往往是：先下载到手机或电脑，再打开网盘上传，最后检查文件是否传完。

偶尔处理一个小文件，这样并不麻烦。但当文件变多，或者遇到体积较大的视频、压缩包时，重复下载、上传和清理临时文件，就会变成一件需要反复盯着的事情。

TG2Cloud 想简化的，就是这个过程：

你负责选择文件，并转发给自己的 Telegram Bot；后续的排队、传输和任务管理，由 VPS 上的服务处理。

按照项目工作原理，它的基本链路是：

1
2
3
4
5
6
7
8
9
10
11

在 Telegram 中选择文件
          ↓
转发给自己的私人 Bot
          ↓
TG2Cloud 在 VPS 上接收并排队
          ↓
通过 rclone 写入 WebDAV
          ↓
CloudDrive2 或 OpenList
          ↓
自己挂载的目标云存储

这里最需要说明的是：“自动转存”不是“自动监听频道”。

当前版本处理的是你与 Bot 的一对一私聊中提交的文件，不会自动扫描频道历史，也不会在群组或频道出现新文件后自行抓取。它更适合“自己挑选、后台处理”的个人文件归档场景，而不是全频道采集。

同样，它不是绕过服务器传输的“网盘秒转”接口。文件仍然需要经过相应的网络链路，VPS 的性能、线路和流量都值得关注。

二、从 TG115 到 TG2Cloud，重点变在哪里？

从名字看，TG115 很容易让人认为它只服务于 115 网盘。TG2Cloud 则把“接收 Telegram 文件”和“连接目标存储”分成了更清楚的两部分。

115 仍是重要的测试和文档示例，但不再应该被理解为唯一目标。 具体能用哪个网盘，要看你在 CloudDrive2 或 OpenList 中实际挂载的存储，以及该存储是否具备项目需要的 WebDAV 操作能力。发布说明也明确保留了这一边界。

可以选择两种存储网关

当前提供 CloudDrive2 Edition 和 OpenList Edition。两版都承担 Telegram 文件转存任务，但连接云存储的组件不同，使用各自独立的部署器。

已经配置好 CloudDrive2 的用户，可以继续沿用熟悉的管理方式；已经在使用 OpenList，或者准备通过 OpenList 挂载存储的用户，也有相应入口。

这不是“必须同时安装两个组件”，更不是“任何网盘都已经验证可用”。

Windows 上操作，VPS 上运行

部署器采用 PySide6 图形界面，负责连接 VPS、检查资源、部署服务和打开管理页面。真正执行文件任务的是 VPS，而不是本地 Windows 程序。

对不想从头拼接 Docker、Bot 和 WebDAV 配置的用户来说，这种方式减少了手工操作。不过，登录自己的网盘、完成授权以及配置存储权限，仍然要由本人完成。新手说明对自动完成和人工完成的部分做了区分。

不只是上传，还要能管理任务

TG2Cloud 使用持久化队列保存任务，并提供状态查询、暂停调度、失败重试和诊断入口。它还会结合资源和目的端情况调整任务调度，而不是不看磁盘剩余空间就不断启动传输。

这些能力的意义不在于保证“永远不出错”，而在于出错以后仍有状态可查、有任务可重试、有数据保护措施。具体能力可参见项目说明。

为小硬盘提供流式选项

普通模式会先把文件完整下载到 VPS，再上传到 WebDAV；超过本地任务预算的单文件则可以走流式管道，避免在 Bot 下载目录里保存完整副本。

但需要记住两个区别：任务恢复不等于任意传输都能断点续传，流式传输也不等于零磁盘占用。 流式任务中断后通常需要从头重试，CloudDrive2、OpenList 自身的缓存也不受 Bot 本地任务预算直接控制。使用说明和项目边界说明均提示了这些限制。

三、CloudDrive2 版和 OpenList 版怎么选？

可以先看自己更熟悉哪套存储管理工具，再选相应部署器，不需要一开始就把两版都装上。

表中的本地地址通过部署器建立的 SSH 隧道访问，并不是要求把管理端口直接开放到公网。两版的目录和运行资源相互隔离，但也不应让多个实例长期共用同一个 Bot Token。版本与部署说明、使用说明

选型时还需要确认第三方工具自己的使用条件：TG2Cloud 开源，不代表 CloudDrive2 的所有功能、网盘的所有权益以及 VPS 资源都免费。CloudDrive2 的会员和功能规则、各网盘的授权要求，应以相应官方说明为准。第三方组件说明

四、部署之前，需要准备什么？

1. 一台可以稳定连接 Telegram 的 VPS

项目给出的个人使用参考配置是 2 核 CPU、4GB 内存、50GB SSD，推荐系统包括 Ubuntu 22.04/24.04、Debian 12 的 64 位版本。批量使用可以参考更高配置，但最终要看部署器对当前机器的检查，而不是只看购买页面上的硬盘总容量。部署准备清单

VPS 还需要可用的 root 或 sudo 权限，能访问 Telegram、Docker 镜像仓库以及目标存储相关服务。选择 CloudDrive2 版时，另外确认 /dev/fuse 可用；OpenList 版不依赖它。使用说明

不要把 50GB 推荐磁盘，误读为随时都有 50GB 可用于临时文件。 系统、镜像、日志、备份和存储组件的缓存都会占空间。项目默认的本地任务预算与磁盘保留线，也应在检测后按实际情况应用。

2. 四项 Telegram 信息

创建 Bot 的官方说明见 Telegram Bot 教程；API ID 和 API Hash 的申请步骤见 Telegram 应用创建说明。登录 my.telegram.org 后进入 API development tools，按官方要求填写应用信息即可。

项目部署参数中的数字 ID 用于私聊鉴权。Bot Token、API Hash 等应作为敏感配置保管，不要放进博客示例、公开截图或 GitHub Issue。安全政策

3. 可用的存储账号和 WebDAV 配置

目标网盘需要有足够空间，并能在所选网关中正常挂载。TG2Cloud 使用的是你为它单独配置的 WebDAV 用户，而不是直接让你把网盘登录密码交给部署器。

可以这样区分：

1
2
3
4
5

网盘登录、扫码或 OAuth 授权
    → 在自己的 CloudDrive2 / OpenList 后台完成

WebDAV 用户名、密码和目标路径
    → 与 TG2Cloud 部署配置对应

OpenList 驱动要求的 Cookie、Token 或 OAuth 授权，也应在自己的 OpenList 中处理，不是填写到 TG2Cloud 的 Telegram 页面。项目对这些凭据的处理范围可参见发布说明。

五、Windows 图形化部署流程

下面按首次安装整理。详细页面说明可对照仓库部署文档和新手使用说明。

第一步：下载对应的部署器

进入 GitHub Releases，下载需要的 Edition，以及同一版本发布的 SHA256SUMS.txt。

可以在 Windows PowerShell 中计算文件 SHA-256。按自己下载的版本选择一条执行：

1
2
3
4
5

# CloudDrive2 Edition
Get-FileHash ".\TG2Cloud-CloudDrive2-Deployer.exe" -Algorithm SHA256

# OpenList Edition
Get-FileHash ".\TG2Cloud-OpenList-Deployer.exe" -Algorithm SHA256

把结果与 Release 提供的校验值比较。v1.0.2 的 EXE 未提供商业代码签名，可能出现“未知发布者”提示；应核对下载来源与文件校验值，而不是为了运行程序直接关闭系统安全防护。发布说明

第二步：填写 VPS 信息，测试 SSH

在部署器中填写服务器地址、SSH 端口、用户名，并选择密码或私钥登录。非 root 用户根据实际情况补充 sudo 信息，然后点击“测试 SSH”。

首次连接时应核对主机密钥指纹，确认连接的是自己的服务器。测试成功后，查看部署器给出的 VPS 资源结果和存储建议。部署文档

特别是小硬盘 VPS，不要跳过检测，直接照搬其他人的任务预算。

第三步：填写 Telegram 参数

输入 Bot Token、API ID、API Hash，以及本人 Telegram 数字 ID。

这些参数的用途不同：Bot Token 指向机器人，数字 ID 决定允许使用它的人。不要把 Bot 的数字 ID、用户名或聊天名称误填成自己的用户 ID。部署文档

第四步：按所选 Edition 配置存储

方案 A：CloudDrive2 Edition

使用部署器在同一台 VPS 上管理 CloudDrive2 时，WebDAV 地址保持默认的 Docker 内网地址：

1

http://tg2cloud-clouddrive2:19798/dav

预先确定一组专用 WebDAV 用户名和密码，稍后在 CloudDrive2 中创建同一组凭据。部署器中填写的不是 CloudDrive2 会员登录密码。

检查存储预算后，执行“一键部署基础环境”。部署成功后点击“打开 CloudDrive2 管理页”，通过 SSH 隧道进入后台，完成网盘挂载、开启 WebDAV，并创建专用用户。

该用户需要读取、写入、改名和删除权限，不能保持只读。目标路径只配置一次，例如：

这里的 115open 只是示例挂载名称，请按自己的目录替换。不要在两处重复填写同一段路径。上述地址、权限与路径规则见CloudDrive2 配置说明。

方案 B：OpenList Edition

OpenList 版也先填写 VPS 和 Telegram 信息，再检测资源、部署基础环境。首次初始化时，界面会提供初始管理员密码；请妥善保管，已有 OpenList 实例不会因为重新部署而自动改用新生成的密码。

基础部署成功后，点击“打开 OpenList 管理页”，通过 http://127.0.0.1:5244 进入后台。由本人添加目标存储、完成授权，并创建与“配置 WebDAV”页面一致的专用普通用户。

为该用户设置合适的基本路径，授予目录列表、读取、创建／写入和删除能力。目标子目录留空时，文件写入该用户对应的 WebDAV 根目录；需要子目录时，再填写 Telegram 之类的相对路径。

v1.0.2 的 OpenList 版不依赖 WebDAV MOVE 改名来完成最终写入。 它采用预留目标名称后直接写入的方式，不能照搬 CloudDrive2 的临时文件改名流程。OpenList 部署说明、v1.0.2 发布说明

第五步：完成 WebDAV 验收，再测试真实文件

基础环境“部署成功”，只说明相关服务已经达到基础健康要求，不等于网盘配置已经正确，也不等于文件能够正常上传。

完成挂载和用户权限设置后，执行“WebDAV 验收”，检查是否出现：

1

TG2CLOUD_DESTINATION=OK

这个验收会通过 Bot 的实际配置测试远端文件操作。通过后，再向 Bot 私聊发送一个小文件，确认任务完成，并到网盘官方客户端检查大小和可打开性。验收说明

发布说明记录了两版的真实 VPS 基础部署和 WebDAV 验收情况，但 Telegram 端到端传输、不同文件规模以及不同网盘组合，仍需在自己的环境中验证。v1.0.2 发布说明

建议先完成小文件与一个常用大小文件的测试，再逐步增加任务量，而不是刚装好就提交大量大文件。

六、部署完成后，平时怎么用？

日常操作可以概括为：转发文件、查看任务、按需处理失败。

先在 Telegram 私聊自己的 Bot，发送 /start 或 /help，再把需要保存的文件转发过去。任务受理后，使用 /queue 查看排队情况，使用 /status 查看系统与传输状态。

以下是当前文档列出的常用命令：

123 是示例任务编号，应替换为 Bot 返回的实际编号。完整语义以Bot 命令说明为准。

特别注意：/pause 暂停的是后续调度，不会立即打断已经开始的传输；/cancel 不是单纯把一条记录从列表隐藏，而是可能删除该任务对应的远端文件和本地副本。对已经需要保留的文件，不要随手执行取消。

“Bot 完成”应该怎样理解？

这是整个项目里最容易误解的一点。

TG2Cloud 能确认的是：所选 WebDAV 目的端已经接收文件，并通过项目执行的大小检查和相应收尾流程。 它没有接入所有上游网盘的官方完成接口，因此不能把这个状态直接解释成“网盘官方端已确认永久保存”。

同样，大小一致不是文件内容哈希一致。首次使用、更换存储后，或者备份重要资料时，仍应通过网盘官方客户端检查文件；重要文件还可以在下载后自行比较哈希。项目边界说明、安全政策

这并不意味着每个任务都要额外输入一次确认命令。当前版本已经不要求逐个执行人工确认；只是不能把自动显示的完成状态夸大成项目没有提供的保证。

七、转存速度怎么样？2GB 文件要多久？

不能只根据“VPS 是千兆带宽”，就判断一份文件肯定能在几分钟内传完。

对于这套链路，至少要区分三段：

1
2
3

Telegram → VPS
VPS → CloudDrive2 / OpenList WebDAV
CloudDrive2 / OpenList → 目标网盘

其中某些环节可能通过缓存衔接。WebDAV 接收得快，不一定代表上游网盘也已经以相同速度完成写入。项目状态说明和安全政策明确限制了 Bot 能确认的范围。

一个仅用于估算的例子

假设文件为 2GB，按十进制约 2000MB 计算，某一个传输阶段能持续保持固定的有效速率，不考虑排队、校验和重试，那么：

1

单阶段耗时 ≈ 文件大小 ÷ 该阶段有效速度

这张表不是 TG2Cloud 的实测速度，也不是端到端耗时承诺。

例如，普通模式下，假设 Telegram 下载持续为 5MB/s，之后写入 WebDAV 持续为 2MB/s，那么这两个串行阶段合计约需：

1
2

2000 ÷ 5 + 2000 ÷ 2 = 1400 秒
约 23 分 20 秒

此外还可能有排队、检查、重试，以及存储网关向上游网盘继续同步的时间。

流式模式能够让部分处理环节重叠。在稳定、理想的流水线模型中，总速度仍受最慢环节限制，不能靠“边下边传”消除网盘或网络本身的瓶颈。

更有参考价值的测试方法

建议用同一个测试文件，分别记录任务提交、开始下载、Bot 完成和官方客户端可正常打开的时间，同时观察 /status 中的来源下载、WebDAV 上传和流式送入指标。状态字段说明

这样至少能分清：时间主要花在 Telegram 下载、写入网关，还是后续云端处理，而不是把所有慢都归因于 TG2Cloud。

选择 VPS 时，也应留意流量计费方式。文件经过服务器传输，服务商可能只计出站，也可能同时计算入站和出站；具体以购买套餐规则为准。部署准备清单

八、几个常见问题，集中回答

Q：没有 Telegram Premium，也能使用吗？

A： 项目的部署准备项并没有把 Telegram Premium 列为前提，而是要求 Bot Token、API ID、API Hash 和本人数字 ID。因此，不应把“没开会员”直接等同于“不能部署”。但具体文件能否发送、转发和读取，仍受 Telegram 的规则与实际条件影响；项目也没有承诺解锁文件大小限制或保证固定下载速度。部署准备

Q：是不是只支持 115？

A： 不是。115 是常用示例和重要测试场景，实际目标由你在 CloudDrive2 或 OpenList 中挂载的存储决定。不过，“能挂载”和“适合通过该项目上传”不能完全画等号，还需要验证认证、目录、写入、检查及清理能力。不能据此宣传所有网盘都已全面兼容。发布说明

Q：部署完成后，本地电脑需要一直开着吗？

A： 文件任务运行在 VPS 上，正常运行时不依赖 Windows 部署器持续开启；服务器和相关服务需要保持可用。关闭部署器后，本地管理页面使用的 SSH 隧道不应视为持续可用，再次管理时需要重新建立连接。这是部署器与服务端分工带来的区别。运行与部署说明

Q：流式传输是不是完全不占硬盘？

A： 不是。它减少的是 Bot 为单个文件保存完整下载副本的需求，不代表容器、系统、日志及存储网关没有磁盘占用。尤其不要忽略 CloudDrive2 或 OpenList 自身的缓存。仍然要保留安全空间，也不能把流式模式当成绕过磁盘检查的手段。资源与流式说明

Q：文件传输失败，会自动接着传吗？

A： 需要区分任务状态与文件传输进度。持久化队列有助于重启后恢复任务管理；普通模式上传失败时，可以保留已经下载的完整本地文件。但流式模式通常没有完整副本，中断后往往需要从头传输，不能笼统宣称“任何失败都支持断点续传”。先查看 /task 编号，再按实际状态重试。任务与边界说明

Q：Bot 一直排队，是不是程序卡住了？

A： 不一定。排队可能与磁盘安全线、资源情况、目标目录不可用或 WebDAV 配置不正确有关。先查看 /status 和 /doctor，确认网盘挂载、凭据和权限，再执行 WebDAV 验收。不要一看到排队就重装，也不要盲目提高并发。排错说明

Q：遇到 401 或 429，应该怎么处理？

A： 先区分原因。401 应优先检查运行中的 WebDAV 凭据是否与网关用户一致；429 则应关注限流，避免连续重复验收加重问题。修改界面里的密码，不等于运行中的服务已经采用新密码，需要按部署或配置更新流程应用，再验证当前状态。“修复 CloudDrive2 网络”也不能代替凭据修正。排错说明、v1.0.2 更新说明

Q：VPS 重装以后，为什么 SSH 密码正确却仍然连不上？

A： 可能是服务器主机密钥变化，而不是密码错误。部署器会显示旧、新指纹；应先通过服务商控制台核对当前服务器身份，确认变化合理、指纹一致，再选择“更新并重新连接”。不要为了省事清空全部主机记录，也不要在原因不明时接受新指纹。SSH 排错说明

Q：项目开源，是不是整个使用过程都免费？

A： TG2Cloud 按 MIT 许可证开源，但 VPS、网盘容量和第三方软件的权益是不同的事情。是否需要为某项功能付费，要看你选择的服务及其当前规则。开源说明的是项目许可，不能替代所有上游服务的使用条件。许可证、第三方组件说明

九、日常维护与升级，注意这几个边界

查看运行状态和日志

使用默认目录部署 CloudDrive2 版时，可以在 VPS 执行：

1
2
3
4
5
6
7
8
9
10
11

# 查看运行状态
sudo /opt/tg2cloud-clouddrive2/manage.sh status

# 查看近期 Bot 日志
sudo /opt/tg2cloud-clouddrive2/manage.sh logs

# 检查当前配置与基础运行情况
sudo /opt/tg2cloud-clouddrive2/manage.sh check

# 执行真实 WebDAV 验收，会创建并清理测试文件
sudo /opt/tg2cloud-clouddrive2/manage.sh verify

OpenList 版使用自己的管理脚本路径：

1

/opt/tg2cloud-openlist/manage.sh

自定义过安装位置的，应换成实际路径。相关命令以运维说明为准。

升级程序，不要误解 update

项目建议使用新版 Windows 部署器重新执行基础部署来升级程序。对于识别到的既有 TG2Cloud 实例，重新部署默认保留当前配置；只有明确选择覆盖配置时，才应用相应表单内容。

manage.sh update 不会自动从 GitHub 下载最新 TG2Cloud 代码。 它主要使用 VPS 已安装的程序资源重建服务，因此不能把它当成从任意旧版升级到最新源码的通用命令。运维与升级说明

另外，“有升级前备份”不等于“有一键恢复所有数据”。v1.0.2 没有正式自动 Restore 或 Uninstall；两版备份覆盖的内容也不同。升级前应确认自己保存了哪些配置和状态，不要把程序备份当成云端文件备份。发布说明

旧 TG115 用户，不能直接按同目录升级

TG2Cloud v1.0.2 不提供旧 TG115 的自动原地迁移。新项目使用独立目录、容器和网络，不会自动接管旧安装。

建议先处理旧任务、保存必要数据和配置，再安排新实例部署；验证新链路之前保留旧环境和私有备份。复用同一 VPS 时，还要人工处理旧实例对固定管理端口的占用。

不要让新旧实例长期使用同一个 Bot Token 同时运行。 有旧目录，并不代表新部署器会自动导入旧队列；简单改名目录也不是可靠迁移方式。详细步骤应对照从 TG115 迁移说明执行。

十、安全与使用范围

自托管让你能够自行控制部署位置和访问入口，但并不意味着没有安全风险。

不要公开 Bot Token、API Hash、WebDAV 密码、SSH 私钥、网盘 Cookie 或 OAuth Token。提交问题前应对日志和截图脱敏；配置备份也可能包含凭据，不能当作普通附件公开分享。安全政策

CloudDrive2 是第三方专有组件，其内部上传逻辑不属于 TG2Cloud 的源码审查范围，受管部署还涉及较高的容器权限。用于个人文件转存的环境，应尽量与重要业务隔离，管理端继续通过受控的 SSH 隧道访问，而不是为方便直接开放到公网。第三方组件说明、部署安全说明

请仅转存自己有权保存、备份和使用的内容，并遵守相关平台规则。这里讨论的是个人文件管理与自动化，不是绕过内容权限、复制限制或服务限制。

写在最后

TG2Cloud 的价值，并不是承诺“无限速”“零成本”或“任何网盘都能秒传”，而是把选择文件之后的一串重复操作，整理成一套能够查看状态、管理队列和处理失败的流程。

对已经使用 Telegram、又希望把资料归档到自己网盘的人来说，这是一种值得了解的自托管方式：入口还是熟悉的聊天窗口，执行任务的是自己的 VPS，存储则由自己选择和授权。

先让一个小文件完整走通，再测试日常会用到的文件规模。相比一次提交大量任务，先确认每一段链路都符合预期，往往更有助于判断这套方案是否适合自己。

项目与下载入口：LuoPoJunZi/TG2Cloud。 再次感谢 whyhhh20/TG115 原作者及相关开源组件的贡献者。

参考资料

本文的功能、部署和运维说明主要依据 TG2Cloud 项目文档、v1.0.2 发布说明、新手使用说明、迁移文档、安全政策及第三方组件说明。Telegram 凭据申请步骤参考其官方文档；耗时计算为本文基于已写明假设的算术估算。

文档核对日期：2026 年 9 月 21 日。本文不替代实际环境验收，也不将仓库记录的验证范围扩大为所有云存储和文件规模的兼容保证。