あなたはそれをはっきりと見ました ゲートウェイが実行中です、RPC 検出も緑色ですただし、Telegram/Slack ではメッセージが届かない、エージェントは「切断されましたが、エラーを報告しません」のような状態になります。この記事では、運用と保守に関するアドバイスを提供します。チャネル層トラブルシューティング パス: まず 7 つのリストを使用して、「コントロール サーフェスは正常である ≠ メッセージ サーフェスは正常である」という錯覚を取り除き、次に 1 つのリストを使用します。症状と根本原因ルックアップ テーブルはペアリングに収束します。dmPolicy、グループ チャットのメンションとボットの権限、最終的に付与6 ステップの最小限のリカバリ ランブック、そして明らかにサイトに関連しています 準備ができていません/起動が停止しています、ゲートウェイが閉じられました(1000)、クロスプラットフォームのインストール 分業読書法。
オープンクロープットコントロール プレーン、セッション プレーン、チャネル プレーン、モデル バックエンドさまざまなレベルで解体されます。ただ見てくださいopenclaw gateway statusこの問題は「モデルが壊れている」と誤診されやすいです。チームが 3 種類のログの間で空回りしないように、レビュー前の自己点検には以下の 7 項目を使用します。
RPC OK をメッセージ リンク OK として扱います。RPC はネイティブ コントロール プレーンの到達可能性を複数検証します。 DM/グループのルーティングは、ペアリング、Webhook の到達可能性、およびポリシーのヒットにも依存します。
ボット側の権限の変更を無視します。チャネル管理者が権限を変更した後、ボットがグループから削除された後、またはトークンがローテーションされた後でも、ゲートウェイが実行中と表示される場合があります。
dmPolicy のコピー アンド ペーストは厳密すぎます:ホワイトリストが誤って空のセットまたは古いワークスペースと一致すると、「正常ですがすべて拒否されました」というメッセージが表示されます。それと一致する必要がありますセキュリティの強化 比較しながら読んでください。
グループ チャットはゲート制御に関する言及を満たしていません:グループ ポリシーで @Bot の応答が必要な場合、ユーザーの口頭での「送信しました」は、ゲート条件に一致することを意味しません。
MCP ツール チェーンの問題をチャネルの問題として扱います。ツールが応答しない場合の症状は、メッセージが受信されない場合の症状と似ています。それらは最初に除外されるべきです。MCP接続 チャンネルに戻ります。
アップグレード後は、構成のみが表示され、ペアリング ステータスは表示されません。新しいバージョンのより厳格な認証デフォルトにより、ペアリングが「半無効」になる可能性があります。公式FAQに従ってペアリングを再実行する必要があります。
マルチゲートウェイ/マルチプロファイルドリフト:systemd と CLI の読み取りが異なるopenclaw.json「チェックした緑色はユーザーに接続されているインスタンスではありません」と表示される場合。
これらの落とし穴の共通の根本原因は次のとおりです。アクセシビリティそして到達性混乱しています: 前者の答えは「プロセスとポートが生きているかどうか」、後者の答えは「この DM がポリシーによって許可されているかどうか、セッションに入るかどうか、モデルのバックエンドによって消費されるかどうか」です。それらを台帳に書き込んだ後、次の表を使用して症状をレベルに固定します。
両方維持していれば 準備ができていない そして 閉店(1000)ランブックには 2 つのセットがあり、この記事は 3 番目のボリュームとして扱ってください。「スタートアップとセッション」を除外してもまだニュースがない場合は、チャネルの調査と戦略に戻ります。
そして ゲートウェイのセキュリティ強化 リンケージ: 締める dmPolicyメッセージ エントリは大幅に変更されるため、変更にはカナリア命令とロールバック命令を伴う必要があります。
特効薬はない: まず答えなければなりませんメッセージはどの層に貼り付けられていますか?を選択し、構成または権限を変更するかどうかを決定します。レビュー中に、メッセージの受信遅延、障害の説明可能性、ポリシー変更のロールバック時間の 3 つの SLA を明確に書き留めます。
| あなたが見るもの | 根本原因層の可能性が高い | 優先的な検証 |
|---|---|---|
| ゲートウェイの準備ができていません / 起動タイムアウト | 起動およびヘルスチェック層 | 読む トラブルシューティングの準備ができていません;ポート、メモリを確認し、起動シーケンスを作成します |
| RPC は緑色ですが、ツールが異常/閉じられています(1000) | セッション、スコープ、トークン、モデルバックエンド | 読む クローズ済み(1000)記事;整列 openclaw status医者と一緒に |
| チャネルのプローブが失敗したか、チャネルが切断されました | チャネル接続と認証情報 | openclaw channels status --probe;ボット トークンと Webhook の到達可能性を確認する |
| プローブはすべて緑色ですが、まだ受信していません | ポリシー: dmPolicy / グループ チャット ゲート / メンション | コントロール 安全性この記事のセクション 4 での最小限の再現実験により、 |
| メッセージが受信されましたが、エージェントが応答しません | モデル側クォータ、CLI のみ、ダウンストリーム タイムアウト | openclaw models status;そして モデルルーティング 連続読み取り |
「ゲートウェイ正常」のみを示しますコントロールサーフェスは生きています;あなたが買いたいものは、メッセージの到達性: マッチメイキング、戦略、チャネル API 機能は同じ承認フォームに含まれている必要があります。
Linux VPS で Gateway を実行する場合は、重いツール チェーンをリモートMac専用ノード、「メッセージの入力」と「ツールの実行」を 2 つの異なる職務 Runbook に記述してください。前者はチャネルと戦略を検討し、後者は SSH とリソース レベルを検討します。
そして OpenClaw カテゴリ一覧連携: インストール、Docker、systemd、観察、セキュリティに関する記事は、「すべての記事が Gateway とは何かについてゼロから始まる」という事態を避けるために、共通のコンテキストを確立する必要があります。
次のシーケンスは、「最初のグローバル スナップショット、次にチャネル プローブ、次に戦略とマッチング、最後に大規模な手術」を強調しています。公式 FAQ の「最初の 60 秒」と同じですが、完全ですグループチャットとdmPolicy よくある盲点。
実行の概要:openclaw status、OS、アップデート、ゲートウェイに到達可能であること、エージェント/セッション、プロバイダーのプロンプトにブロックする項目がないことを確認します。
チャネル プローブを実行します。openclaw channels status --probe、まず切断/認証エラーをクリアします。
列のペアリング:openclaw pairing list --channel telegram(実際のチャネルに応じて置き換えます)、ハンドルは保留中/期限切れです。
比較戦略:レビュー dmPolicy、グループ チャットのゲートとメンションのルールは勤務スケジュールと一致しています。変更する前にバックアップしてくださいopenclaw.json。
ゲートウェイを再起動し、以下を確認します。openclaw gateway restart次に、01 ～ 02 を繰り返します。それでも異常な場合は、もう一度試してください。openclaw doctor。
それでも失敗する場合は、最小限の情報パケットを収集します。バージョン、関連する構成フラグメント、および二次的なトラブルシューティングやコミュニティ ヘルプを容易にする前後の 50 行のログ (コーディング トークン)。
openclaw status openclaw gateway status openclaw channels status --probe openclaw pairing list --channel telegram openclaw logs --follow openclaw doctor
ヒント：変わったばかりなら gateway.bindまたは逆生成パスも同時に確認してくださいセキュリティの強化ループバックとトークンを組み合わせることで、「コントロール サーフェスには到達可能に見えるが、実際には Webhook に到達できない」という事態を回避できます。
アップグレード後に「チャンネルはすべて緑色ですがメッセージが受信されません」が表示される場合は、疑うことを優先してください。認証のデフォルト強化によるペアリングドリフト: 公式アップグレードノートに従って再実行します。openclaw gateway install --force医師の場合は、最初にビジネス プロンプトを書き直すのではなく。
そして 閉店(1000)記事のリンク: ログに近いフレームがある場合は、まずセッション レイヤーに戻ってスコープ/トークンを調整し、次に記事チャネル戦略に戻る必要があります。そうしないと、間違ったレイヤーが繰り返し変更されてしまいます。
最も一般的な生産事故の種類は次のとおりです。ポリシーが厳しすぎる + 義務書類が同期されていない：ゲートウェイのログもインジケーターも静かですが、ビジネス側は「エージェントが死んだふりをしている」ように感じます。このセクションでは最小限の再現実験を提供します。最初にそれを使用してください。プライベートチャットボットがまだ利用可能であることを確認し、グループ チャットに戻ってドアの制御を 1 つずつ解放します。
Telegram/Slack などのチャネルの場合は、まず 3 種類のリストを確認します。ボットはまだグループにいますか?、@メンションを必要とするかどうか、トピック/スレッドを制限するかどうか;また dmPolicyホワイトリストはワークスペースのパスに合わせて調整されます安全性最小露出の原則。
知らせ：ピーク時にトラブルシューティングを行うために直接「dmPolicy を解放」しないでください。最初に開いてください。読み取り専用監査そしてシャドウチャンネル(小規模アカウント グループ/テスト ボット)、運用戦略に収束する前にルールがヒットしていることを確認します。
ゲートウェイが VPS 上で実行され、ツールが VPS 上で実行される場合リモートMac専用ノード「メッセージ入力戦略」と「SSH 実行戦略」を個別に確認してください。前者のエラーはユーザーにサイト全体がダウンしていると思わせますが、後者のエラーは一部のツールが失敗するだけです。
次の項目は内部調整用です。具体的なしきい値は、チャネルのサイズとコンプライアンス要件によって異なります。
dmPolicy/グループ ゲート クラスの変更は、少なくとも次の期間に予約する必要があります完全なペアリングの復帰そしてロールバックバックアップ, 夕方のラッシュアワーを避けるために、「完全に沈黙するように一行変更する」。純粋なローカルまたは一時的な VPS は、多くの場合、ゲートウェイを実行します。スリープ、ポート ドリフト、証明書、IM プラットフォームの電流制限の間を繰り返します。そして安定して動作する必要があるxcodebuild / CLI エージェント / 常駐ツール チェーンチームの方が適しているコンピューティング能力とデスクトップのステータス入れます独占的、長期オンラインリモート Mac ノードでは、ゲートウェイを Linux マシン上に残し、メッセージングとオーケストレーションに集中します。独自の散在マシンを構築したり、不安定な仮想化環境で macOS を石畳み合わせたりするのと比較して、NodeMiniのMac Miniクラウドレンタル固定 SSH、クリア ディスク ファイル、複製可能なノード イメージは、「ツールの実行」を「メッセージ エントリ」から分離するのにさらに役立ちます。仕様と価格を比較する必要がある場合は、最初にお読みください。レンタル料金の説明、と組み合わせる ヘルプセンター 計画ノード。
実装するときは、この Runbook を内部の「チャネル変更レベル」にバインドすることをお勧めします。ボットのアクセス許可、グループ ポリシー、ゲートウェイのバージョン、およびモデルのバックエンドの切り替えでは、異なる承認およびカナリア スコープを使用する必要があります。
RPC マルチ認証コントロール プレーンに到達可能です。メッセージがセッションに入るかどうかは、チャネル ペアリング、ボットのアクセス許可、dmPolicy、およびグループ チャット ゲーティングにも依存します。この記事のセクション 3 の順序に従ってください。channels status --probe そして pairing list。ノードおよびネットワーク側の提案が必要な場合は、それらを表示できます。ヘルプセンター。
Closed(1000) の記事では、アップグレード後のセッション スコープ、トークン、およびツールの例外に焦点を当てています。この記事では、チャネル層のメッセージ フローに焦点を当てます。クローズ フレームがログに頻繁に表示される場合は、2 つの記事を続けて読む必要があります。最初にセッションとセッション バックエンドを除外し、次にペアリングと戦略に戻ります。 OpenClaw 関連記事は次の場所にあります。ブログ OpenClaw フィルタリング 入力。