想定される事象：OpenClaw Gateway とチャネルがオンラインに見えるのに、ユーザー側にテキスト応答が長く届かない、またはログに429、コンテキスト超過、モデル利用不可、ツール未登録などモデル／キュー系のエラーが繰り返し出る場合です。本稿の結論：公式の Gateway Troubleshooting を断片としてではなく、実行可能な層の順序に落とし込みます。インストールと Compose は三プラットフォームの導入ガイドとDocker 本番運用ランブック、ネットワークと CLI はDocker ネットワークの切り分け、チャネルの握手はチャネル OAuth の切り分けに任せます。構成：六つの誤判断、層別の意思決定表、チェック項目対照表、コマンド断片、六ステップのランブック、三つの KPI、リモート常駐への収束です。
「無応答」はしばしば複数レイヤーの不具合が重なった外観です。プロセスは動き、ヘルスチェックは緑、リバースプロキシは 200 を返す一方で、モデル層のクォータ枯渇、コンテキスト拒否、ワーカーがキューを消費しなくなる背圧などが同時に起きます。オンコールで頻出する次の六つは、この順で照合すると無益な再起動をおおむね避けられます。
memory_search を絞り込みます。Skills と memory_search の調整記事を参照してください。openclaw doctor は設定変更後のベースラインスナップショット向きです。事故のたびにゼロから deep だけを回すと、いつから悪化したかが見えません。インストール後 doctor の記事とつなげ、インストール直後一回、アップグレード後一回、無応答インシデント時に一回、と運用してください。公式 Troubleshooting は、まず Gateway とモデルの疎通を確認し、チャネルとツールへ下る流れが一般的です。本稿ではその順序をレビュー資料にそのまま貼れる表にし、ランブックや変更チケット番号と紐づけられるようにします。
運用では「無応答」をハード失敗（4xx／5xx やスタックがはっきり出る）とソフト失敗（ログは静かだが出力がない）に粗く分けます。ソフト失敗ではキュー、タイムアウト、コンテキスト閾値を先に、ハード失敗では鍵、ルーティング、リバプロを先に見ます。
上流から下流へ一段ずつ潰します。いずれかの層が閉じる前に四層の設定を同時にいじらないでください。ロールバックが雪崩しやすくなります。
| レイヤー | 典型的な症状 | 優先する証拠 | 次の一手 |
|---|---|---|---|
| プロセス／コンテナ | ポート不通、プロセスの反復クラッシュ | コンテナ終了コード、systemd／launchd のログ | 導入ガイドと Docker 本番稿へ戻り、リソースとボリュームマウントを確認します。 |
| リバプロ／TLS／WS | ブラウザで 502 が散発、WS が途切れる | リバプロの access／error、Upgrade ヘッダー | TLS と WebSocket のチェックリストを開き、項目どおりに照合します。 |
| チャネル | 接続表示はあるがスレッドにメッセージが入らない | チャネル側イベント、OAuth スコープ | チャネル OAuth の表を実行し、プライバシーモードとチャンネル許可を除外します。 |
| モデル／キュー | ログにリクエストはあるが completion がない、429 文言 | プロバイダの状態、クォータ、ルーティングログ | プロバイダのルートとフェイルオーバーを確認し、必要なら同時実行とコンテキストを下げます。 |
次の対応づけはコミュニティと公式ドキュメントで繰り返される手順を骨格としています。具体的なサブコマンドは、手元の OpenClaw バージョンの CLI ヘルプを正としてください。目的は操作とログ行を結び付けることであって、感覚的な再起動ではありません。
| 確認アクション（概念） | ログ／現象の指紋 | 説明 |
|---|---|---|
| Gateway の健全性／状態 | レディネスプローブ失敗や status コマンドのエラー | まず待ち受けアドレスと compose ネットワークを閉じてからモデルへ進みます。 |
| モデル疎通プローブ | timeout、401、403、429 | 401／403 は鍵とプロジェクト寄り、429 はクォータとルート冷却寄りです。 |
| doctor（深いモード） | 設定の漂移、存在しないパス、バージョンの skew | アップグレードや設定マージのあと必ず実行し、出力を変更チケットに添付します。 |
| キュー／背圧（該当する場合） | リクエスト滞留、エラーコードなしに遅延だけが跳ね上がる | 同時実行を下げ、インスタンスを増やすか時間帯をずらします。リモート機の CPU 水位と併せて見ます。 |
出力はチケットの添付に保存し、秘匿が必要な行はマスクしてから共有してください。フラグの詳細はローカルの openclaw --help を正としてください。
# ベースライン：アップグレードまたは設定変更のたびに実行してアーカイブ openclaw doctor openclaw doctor --deep --yes # 再現時：タイムスタンプとリクエスト ID（ログにあれば）を記録 # tail -n 200 /path/to/gateway.log | tee ./incident-$(date +%Y%m%d%H%M).log # モデルルートの二分：マルチプロバイダ稿に沿い、非主系を順に切る
ヒント：リバプロのタイムアウト、モデルの max_tokens、チャネルの再試行を同時に変えると、帰属がつきません。インシデントごとに一層だけ動かし、doctor の出力に変更前後の diff を書き込んでください。
まず Gateway ログを 30 秒の窓で取り、モデルプロバイダの返却断片を検索します。long context や 429 が出ていれば、プロバイダ稿に従って冷却とフェイルオーバーを行い、最初のトークンまでの遅延が戻るか観測します。
リバプロの WebSocket とチャネル OAuth を先に照合します。UI が localhost でチャネルが公開ドメインだと、二系統の入口方針が食い違うことが多いです。同じトポロジ図に両方の経路を書き入れてから調べてください。
ベンチマークではなく工程上の合意として、2025 から 2026 にかけてマルチプロバイダと長いコンテキストを既定で有効にしたスタックでは、キューとクォータ起因の無応答がコミュニティのチケットで依然として多い部類です。TTFT と 429 を同じ時間軸に描くと、CPU だけを見るより「昨夜いきなり全員が沈黙した」理由を説明しやすくなります。
見落とされがちなのは企業プロキシと証明書の差し替えです。モデルへの HTTPS プローブは成功するのに長寿命接続だけが断続する、という併存が起き得ます。同じキャプチャ窓で Gateway の出口と開発者ノートの出口を突き合わせ、ネットワーク方針をバージョン不具合と取り違えないでください。プロキシ許可、SNI、HTTP／2 の互換性をDocker ネットワークの切り分けと同じ運用メモに書けば、当番は「出口が一致しているか」だけで迅速に分流できます。
自前モデルとパブリック API を併用するチームでは、変更レビューに二系統のルート表を必須にすることをおすすめします。どのセッションがどの鍵を使い、どの条件でフェイルオーバーするかを文書化しないと、「無応答」は単一設定の誤記ではなくルート表そのものの欠落として現れます。その表は doctor のベースラインと同じリビジョン管理に載せ、担当交代後も口頭前提が途切れないようにしてください。
個人マシンのスリープ、ルーティングの切り替え、企業出口方針により、「無応答」が再現しにくい挙動に見えます。本番には固定出口、再起動順序の再現性、監査可能なログパスが要ります。自作の小型ホストも、グローバル到達性やディスク／帯域の余裕が乏しく、ピーク時にモデルキューとチャネル再試行が踏み合いやすいです。
OpenClaw を24 時間 365 日の自動化入口として据えるチームには、専用の Apple Silicon、複数リージョン、柔軟なレンタル期間を備えたクラウド上の Mac に Gateway を置くほうが安定しやすいです。本ランブックと常駐運用のチェックリストを、変更レビューに同梱してください。MACCOME はシンガポール、日本、韓国、香港、米国東海岸、米国西海岸などで Mac mini M4／M4 Pro を提供しており、リバプロ、永続ディレクトリ、監視の固定に向きます。公開のレンタル説明とヘルプを確認してから発注してください。
パイロットとして、主要ユーザーと同じリージョンの短いレンタルで本六ステップを一度通し切り、そのうえで月額／四半期とディスク拡張を決めると安全です。
最後に「ドキュメント規律」です。無応答インシデントを閉じるたびに、根本原因ラベルと対応するログ行のパターンを社内ナレッジに登録し、次のリリース前にそのパタイルがまだ監視で拾えているか確認してください。公式 Troubleshooting が更新されたとき、自社の追記条項だけを diff でき、毎年ゼロから手順書を書き直す必要が減ります。
よくある質問
アップグレード後に突然無応答になりました。最初に何をすべきですか。
まず openclaw doctor --deep --yes を実行し、アップグレード前のベースラインと diff します。doctor がクリーンなら、四層表に沿ってリバプロから下へ進みます。手順の補足は ヘルプセンター も参照してください。
ログに tool call の失敗が既に出ています。本稿はまだ必要ですか。
モデルが一度計画を返しツールを起動したあと実行に失敗しているなら、まず MCP と ClawHub のトリアージ稿 を開いてください。本稿は「モデルが出てこない／キューが進まない」主線を扱います。