故障排查：来源已连接，为什么目标收不到消息

先记录一次具体问题：哪一个实例、哪条规则、哪条新消息、哪个目标没有收到。用同一条消息贯穿排查，不只看总体统计。

第一步：检查实例和来源

排查入口：运行日志查看来源连接，投递记录查看具体消息的发送结果。

进入该实例，确认实例已启动，来源账号属于当前实例。在“运行日志”查看来源连接、最近心跳及已加载路由。

节点在线表示节点可通信，不保证来源登录有效；账号已登录也不保证已有规则或监听已经就绪。遇到来源 Token 失效、Telegram 登录过期或 QQ 等待扫码，先完成对应账号恢复。

第二步：检查来源频道与规则

1. 确认规则启用，来源账号和频道选对。
2. Discord 检查频道/帖子 ID；Telegram 检查数字 Chat ID 和负号；QQ 检查群号；X 检查绑定账号。
3. 检查触发词、屏蔽词、发送人限制、机器人消息和自身消息开关。
4. 使用连接完成后的一条新消息验证；不要默认自动补发旧历史。
5. 若配置多目标，逐个核对目标名称和对应结果。

没有投递记录时，优先查以上内容。被前置筛选排除的消息未必产生目标投递记录。

第三步：读懂投递记录

“重新投递”会产生实际发送，可能再次通知用户。先确认目标没有收到、故障已处理，再操作，不连续点击。

第四步：检查目标

编辑 Webhook 或 Bark 时页面留空是为了不回显凭据，不代表已经丢失配置。只在要更换时填写新值。

只有附件或翻译失败

先用普通文本确认基础链路；再分别测试一张小图和一条需翻译的短消息。检查转发附件开关、目标附件限制、媒体来源，以及服务端翻译/视觉能力是否可用。

文本正常不能证明视频、水印、翻译也正常。不要用多次重启代替对具体错误的检查。

消息重复或漏掉某些消息

重复时检查是否有多条重叠规则、是否全部发送到多个配置、是否形成来源与目标回环，以及是否曾手工重新投递。遗漏时检查筛选、去重、历史消息边界和平台限制。

调整后再发送一条带新序号的消息。修复后有一次成功，只说明这条测试链路通过，不代表此前积压都已清空。

联系支持时提供这些信息

复制以下模板，先将私人正文和凭据遮挡：

问题发生时间及所在时区：
实例名称：
规则名称：
来源平台和频道类型：
目标类型：
来源消息时间或脱敏测试编号：
投递状态和脱敏错误说明：
目标是否收到、是否重复：
最近修改了什么：

不要提交 Token、Webhook 完整地址、SMTP 授权码、登录验证码、两步验证密码或注册 Key。截图也需遮挡这些字段。不要通过删除整个实例来排查：删除会清理关联资源和凭据。

返回教程目录