你明明看到 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 篩選 進入。