打开全局模式,Telegram 立刻恢复正常;切回规则模式,消息又开始转圈。这个反复横跳的现象几乎每个用代理的人都遇到过,而它指向的问题很具体:流量没有被规则匹配到代理里去,不是节点出了毛病。
从现象倒推:哪些可能性已经被排除
全局模式的含义是「所有流量无条件走节点」。既然这种情况下 Telegram 能用,那么下面这些就都不是原因:
- 节点本身可用,线路通畅;
- 订阅有效、账号没有欠费或超流量;
- 客户端的核心转发功能工作正常;
- 系统代理已经正确接管了流量。
问题只剩下一处:规则模式下,Telegram 的流量被判定成了「直连」。
Telegram 的流量为什么难匹配
大部分应用的网络行为是:先解析域名,再连接解析出来的 IP。分流规则靠域名就能拦住。Telegram 不完全是这样。
它的消息通道使用自研的 MTProto 协议,数据中心地址在客户端内部维护,连接时经常直接向固定的 IP 段发起请求,不走一次公开的域名解析。这意味着:
- 你写的
DOMAIN-SUFFIX,telegram.org这类规则,在消息通道上根本没有触发的机会; - 流量落到规则列表末尾的兜底条目上,而多数配置的兜底是「直连」或「按 GEOIP 判断」;
- GEOIP 数据库把这些地址归到境外,但如果你的兜底策略写的是直连,一样会漏。
另一个容易被忽略的点是:Telegram 里的图片、视频、文件下载走的是另一套 CDN 地址,和消息通道未必是同一条路径。所以会出现「文字消息能收,图片一直加载不出来」的半通状态。想理解规则匹配的基本机制,可以先看看分流规则的说明。
三分钟定位:到底漏了哪一类流量
在动手改配置之前,先用下面这张表对一下自己的具体表现,能少走弯路。
| 你观察到的现象 | 大概率原因 | 优先补哪类规则 |
|---|---|---|
| 消息完全发不出,一直转圈 | MTProto 通道走了直连 | Telegram 的 IP 段规则 |
| 文字正常,图片视频加载不出 | 媒体 CDN 走了直连 | 媒体相关域名 + IP 段 |
| 桌面端正常,手机端不行 | 两端配置文件不同 | 检查手机端用的是哪份配置 |
| 偶尔能用,过一会又不行 | 规则命中不稳定或存在多条冲突条目 | 检查规则顺序和重复条目 |
| 全局也不稳定 | 不是规则问题,是节点或线路问题 | 转去查节点连通性 |
最后一行值得单独说一句:如果开全局之后仍然时好时坏,那这篇文章的方向就不对了,应该按连接成功但无法上网的思路去查转发链路。
补规则的正确顺序
第一步:加 IP 段规则。 这是最有效的一步。在客户端的规则列表里,新增针对 Telegram 已知 IP 段的条目,策略指向你的代理组。IP 段规则不依赖域名解析,能直接覆盖消息通道。多数机场提供的官方配置里已经有这组规则,如果你用的是自己拼的配置或第三方规则集,漏掉的可能性很大。
第二步:确认规则的位置。 规则是自上而下逐条匹配的。如果你的配置里在前面有一条很宽泛的直连条目,新加的 Telegram 规则排在它后面就永远轮不到执行。把新条目提到规则列表的靠前位置,是很多人改完规则「没效果」的真正原因。
第三步:补进程规则。 桌面端客户端通常支持按进程名分流。给 Telegram 的可执行文件加一条进程规则,策略指向代理,可以把这个应用产生的所有连接一网打尽,包括那些你没预料到的地址。这条规则在 Windows 和 macOS 上都很实用,是应对「地址会变」类应用的稳妥做法。
第四步:处理媒体流量。 如果文字能收但图片打不开,再补上媒体 CDN 相关的域名和 IP 段。这一步单独做,是为了让你知道到底是哪一类规则起了作用。
第五步:重载配置并重启 Telegram。 客户端重载配置只影响新建立的连接,Telegram 后台已有的长连接会继续按老路径走。必须彻底退出应用再打开,否则你看到的还是旧行为。
不同客户端的落地方式
Clash 内核的客户端在配置文件的 rules 段里增删条目,格式统一,改完在界面上点重载即可。如果你用的是机场订阅链接下发的配置,注意订阅更新会覆盖手改内容,应该用客户端提供的「覆写」或「自定义规则」功能来保留修改。导入和管理配置的细节见 Clash 订阅导入与基础配置。
Shadowrocket 在「配置」里编辑规则,也支持按 IP 段和域名添加。移动端没有进程规则的概念,所以 IP 段规则更关键。具体操作路径参考 Shadowrocket 订阅导入教程。
sing-box 系客户端用的是路由规则集的写法,可以直接引用现成的规则集文件,比手写 IP 段更省事,也更容易跟着上游更新。
还有一类特殊情况:开启了 TUN 模式之后表现和之前不一样。TUN 会在系统层接管流量,原本靠系统代理漏出去的连接现在也被接管了,规则的影响范围随之扩大。切换 TUN 前后建议各测一次,便于判断问题到底出在哪一层。
怎么确认真的修好了
别只看「消息发出去了」这一个信号,建议做完整的三项验证:
- 关掉全局,切回规则模式,发一条文字消息,确认秒到;
- 发一张图和一个文件,确认上传下载都正常,这一步验证媒体通道;
- 打开一个国内网站,确认速度正常,说明你没有为了修 Telegram 而把国内流量也扔进代理。
第三项是很多人忽略的自检。有些人「解决」问题的办法是把兜底策略从直连改成代理,Telegram 确实通了,但代价是所有未匹配流量都绕道境外,日常访问变慢、流量消耗成倍上升。
仍未解决时,准备这些材料
如果 IP 段规则、进程规则都补齐了还是不通,再去找机场客服,并带上:
- 客户端名称和版本号,以及配置来源(机场官方订阅 / 第三方规则 / 自己编写);
- 规则模式下的失败表现,以及全局模式下的对照结果;
- 你添加的规则条目原文,和它在规则列表里的位置;
- 客户端连接日志里,Telegram 尝试连接时对应的那几行记录,重点看策略字段显示的是代理还是直连;
- 是否只有 Telegram 有问题,其他需要代理的服务是否正常。
最后一条很关键。如果多个应用都要靠全局才能用,那说明整份配置的分流策略有系统性问题,不是单独给 Telegram 打补丁能解决的,更合理的做法是换回机场提供的官方配置做一次对照。