Telegram 收不到消息？2026 年 10 月：小火箭 APNs 推送修复教程（附模块下载）

2026 年 10 月 23 日更新 · 阅读约 8 分钟 · 适用：iOS 小火箭 / Android

先说结论："收不到消息"绝大多数不是 Telegram 挂了，而是通知根本没送到你手机上。 iOS 上它走的是苹果的 APNs——Telegram 服务器先把通知发给苹果，苹果再投递到你手机，App 自己并不常驻后台。

国内网络下 APNs 相关域名时通时不通，再叠加小火箭的"智能分流"把 push.apple.com 判成国内直连，通知就没了。修复办法是：把 APNs 流量明确交给代理。下面这套流程来自开源项目 ios-push-fix，我按自己的理解重排了步骤、补了图和坑。

一、先分清是哪一种"收不到"

同样是"没消息"，原因完全不同，先对号入座：

• 锁屏没提示，进 App 才看到：通知链路断了（APNs / FCM / 后台保活），消息其实已经到了。
• 进 App 也没有，转圈很久才刷出来：网络没通，Telegram 连不上服务器。
• 只有部分聊天不提醒：会话被静音，或者设了"仅 @ 提醒"。
• 完全登录不上、一直转圈要验证码：账号或网络层问题，跟通知无关。

第一种最常见，也是本文的重点。

二、为什么偏偏是 iPhone 出问题

这是最容易被误解的一点：iPhone 上 Telegram 的推送，是 Telegram 服务器先发给苹果 APNs，再由苹果投递到你手机。 Telegram 自己并没有常驻后台的连接。

所以只要 APNs 这条路不通，Telegram 就"哑"了——哪怕你的节点速度很快、网页秒开。

常见的三种断法：

1. 规则把 APNs 走了直连。 很多配置默认只代理"被墙"的域名，push.apple.com 被判定为国内可直连，结果时通时不通。
2. DNS 污染 / fake-ip。 解析拿到脏 IP，连接超时，推送就丢了。
3. 切网时隧道重建。 从 Wi-Fi 切到蜂窝、或锁屏后系统回收 VPN，连接断掉。

对应的解法就一句话：别让"智能分流"去猜，直接把 APNs 交给代理。

三、四步修好（推荐：模块直链）

这套操作来自开源仓库 beibei030/ios-push-fix，模块本身只有 12 条规则，很轻。

第 1 步：在模块页新建

Shadowrocket → 配置 → 模块 → 新建模块。

没有"新建模块"入口的，先确认你用的是配置（不是"全局路由-代理"的简易模式）。

第 2 步：粘贴模块直链并保存

模块内容填下面这一行（这是 raw 直链，保存后小火箭会自动拉取并解析）：

https://raw.githubusercontent.com/beibei030/ios-push-fix/main/APNs_Push_Fix.sgmodule

如果直链拉不下来（国内 raw 域名偶尔抽风），就手动粘贴规则内容，效果一样：

#!name=APNs Push Fix
#!desc=修复 X/TG 收不到推送

[Rule]
DOMAIN-SUFFIX,push.apple.com,PROXY
DOMAIN-SUFFIX,akadns.net,PROXY
DOMAIN-KEYWORD,apple.com.edgekey.net,PROXY
IP-CIDR,17.249.0.0/16,PROXY,no-resolve
IP-CIDR,17.252.0.0/16,PROXY,no-resolve
IP-CIDR,17.57.144.0/22,PROXY,no-resolve
IP-CIDR,17.188.128.0/18,PROXY,no-resolve
IP-CIDR,17.188.20.0/23,PROXY,no-resolve
IP-CIDR6,2620:149:a44::/48,PROXY,no-resolve
IP-CIDR6,2403:300:a42::/48,PROXY,no-resolve
IP-CIDR6,2403:300:a51::/48,PROXY,no-resolve
IP-CIDR6,2a01:b740:a42::/48,PROXY,no-resolve

第 3 步：设置 → 隧道 → 打开 APNs

这一步最容易被漏掉。光有模块不够，还要在"设置 → 隧道"里把 APNs 开关打开。 只开 APNs 就行；如果还是收不到，把隧道里的开关全部打开再试。

第 4 步：飞行模式重置

规则生效需要系统重新注册推送：

1. 关闭 VPN；
2. 开飞行模式，等 1 分钟；
3. 关飞行模式，重新打开 VPN 和 Telegram。

然后锁屏放十分钟，让别人给你发一条消息。能亮屏弹出，就是通了。

四、备选方案：整份配置订阅

不想手动建模块的，可以直接把整套配置加为订阅（基于 cnip_ad 规则，已内置 APNs 修复）：

https://raw.githubusercontent.com/beibei030/ios-push-fix/main/sr_cnip_ad_pushfix.conf

Shadowrocket → 配置 → 添加 → 粘贴上面的地址 → 下载 → 使用配置。

注意两点：这份配置 2MB 左右，规则很全，会覆盖你现在的分流策略；如果你有自己的规则习惯，还是用第三节的模块方式更稳妥。

⚠️ 安全提醒：本文只逐行审阅了模块文件（12 条规则，干净）；这份 .conf 有 2MB、上千条规则，我没有逐行审阅，也无法为它担保。它是个人维护的开源项目，不是官方发布——导入前请自己打开原始文件扫一遍，或至少搜索 URL-REGEX、SCRIPT、REJECT 这类能改写流量走向的段落。配置类文件可以直接改变你的分流甚至劫持流量，这一步的谨慎不多余。

五、模块里到底改了什么

no-resolve 的作用是：命中 IP 段时不再做 DNS 解析，既省时间也避免 DNS 泄露。

六、Android：另一套逻辑

Android 上没有 APNs 这回事：

• 有 Google 服务且能连上 FCM 的机器，通知走 FCM；
• 国内没有 GMS 的机器，Telegram 会退回自己的后台长连接，这时候"系统把 App 杀掉"就等于"收不到消息"。

排查顺序：关掉电池优化（设置 → 应用 → Telegram → 电池 → 不受限制）→ 允许后台活动和自启动 → Telegram 内打开"后台连接" → 确认 FCM 机型没把 Google 服务拦掉。

七、通用排查清单

1. 系统设置里 Telegram 的通知权限是否开启，是否允许横幅/锁屏显示；
2. 是否开了专注模式 / 勿扰模式 / 低电量模式；
3. 该会话是否被静音，或设成了"仅 @ 提醒"；
4. 是否多设备同时在线，消息推给了另一台设备；
5. 存储是否已满；
6. 系统时间是否准确；
7. 换网络（Wi-Fi ↔ 蜂窝）试试；
8. 退出重登一次；
9. 更新客户端；
10. 卸载重装（先确认账号能登录）。

八、注意事项（别忽略）

• 梯子挂了，所有推送都收不到，包括微信。 因为 APNs 被你整体交给了代理，代理一断，推送全断。主力机慎用，备用机/Web3 专用机无所谓。
• 跨设备复制粘贴、接力可能失灵。 这类功能也依赖苹果推送，走代理后偶尔抽风；介意的话只在需要收 TG 推送时启用模块。
• PROXY 必须是配置里真实存在的策略组名。 如果你用整份配置一般没问题；自己写模块时要是报错，把它换成实际的组名或节点名。
• 模块是叠加，不是替换。 别把 .sgmodule 当配置文件切换，否则 VPN 会直接连不上。

九、下载与参考

仓库是个人维护的小项目，用之前建议点开 .sgmodule 看一眼内容——规则很短，几十秒能读完，这是用任何第三方配置的好习惯。

本文只讨论"自己的设备收不到通知"这一类技术问题。使用代理工具请遵守当地法律法规与平台服务条款，风险自负。