openclaw gateway status がすでに Runtime: running なのに、Telegram では返信がなく、Chrome 拡張の Relay が灰色のまま、ログに 409 Conflict が出る——これは 2026 年デプロイで最も多い「トリプル症候群」です。制御面は健全でも、業務チャネルが閉じていません。インストール済みで OpenClaw を 7×24 本番へ進める開発者向けに、四連プローブ、症状対照表、6 ステップ受け入れ Runbook と FAQ を示します。サイト内の 半インストール復旧、channels probe 専用記事、gateway not ready と役割分担し、誤った段階で設定をいじらないようにします。
多くのチームは「インストール成功」を「外部提供可能」と同一視します。OpenClaw 2026 アーキテクチャでは、Gateway プロセス、チャネル（Telegram / WhatsApp 等）、ブラウザ Relay は独立した 3 本の経路です。前者は RPC と制御面のみを保証し、後者は Token、Webhook モード、ペアリング、拡張内 WebSocket アドレス、リバースプロキの Upgrade に依存します。以下 6 症状のうち 2 つ以上なら本記事の手順を使い、マシン全体の再インストールは避けてください。
Telegram が完全無応答：Bot はオンラインでもメッセージに inbound が出ない。多くは 409（同一 Bot Token の複数 Gateway）または残存 Webhook が polling を阻害。
ログに 409 Conflict：同一 BOT_TOKEN を第 2 Gateway、旧コンテナ、ローカルデバッグが同時 long-polling。
Chrome Relay バッジは点灯、タブなし：拡張が誤ポート/ホストに接続、または Nginx が Upgrade: websocket を転送していない。2026.3.22+ で relay ドライバ変更あり、跨ぎデプロイは公式変更を照合。
channels probe 失敗だが gateway status は正常：ペアリング未承認または dmPolicy ブロックが多く、Gateway 未インストールではない——channels probe 専用記事を参照。
リモート CLI が Unauthorized：設定キーが gateway.token から gateway.auth.token へ移行。openclaw doctor --generate-gateway-token 後に再起動。
18789 EADDRINUSE：表面 running でも古い PID。ポート解放後に gateway restart。先にチャネル設定を大量変更しない。
| 見える表象 | 本記事優先（デプロイ後トリプル） | 転読すべき専用記事 |
|---|---|---|
| install.sh 成功だが Gateway なし | いいえ | 半インストール復旧 |
| gateway status: not ready / OOM | いいえ | gateway not ready |
| running + Telegram 409 / 無応答 | はい | ペアリング併発時 + channels probe |
| running + Relay 切断 | はい | 公開露出時 + Gateway セキュリティ / Tailscale 記事 |
| models Unauthorized | 一部（Token キー） | 認証トラブルシュート |
「Gateway プローブ OK」は制御面が生きているだけ——チャネルとブラウザ Relay はそれぞれ受け入れを通して初めてデプロイ完了です。
順序は固定です。まずToken を消費する Gateway が 1 台だけであることを証明し、次にペアリングと Relay URL を扱います。409 が残ったまま openclaw gateway restart を繰り返すとログだけが乱れます。
四連プローブ（約 5 分）：openclaw status → openclaw gateway status --deep → openclaw channels status --probe → openclaw doctor --deep。別ターミナルで openclaw logs --follow を見て inbound を確認。
Telegram Token 健診：curl "https://api.telegram.org/bot<TOKEN>/getMe" で Bot 有効性。Webhook 設定歴があれば deleteWebhook で polling 復帰。
409 撲滅：他の Gateway/デバッグ（旧 Docker、同僚 PC の同名 Bot）を停止。グローバルに 1 インスタンスだけが Token を保持。
ペアリングと dmPolicy：openclaw pairing approve telegram <CODE>。probe 失敗時は channels 専用記事で dmPolicy を調整。Gateway を 0.0.0.0 に晒して試さない。
Chrome Relay：拡張の Gateway URL は実リッスンと一致（本機は ws://127.0.0.1:18789 等、リバースプロキは wss:// と Upgrade）。跨ぎデプロイは 2026.3+ relay 変更の影響を確認。
再起動と再検：openclaw doctor --fix → openclaw gateway restart → 再度 channels status --probe。macOS 常駐は launchd 記事、Linux は Ubuntu systemd デプロイ。
# デプロイ後四連プローブ + Telegram Webhook 清理例 openclaw status openclaw gateway status --deep openclaw channels status --probe openclaw doctor --deep curl -s "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/getMe" curl -s "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/deleteWebhook" openclaw pairing approve telegram YOUR_CODE openclaw gateway restart
ヒント：Gateway が実際にリッスンしていない場合は先に 半インストール復旧 を読んでから本記事へ。誤段階で有効設定を消さないでください。
注意：切り分けのため一時的に 0.0.0.0 へバインドするのは高リスクです。本番は loopback + Tailscale/トンネルを維持し、Token ローテーションは認証専用記事を参照してください。
gateway.auth.token に統一。旧キーのみ変更すると「ローカル doctor は通るがリモート CLI は 401」に見えます。Connection: upgrade が無いと「拡張は点灯、タブなし」になりがちです。スリープするノート PCや CI とリソースを奪い合う共有 Mac に Gateway を置くと、OS 更新やポート争奪後にトリプル症候群が再発します。専有で常時オンラインの macOS ノードの方が 7×24 チャネルと Relay に向きます。VPS を借りる感覚で SSH 保守可能な Mac 算力と「四連プローブ」を標準イメージに載せたい場合、NodeMini の Mac Mini クラウドレンタルが実務上はっきり有利です。OpenClaw リモートモードや iOS CI と同じ運用心智で、「自宅 Gateway は眠る、オフィス Bot が Token を奪う」といった人的 409 を減らせます。