你明明看到 Gateway 在跑、RPC 探测也绿，但 Telegram/Slack 里消息就是不进来，Agent 像「掉线却不报错」。本文给运维一条渠道层排障路径：先用七条清单把「控制面正常 ≠ 消息面正常」的错觉拆掉，再用一张表象 vs 根因对照表收敛到配对、dmPolicy、群聊 mention 与 Bot 权限，最后给出六步最小恢复 Runbook，并明确与站内 not ready / 启动卡住、gateway closed(1000)、跨平台安装 的分工读法。
OpenClaw 把控制面、会话面、渠道面、模型后端拆在不同层次；只看 openclaw gateway status 很容易把问题误判成「模型坏了」。下面七条用于评审前自检，避免团队在三类日志之间空转。
把 RPC OK 当成消息链路 OK：RPC 多验证本机控制面可达；DM/群路由还取决于配对、Webhook 可达性与策略命中。
忽略 Bot 侧权限变更：频道管理员改权限、Bot 被移出群或 Token 轮换后，Gateway 仍可能显示 running。
dmPolicy 复制粘贴过严：误把 allowlist 配成空集或旧 workspace，会出现「健康但全拒收」；应与 安全加固篇 对照阅读。
群聊未满足 mention 门控：群策略要求 @Bot 才响应时，用户口头说「我发了」并不等于命中门控条件。
把 MCP 工具链问题当渠道问题：工具无响应与消息进不来症状相似；应先排除 MCP 连通性 再回渠道。
升级后只看配置不看配对状态：新版本更严格的 auth 默认可能让配对「半失效」；需要按官方 FAQ 重跑 pairing。
多 Gateway / 多配置文件漂移：systemd 与 CLI 读到不同 openclaw.json 时，会出现「你查的 green 不是用户连的那个实例」。
这些坑的共同根因，是把可达性与可投递性混为一谈：前者回答「进程与端口是否活着」，后者回答「这条 DM 是否被策略允许、是否进到会话、是否被模型后端消费」。把它们写进台账后，再用下一张表把症状钉到层级。
若你同时维护 not ready 与 closed(1000) 两套 Runbook，请把本文当作第三册：当「启动与会话」都排除后仍无消息，再回到渠道探针与策略。
与 Gateway 安全加固 篇联动：收紧 dmPolicy 会显著改变消息入口，变更必须带金丝雀与回滚说明。
没有银弹：你要先回答消息卡在哪一层，再决定改配置还是改权限。评审时把三条 SLA 写清：消息入站时延、失败可解释性、策略变更的回滚时间。
| 你看到的表象 | 更可能的根因层 | 首选验证 |
|---|---|---|
| Gateway not ready / 启动超时 | 启动与健康检查层 | 读 not ready 排错；看端口、内存、compose 启动顺序 |
| RPC 绿但工具异常 / closed(1000) | 会话、scope、Token、模型后端 | 读 closed(1000) 篇；对齐 openclaw status 与 doctor |
| channels 探针失败或频道 disconnected | 渠道连接与凭证 | openclaw channels status --probe；核对 Bot Token 与 webhook 可达性 |
| 探针全绿但仍无入站 | 策略：dmPolicy / 群聊门控 / mention | 对照 安全篇 与本文第 4 节最小复现实验 |
| 消息进来但 Agent 不回 | 模型侧配额、CLI-only、下游超时 | openclaw models status；与 modelRouting 篇连读 |
「Gateway 正常」只说明控制面活着；你要买的是消息可投递性：配对、策略与频道 API 能力必须在同一张验收表上。
若你把 Gateway 跑在 Linux VPS、把重工具链放到 远程 Mac 独占节点，请把「消息入口」与「工具执行」写进两张不同的值班 Runbook：前者看 channels 与策略，后者看 SSH 与资源水位。
与 OpenClaw 分类列表 联动：安装、Docker、systemd、观测与安全文章应按顺序建立共同语境，避免「每篇都从零讲 Gateway 是什么」。
下列顺序强调「先全局快照，再渠道探针，再策略与配对，最后才动大手术」：与官方 FAQ 的「First 60 seconds」同构，但补齐群聊与 dmPolicy 常见盲区。
跑总览：openclaw status，确认 OS、更新、Gateway 可达、agents/sessions 与 provider 提示无阻塞项。
跑渠道探针：openclaw channels status --probe，把 disconnected / auth 类错误先清掉。
列配对：openclaw pairing list --channel telegram（按实际渠道替换），处理 pending / 过期。
对照策略：复核 dmPolicy、群聊门控与 mention 规则是否与值班表一致；变更前先备份 openclaw.json。
重启 Gateway 并复查：openclaw gateway restart 后重复 01–02；仍异常再 openclaw doctor。
仍失败则收集最小信息包：版本、相关配置片段、前后 50 行日志（打码 Token），便于二次排查或社区求助。
openclaw status openclaw gateway status openclaw channels status --probe openclaw pairing list --channel telegram openclaw logs --follow openclaw doctor
提示：若你刚改 gateway.bind 或反代路径，请同时核对 安全加固篇 的回环与 Token 组合，避免「控制面看似可达、Webhook 实际打不到」。
升级后若出现「channels 全绿但消息仍不进」，优先怀疑配对漂移与 auth 默认收紧：按官方升级笔记重跑 openclaw gateway install --force 与 doctor，而不是先重写业务 prompt。
与 closed(1000) 篇联动：若日志里已有 close 帧，应先回到会话层对齐 scope/Token，再回本文渠道策略，否则会反复改错层。
生产事故里最常见的一类，是策略过严 + 值班文档没同步：Gateway 日志安静、指标也安静，但业务侧体感是「Agent 装死」。本节给最小复现实验：先用私聊验证 Bot 仍可用，再切回群聊逐项放开门控。
对 Telegram/Slack 等渠道，优先核对三类清单：Bot 是否仍在群内、是否要求 @mention、是否限制话题/线程；再把 dmPolicy 的 allowlist 与 workspace 路径对齐 安全篇 的最小暴露面原则。
注意：不要在高峰期直接「全放行 dmPolicy」排障：先开只读审计与影子通道（小号群 / 测试 Bot），确认命中规则后再收敛生产策略。
若 Gateway 跑在 VPS、工具执行在 远程 Mac 独占节点，请把「消息入口策略」与「SSH 执行策略」分开评审：前者错误会让用户以为全站宕机，后者错误只会让部分工具失败。
下列条目用于内部对齐；具体阈值以你们渠道规模与合规要求为准。
dmPolicy / 群门控类变更应至少预留 一次完整配对回归与回滚备份，避免晚高峰「改一行全静默」。纯本机或临时 VPS 跑 Gateway，常会在睡眠、端口漂移、证书与 IM 平台限流之间反复；而需要稳定跑 xcodebuild / CLI Agent / 常驻工具链 的团队，更适合把算力与桌面态放到独占、长期在线的远程 Mac 节点上，把 Gateway 留在 Linux 小机上专注消息与编排。相比自建零散机器或在不稳定的虚拟化环境里硬凑 macOS，NodeMini 的 Mac Mini 云端租赁在固定 SSH、清晰磁盘档位与可复制的节点画像上更利于把「工具执行」从「消息入口」里解耦；需要对比规格与价格时，可先阅读 租赁价格说明，再结合 帮助中心 规划节点。
落地时建议把本 Runbook 与内部「渠道变更等级」绑定：Bot 权限、群策略、Gateway 版本与模型后端切换应使用不同的审批与金丝雀范围。
RPC 多验证控制面可达；消息是否进入会话还取决于渠道配对、Bot 权限、dmPolicy 与群聊门控。请按本文第三节顺序执行 channels status --probe 与 pairing list。需要节点与网络侧建议可查看 帮助中心。
closed(1000) 篇聚焦会话 scope、Token 与升级后工具异常；本文聚焦渠道层消息流。若日志里频繁出现 close 帧，应两篇连读：先排除会话与会话后端，再回到配对与策略。OpenClaw 相关文章可从 博客 OpenClaw 筛选 进入。