Gateway
複数のGateway
ほとんどのセットアップでは、1つの Gateway を使用してください。単一の Gateway で複数のメッセージング接続とエージェントを処理できるためです。より強い分離や冗長性が必要な場合(例: レスキューボット)は、分離されたプロファイル/ポートで別々の Gateway を実行します。
最も推奨されるセットアップ
ほとんどのユーザーにとって、最も単純なレスキューボット構成は次のとおりです。
- メインボットはデフォルトプロファイルのままにする
- レスキューボットは
--profile rescueで実行する - レスキューアカウントには完全に別の Telegram ボットを使用する
- レスキューボットは
19789など別のベースポートで維持する
これにより、レスキューボットがメインボットから分離されるため、プライマリボットが停止している場合でも、デバッグや設定変更の適用ができます。派生するブラウザ/canvas/CDP ポートが衝突しないように、ベースポート間は少なくとも20ポート空けてください。
レスキューボットのクイックスタート
別の方法を選ぶ強い理由がない限り、これをデフォルトの手順として使用してください。
# Rescue bot (separate Telegram bot, separate profile, port 19789)openclaw --profile rescue onboardopenclaw --profile rescue gateway install --port 19789メインボットがすでに実行中の場合、通常はこれだけで十分です。
openclaw --profile rescue onboard の実行中:
- 別の Telegram ボットトークンを使用する
rescueプロファイルを維持する- メインボットより少なくとも20高いベースポートを使用する
- 自分で管理しているものがすでにない限り、デフォルトのレスキューワークスペースを受け入れる
オンボーディングによってレスキューサービスがすでにインストールされている場合、最後の gateway install は不要です。
これが機能する理由
レスキューボットは、次を独自に持つため独立したままになります。
- プロファイル/設定
- 状態ディレクトリ
- ワークスペース
- ベースポート(および派生ポート)
- Telegram ボットトークン
ほとんどのセットアップでは、レスキュープロファイルに完全に別の Telegram ボットを使用してください。
- オペレーター専用に保ちやすい
- ボットトークンと識別子が分離される
- メインボットのチャネル/アプリインストールから独立する
- メインボットが壊れている場合の単純な DM ベースの復旧経路になる
--profile rescue onboard が変更する内容
openclaw --profile rescue onboard は通常のオンボーディングフローを使用しますが、すべてを別のプロファイルに書き込みます。
実際には、レスキューボットは次を独自に持ちます。
- 設定ファイル
- 状態ディレクトリ
- ワークスペース(デフォルトでは
~/.openclaw/workspace-rescue) - 管理対象サービス名
それ以外のプロンプトは通常のオンボーディングと同じです。
一般的な複数 Gateway セットアップ
上記のレスキューボット構成が最も簡単なデフォルトですが、同じ分離パターンは1つのホスト上の任意の Gateway のペアまたはグループにも使用できます。
より一般的なセットアップでは、追加の各 Gateway に独自の名前付きプロファイルと独自のベースポートを割り当てます。
# main (default profile)openclaw setupopenclaw gateway --port 18789 # extra gatewayopenclaw --profile ops setupopenclaw --profile ops gateway --port 19789両方の Gateway で名前付きプロファイルを使用したい場合も可能です。
openclaw --profile main setupopenclaw --profile main gateway --port 18789 openclaw --profile ops setupopenclaw --profile ops gateway --port 19789サービスも同じパターンに従います。
openclaw gateway installopenclaw --profile ops gateway install --port 19789フォールバック用のオペレーターレーンが必要な場合は、レスキューボットのクイックスタートを使用してください。異なるチャネル、テナント、ワークスペース、または運用ロール向けに複数の長期稼働 Gateway が必要な場合は、一般的なプロファイルパターンを使用してください。
分離チェックリスト
Gateway インスタンスごとに、次を一意に保ってください。
OPENCLAW_CONFIG_PATH— インスタンスごとの設定ファイルOPENCLAW_STATE_DIR— インスタンスごとのセッション、認証情報、キャッシュagents.defaults.workspace— インスタンスごとのワークスペースルートgateway.port(または--port)— インスタンスごとに一意- 派生するブラウザ/canvas/CDP ポート
これらを共有すると、設定の競合やポート衝突が発生します。
ポートマッピング(派生)
ベースポート = gateway.port(または OPENCLAW_GATEWAY_PORT / --port)。
- ブラウザ制御サービスのポート = ベース + 2(local loopback のみ)
- canvas ホストは Gateway HTTP サーバーで提供される(
gateway.portと同じポート) - ブラウザプロファイルの CDP ポートは
browser.controlPort + 9 .. + 108から自動割り当てされる
設定または環境変数でこれらのいずれかを上書きする場合は、インスタンスごとに一意に保つ必要があります。
ブラウザ/CDP の注意事項(よくある落とし穴)
- 複数のインスタンスで
browser.cdpUrlを同じ値に固定しないでください。 - 各インスタンスには、独自のブラウザ制御ポートと CDP 範囲(Gateway ポートから派生)が必要です。
- 明示的な CDP ポートが必要な場合は、インスタンスごとに
browser.profiles.<name>.cdpPortを設定してください。 - リモート Chrome:
browser.profiles.<name>.cdpUrlを使用します(プロファイルごと、インスタンスごと)。
手動環境変数の例
OPENCLAW_CONFIG_PATH=~/.openclaw/main.json \OPENCLAW_STATE_DIR=~/.openclaw \openclaw gateway --port 18789 OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json \OPENCLAW_STATE_DIR=~/.openclaw-rescue \openclaw gateway --port 19789クイックチェック
openclaw gateway status --deepopenclaw --profile rescue gateway status --deepopenclaw --profile rescue gateway probeopenclaw statusopenclaw --profile rescue statusopenclaw --profile rescue browser status解釈:
gateway status --deepは、古いインストールから残っている launchd/systemd/schtasks サービスの検出に役立ちます。multiple reachable gateway identities detectedなどのgateway probeの警告テキストは、意図的に複数の分離された Gateway を実行している場合、または OpenClaw が到達可能なプローブ対象が同じ Gateway であることを証明できない場合にのみ想定されます。SSH トンネル、プロキシ URL、または同じ Gateway への設定済みリモート URL は、トランスポートポートが異なる場合でも、複数のトランスポートを持つ1つの Gateway です。