常见现象：代理开着，Telegram 却一直「正在连接」

在中文检索里，Telegram 正在连接 代理、Clash Telegram 分流这类组合非常常见。用户往往已经能正常浏览网页，却在桌面端或手机里看到会话列表灰掉、顶部状态长时间转圈。第一反应通常是「换节点」，但若节点本身可达，问题更常出在规则没有把整个 Telegram 生态一起送进同一个可信出口，或应用有一部分流量绕开了你以为是全局的那条路径。

与站内《Discord UDP 与域名分流》相比，Telegram 的痛点不完全一样：Discord 语音更突出 UDP 与 WebSocket 对齐；Telegram 客户端则大量依赖短链域名 t.me、telegram.org 系主机名，以及到数据中心（DC）的长连接。界面卡在「正在连接」，很多时候并不是「完全没网」，而是鉴权、拉取配置、媒体与信令中某一环命中了 DIRECT 或被前置规则截断，导致握手完不成。

下文默认你使用 Clash Meta / mihomo 系内核与图形客户端；DNS、Fake-IP、规则优先级等通用背景，请与《Clash YAML 配置深度解析》对照阅读。若你在一开 TUN 就出现整机路由异常，请先完成《Windows 下 TUN 与防火墙排查》，再回来微调 Telegram 专用规则，避免把「系统层问题」误判成「应用域名漏配」。

MTProto 在排障里到底指什么

搜索 MTProto 规则 时，容易和两个概念混在一起：一是 Telegram 自带的 MTProto 代理（MTProxy） 服务，那是另一种接入方式；二是客户端与官方数据中心之间使用的 MTProto 传输协议。在 Clash 里你通常无法也不需写一条名叫「MTProto」的魔法规则去「识别协议」，而是要用 DOMAIN / DOMAIN-SUFFIX、维护良好的 rule-providers，或在确有依据时补充 IP-CIDR，让目标主机名与地址落到你为 Telegram 预留的策略组上。

实务上的结论是：把「MTProto 稳定」翻译成「Telegram 相关域名与 DC 出口一致」。当 SNI、解析结果与规则顺序不一致时，就会出现「偶尔能上、多数时候转圈」的假性随机故障，排查时务必以连接日志为准，而不是凭感觉改节点。

域名与场景：别只记一个 t.me

t.me 是高频入口：分享链接、登录跳转、部分 Web 场景都会碰到。但仅写 t.me 往往不够。桌面端还会访问 telegram.org、desktop.telegram.org、核心文档与更新域名等；移动端与网页版也会引入 cdn、sticker、emoji 相关子域。若你只给浏览器做了分流，而 Telegram 可执行文件走系统代理或 TUN 的另一条分支，就会出现Web 能打开、客户端仍断连的割裂。

更稳妥的流程是：在问题复现时打开客户端连接记录，把实际出现的主机名与目标端口记下来，再沉淀为「TELEGRAM 策略组」下的多条后缀规则。对大多数用户，使用可信来源的 GEOSITE / rule-provider 分类比自己维护一长串 IP 更省力；IP 段会随运营商调度变化，手工 IP-CIDR 需要持续维护，只适合能自行验证的场景。

YAML 示意：独立策略组 + 规则顺序

下面是一段示意性配置，用于说明「独立策略组 + 域名规则」如何拼接；具体域名是否仍由官方使用、是否与你订阅中的规则重复，请以本地日志与远程规则集为准增删，勿机械搬运：

proxy-groups:
  - name: TELEGRAM
    type: select
    proxies:
      - YOUR-STABLE-NODE
      - PROXY

rules:
  - DOMAIN-SUFFIX,t.me,TELEGRAM
  - DOMAIN-SUFFIX,telegram.org,TELEGRAM
  - DOMAIN-SUFFIX,telegram.me,TELEGRAM
  - DOMAIN-SUFFIX,tdesktop.com,TELEGRAM
  - DOMAIN-SUFFIX,telesco.pe,TELEGRAM

rules 自上而下匹配，先命中的规则胜出。Telegram 相关条目通常应放在广告拦截与国内直连之后、过宽的 GEOIP 或 MATCH 之前。若你把「全局代理」写在很后面，而前面有一条宽泛的 DIRECT 把某些后缀提前放行，客户端就会表现为长时间连接中。若使用 rule-providers，请同时注意策略引用是否指向 TELEGRAM 组，而不是默认的 PROXY。

TUN、系统代理与端口：什么时候必须上 TUN

仅依赖「系统 HTTP 代理」时，一部分应用仍可能让某些连接绕开代理栈，尤其在桌面端。若你已确认域名规则无误，但日志里仍能看到 Telegram 进程在奇怪的路径上 DIRECT，可以尝试在可接受的环境下启用 TUN / 虚拟网卡类增强模式，让更多三层流量进入内核决策。与此同时要检查：防火墙是否放行、是否与其他 VPN 抢路由、以及规则里是否无意对 UDP 走了 DIRECT。

Telegram 的语音与通话场景也会用到 UDP，虽然许多用户的首要问题是「根本连不上」，但一旦进入媒体通道，UDP 是否与 TCP 对齐到同一策略组仍会决定体验。可与 Discord 一文中的「同一条出口」思路类比：目标是减少「信令走节点、媒体却本地直连」的分叉。安卓用户若使用分应用策略，请同时核对《Clash Android 分应用代理》中的系统勾选与配置文件是否表达同一意图，避免半代理状态。

验证：用连接日志对齐「以为自己配好了」

排障时请不要只用「能不能打开 t.me 网页」作为唯一标准。更值得做的是：在复现「正在连接」时观察日志里 Telegram 相关条目是否全部命中 TELEGRAM（或你命名的等价组）；是否出现意外的 DIRECT；是否在切换 TUN 前后，UDP 与 TCP 的命中分布发生明显变化。若只有部分子域命中，通常就对应「登录环过了、数据中心握手没过」一类问题。

同时请关闭浏览器里只代理部分站点的扩展、避免与其它代理客户端争抢系统代理。局部改写会让规则命中看起来「随机」，让你误以为是 YAML 写错或节点「质量差」。

合规与账号安全

Telegram 的服务条款、自动化行为与地区政策因账号类型与使用场景而异。本文仅讨论本地网络路径与 Clash 配置的技术思路，不提供规避服务条款或违法用途的操作指引。请在你有权使用的网络环境与账号前提下操作，并自行承担合规与账号风险。

结语

Telegram 正在连接在 Clash 语境里，多数是域名与规则顺序没有覆盖完整链路，或TCP/UDP 与系统代理路径没有对齐，而不是单纯「换一个更快的节点」就能解决。为 Telegram 单独建策略组、显式包含 t.me 与 telegram.org 等核心后缀，并在需要时用 TUN 把会话纳入同一隧道，通常比盲目堆规则集更有效。把「MTProto」理解成「客户端到 DC 的一整条可信路径」，排障会清晰很多。

相比在论坛零散搜报错文案，用一款能看清规则命中与连接日志的客户端会省大量时间。若你希望与教程保持同一套界面习惯，可从客户端下载页获取当前系统对应版本；更多主题见博客索引。→ 立即免费下载 Clash，开启流畅上网新体验