ToiCF/CF-Workers-TGProxy

选用指南

AI 根据 README 整理 · 2026/10/17 05:40:50

使用方式

部署为 Cloudflare Worker，通过 WebSocket 代理中继，客户端需配置为使用该代理。

查看 README 依据

# CF-Workers-TGProxy Cloudflare Workers 的 Telegram Web/MTProto WebSocket 代理中继（KWS Lanes）。 [`telegram_webproxy.js`](./telegram_webproxy.js) 是一个单文件 Cloudflare Workers 实现：它扮演 Telegram 官方 Web Proxy（td web-proxy）后端，把客户端（Desktop / Android）在隔离 webview 里发起的 WebSocket lanes，直接转接到 **Telegram Web K 自己的 KWS 通道**（`kws{dc}[-1].web.telegram.org/apiws`）。 它不再依赖一套独立的 MTProxy / middle proxy 后端：Worker 在本地解开客户端 MTProto 传输层的 obfuscation，再用自己生成的随机密钥重新封一层，拨 Telegram 官方的 Web K 入口。内层 MTProto 载荷始终由客户端端到端加密，Worker 不接触、也不做 mtp 层加解密。 ## 核心能力 当前代码主线包含：

`openssl rand` 走系统 CSPRNG，是真随机。任一绑定缺失，`mkCfg` 直接抛错，`/health` 会返回 `500` 而不是 `{"ok":true}`。 ## 路由 | 路径 | 方法 | 说明 | | --- | --- | --- | | `/` | `GET` / `HEAD` | 校验 bridge 签名后下发 web-proxy 页面 | | `/health` | `GET` | `{"ok":true}` | | `/api/v1/session` | `POST` | 建会话，返回 session token | | `/api/v1/session` | `DELETE` | 注销会话 | | `/api/v1/ws` | `GET` | lane WebSocket（需 `Upgrade` 与正确子协议） | ## 文件 | 文件 | 说明 | | --- | --- | | [telegram_webproxy.js](./telegram_webproxy.js) | Worker 主实现：页面 / session / lane / obfuscation / KWS 中继 | ## 访问优化（CNAME / SaaS 优选）

部署要求

需要 Cloudflare Workers 环境，并配置 SECRET 和 BOOT 密钥绑定。

查看 README 依据

| KWS 端点 | Telegram Web K 出站 | `kws{1..5}[-1].web.telegram.org/apiws` | ## 密钥配置 | 绑定 | 意义 | 要求 | | --- | --- | --- | | `SECRET` | 代理密钥：AES-CTR 传输密钥派生 + `?bridge=` 能力签名 | `32` 位 hex，或 `dd` / `ee` / `ef` 前缀 + 32 位 hex（共 `34`）；字符集 `0-9a-f`；大小写不敏感，建议小写 | | `BOOT` | bootstrap token：签发 bootstrap / session，并内联进下发页面 | 仅要求非空，建议 ≥ `16` 字符随机串 | 生成命令： | 目标 | 命令 | 输出 | | --- | --- | --- | | `SECRET` | `openssl rand -hex 16` | `32` 位 hex | | `SECRET`（带前缀） | `printf 'dd%s\n' "$(openssl rand -hex 16)"` | `34` 位 hex | | `BOOT` | `openssl rand -hex 24` | `48` 位 hex |

已知限制

作者指出性能提升为理论推断，非实测；且依赖官方域名，第三方线路可能导致错误。

查看 README 依据

> 以下为基于当前代码路径的**理论模型**（标记 `[推断]`），不是本仓库的实测基准。 - **数据面加解密量下降**：相对"经 middle/MTProxy 转发"的路径，本实现每包只做一次 obfuscation（AES-CTR，128-bit 计数器）重签，而不是在代理侧再承担 mtp 层的加解密。数据面 AES 块操作量约降到一半量级 `[推断]`。 - **少一跳 RTT**：去掉自建中转服务器，客户端 → CF 边缘 → Telegram KWS。`[推断]` - **小包汇聚**：上行 `upPack = 20KB`、下行 `dnPack = 32KB` + `1ms` 观察窗，把高频 tiny frame 压成更少的实际写入。复用 GrainTCP 同一颗 grain 核，其本地回放实测区间为 **1.8x–39.8x**（固定 512B 风暴下约 39.8x，mixed 小包约 1.8–2.0x）。 - **单 isolate 承载**：单会话最多 128 条 lane，无需把整条会话钉在单个 Durable Object 上。 综合到瓶颈场景，理论提升从 **约 2x 起**（仅算加解密 + 去跳），小包风暴场景在汇聚部分叠加后可更高。`[推断]` ## 设计重点 ### 1. 多 lane 直接替代 Durable Object

- 使用**自有域名 + CNAME**，或直接走 Cloudflare **SaaS（自定义主机名）优选**，以获得更好的接入体验。 - 参考实现中曾出现第三方线路（非官方 `web.telegram.org` 域名）导致边缘层 `1034` / `403`；换成官方 web 域名后恢复正常，因此**优先使用 Telegram 官方 web 域名与稳定的自有 CNAME / Custom Domain**，避免依赖质量不稳定的中间线路。 ## 相关链接 - 开源协议：[GPL-3.0](./LICENSE) - 频道 / 交流群组：<https://t.me/Enkelte_notif> - Telegram Desktop（tdesktop）：<https://github.com/telegramdesktop/tdesktop> - Telegram Android（DrKLO）：<https://github.com/DrKLO/Telegram> - Telegram tproxy-server：<https://github.com/telegramdesktop/tproxy-server> ## Stargazers over time