Telegram Desktop 停在「连接中」？Clash TUN、进程分流与 telegram 域名逐步修复
很多人装好 Clash 以后，浏览器立刻恢复可用，但 Telegram Desktop 仍长时间停在「连接中」：头像转圈、会话列表不全，甚至出现只能收发文字、图片与语音加载异常。底层往往是 MtProto 与 UDP 没有被正确送进代理策略，再加上系统代理对原生桌面客户端覆盖不全。本文用 Clash TUN 作为统一捕获点，结合 PROCESS-NAME / PROCESS-PATH 与 telegram.org、t.me 等域名规则，对齐 DNS / fake-ip 与规则顺序，给你一条可复现的排查路径；并与站内 Discord 语音 UDP 等场景互补。
典型现象：不止「连不上」这么简单
同一台机器上，浏览器访问境外站点正常，但 Telegram Desktop 的表现却拆成几种层次：
- 长时间「连接中」：顶部状态像在读秒，会话不同步或顺序错乱。
- 退化到「仅能文字」：文字能进出，贴纸、图片、语音与视频圆环一直转圈——往往说明部分 HTTPS/CDN 通了，但媒体或大 UDP 流仍走错出口或被丢弃。
- 间歇性「假在线」：偶尔刷出新消息，下一秒又回到卡顿——多与节点抖动、DNS 分裂或多条 MtProto 路径争抢有关。
这类问题不是换一个节点名字就能一劳永逸；应先确认流量是否真的进了 Clash，再谈节点质量。桌面客户端不像 Chromium 那样乖乖读系统代理变量，许多路径会直接走系统路由——这正是为什么 TUN 模式几乎总是桌面电报排查的第一步。
为什么仅靠「系统代理」常常治不好 Telegram Desktop
Clash 在 Windows / macOS 上默认可以把 HTTP(S) 系统代理配好，浏览器和部分 Electron 应用会跟随；但 Telegram Desktop 的数据通道大量依赖自有协议栈与 UDP，不一定走你设的 PAC 或 localhost 端口。结果是：你以为的全局规则从未命中电报进程，日志里看不到一行 Telegram，客户端却在底层直连或被防火墙半路掐断。
TUN（虚拟网卡）把拦截点前移到内核转发路径附近，让「不听话」的二进制流量仍经过 Clash/Mihomo——这与微信、游戏启动器等场景一致。开启 TUN 后，才有机会对进程级特征做分流，并在同一捕获点上观察 UDP、DNS 与最终策略名。
心智模型
先回答「电报进程有没有被 TUN 看见」，再回答「命中了哪条规则、走了哪个策略组」。这两层叠在一起，才能区分路由问题与单纯节点不可达。
若你尚未完成客户端侧基线配置，请先按平台对照：《Clash for Windows 安装与配置》（含订阅与模式切换）、macOS 图形客户端可参考 《Clash Verge Rev macOS 首次配置》，确保 Meta / Mihomo 内核与 Network Extension / 管理员权限就绪后再往下调 Telegram。
MtProto、UDP 与「仅能文字」之间的关系
Telegram 使用自家的 MtProto，桌面端往往依赖多条 TCP 与 UDP 会话共同完成同步、语音通话与媒体传输。若策略层只代理了若干 HTTPS 域名，而未覆盖数据中心 IP、UDP 端口或备用接入点，就容易出现文字勉强可用、富媒体全挂的症状——这与「UDP 被直连进黑洞」或「走了错误的 GEOIP 兜底」是一个家族的问题。
在 DPI 较重或运营商对 UDP 不友好的地区，电报还可能频繁切换接入方式；此时固定一条过于狭窄的域名表反而会成为绊脚石：你需要的是可持续更新的 rule-providers，外加进程级兜底，而不是把某个静态列表当圣经。
合规提示
请遵守所在地法律法规与 Telegram 服务条款。本文仅讨论你有权配置的设备上的网络工程问题，不涉及绕过监管的不当用途。
进程分流：PROCESS-NAME 与 PROCESS-PATH
在 Clash Meta（Mihomo）系内核中，常见的进程规则可以让你显式指定 Telegram 二进制走哪个策略组，而不必猜测后台具体连到了哪个 CDN 主机名：
- Windows：可执行文件通常为
Telegram.exe（路径因安装来源略有差异）。 - macOS：多为应用包内的二进制名
Telegram；若存在多个副本或测试通道，优先用PROCESS-PATH精确到.app路径。
把电报进程指向稳定的代理策略组（例如你的「常用代理」组），并在其后保留细致的域名规则与 GEOIP，可以避免「一条粗暴 MATCH 误伤其它软件」。若同名进程多开或便携版路径怪异，请打开客户端连接日志，核对进程名列后再写入规则——拼写必须与系统任务管理器一致。
与 Steam / Epic、Discord 语音等场景类似，进程规则应放在过于宽泛的 GEOIP 或最终 MATCH 之前，否则永远轮不到 Telegram。若你对 UDP 语音类场景也在排查，可交叉阅读 《Discord 语音与 UDP 延迟》，对照中继节点与 TUN 叠加时的日志读法。
telegram.org、t.me 与规则集：域名层怎么补齐
仅有进程规则有时仍不够：电报还会拉起网页预览、Bot API、CDN 与推送通道，主机名会随版本微调。常见需要你显式分流或并入可信 rule-provider的片段包括（示意，实际以实现集为准）：
- 核心站点与短链：
telegram.org、telegram.me、t.me等。 - 网页版与资源域名：
web.telegram.org、各类静态资源与更新校验域名。 - 与你订阅规则集对齐的社交/即时通讯分类：避免重复定义冲突；导入第三方集合后务必检查优先级是否在本地覆写之下。
若使用 mixin 或本地片段覆盖远程订阅，请确认自定义行仍在合并后的列表前部，否则订阅刷新会把关键放行挤到 MATCH 之后——这与 《mixin 覆写远程订阅》一文所述思路一致。
DNS、fake-ip 与规则顺序：先对齐再谈换节点
TUN 会放大 DNS 行为差异：fake-ip 若与电报客户端期望的解析路径不一致，可能出现握手反复重试或偶发只能文字。建议在调整 Telegram 专用规则之前，先确认全局 DNS 策略没有结构性错误——可参考 《DNS 泄漏与 fake-ip 排查》，每次只改一个变量。
阅读日志时盯住三件事：进程名、目标地址与端口（尤其 UDP）、命中的规则类型与策略组。若日志里根本没有 Telegram，说明捕获点仍不对（TUN 未生效或被其它过滤驱动抢走）；若进程对了但策略是 DIRECT，就去上游找误匹配的域名或 GEOIP 行。
YAML 示意（务必替换策略组名并本机核对）
以下为教学示意：请把 PROXY 换成你的真实策略组名，并在 Windows「任务管理器」或 macOS「活动监视器」核对进程名与路径。
# Illustrative rules — verify process names on your OS
rules:
- PROCESS-NAME,Telegram.exe,PROXY
- PROCESS-NAME,Telegram,PROXY
- DOMAIN-SUFFIX,telegram.org,PROXY
- DOMAIN-SUFFIX,t.me,PROXY
- DOMAIN-SUFFIX,telegram.me,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
若同一策略组内仍有抖动，请在策略组层面启用合理的健康检查 URL、切换更适合长连接的节点类型（例如丢包敏感场景慎用过高延迟链路），并与服务商给出的 UDP 支持说明对照——这与单纯「抄一段域名」不是同一层面的优化。
DPI / 运营商场景下的现实边界
在部分网络环境中，即使 Clash 规则「逻辑正确」，仍可能出现握手被干预、UDP 被限速等现象——这不是客户端 YAML 能单方面承诺解决的。此时日志里常见间歇性超时或特定端口黑洞。工程上的做法是：保留可读日志、尝试不同接入节点地区、避免在同一时刻叠加多个未知过滤驱动；仍有疑虑时请转向本地网络与合规渠道排查。
常见问题
为什么只能发文字、图片一直转圈？
多半仍有媒体或 UDP 路径未命中代理策略，或 DNS 分裂导致 CDN 解析到不可达出口。先确认 TUN 与进程规则，再对照日志里的 UDP 命中记录。
网页版 telegram.org 能上，桌面端不行？
浏览器遵循系统代理而桌面客户端不一定。优先开启 TUN并用进程规则对齐 Telegram 二进制。
订阅更新后规则又失效？
远程订阅若覆盖了本地片段，Telegram 放行可能被挤掉。请用 mixin / profile 固定高优先级覆写。
实操检查清单
- 确认 Meta / Mihomo 内核与 TUN 在
Rule模式下可用。 - 在日志中核对 Telegram 真实进程名与连接维度（TCP/UDP）。
- 进程与关键域名规则放在过宽 GEOIP / MATCH 之前。
- 复查 DNS、fake-ip 与订阅合并顺序。
- 用「收发文字 + 拉一张图片 + 一次语音消息」联合验证。
从一款趁手的客户端开始
当你能把进程 → 策略 → DNS这条链路读清楚时，Telegram 只是众多桌面应用场景之一；同样的方法也适用于其它不完全遵循系统代理的原生软件。