Gateway を VPS またはクラウド Mac 上で安定稼働させた一方、ノート PC で openclaw を実行するとツールが動かない、あるいは RPC プローブ失敗 が出るのにサーバー側ログは静か、という状況を想定します。本文は OpenClaw を本番ゲートウェイとして扱うチーム 向けです。まず 7 項目で gateway.mode=remote と Tailscale による公開、SSH ローカルポートフォワード の混同を解きます。次に 4 行の対照表でプロセス位置、クライアントの向き先、TLS、トークン検証を整理します。続けて 6 ステップの引き継ぎ Runbook（リモート URL、wss、両端の gateway status、gateway install --force、doctor、ヘルスプローブ）を示し、サイト内の Tailscale プライベート公開、全プラットフォーム導入の切り分け、gateway closed(1000) へ役割分担で誘導します。
公式 FAQ の local / remote は短い記述ですが、本番では プローブ URL と実際の待ち受けが一致しない こと、systemd ユーザーユニットと対話シェルの設定が分岐する ことに時間が溶けがちです。以下の 7 つで議論を「ping は通る」から「署名できる受け入れ表」へ寄せます。
リモートモードを SSH ポートフォワードの別名とみなす：SSH -L はブラウザから UI への経路を整えるだけで、リモートモードは CLI の既定プローブ先 を変えます。併用はできますが意味合いは異なります。
Tailscale Serve を remote mode と同一視する：Tailscale は ローカル Gateway を tailnet から到達可能にします。remote mode は ノートの CLI が 別ホスト の Gateway に話しかけます。境界表は Tailscale の記事 を参照してください。
gateway.remote.url だけ変えて gateway.mode を忘れる：mode が local のままだと CLI は空のローカルポートをプローブし続け、不可解なタイムアウトになります。
http と wss の混在：リバースプロキシで TLS を終端し、クライアント URL と trusted-proxy の説明が食い違うと 401 や再接続嵐が起きます。ハードニング観点で同席レビューしてください。
Config (cli) / Config (service) の 2 行を無視する：アップグレード後に root でファイルを編集したのに、サービスは --profile dev の別 state ディレクトリで動いている、というのは典型です。
トークンを片側にしか書かない：Gateway 側で gateway.auth.token をローテーションしたのにノートの Control UI が古い値を保持している。トークン表は gateway closed(1000) と併読してください。
最小のリモート受け入れ試験がない：チャットだけ試してツールチェーンを試さないと、モデル更新後に初めて RPC スコープのドリフトが表面化します。読み取り専用コマンドをカナリアに固定してください。
共通の根は、OpenClaw を単一の Web アプリではなく、ローカル監督プロセスとリモートセッションルーティングを持つ二端システム として扱えていないことです。プラットフォームエンジニアリングでは kubeconfig の文脈と同様に、各開発端末について プロファイル、state ディレクトリ、リモート URL、ローテーション時刻 を監査可能に残してください。
全プラットフォーム導入の切り分け とセットで：初回インストールで openclaw doctor が通っていないのに remote へ急ぐと、チケットに「壊れたインストール」と「誤ったインスタンス」が混ざります。
2026 年に「Gateway はクラウド、IDE はローカル」を標準化するなら、オフライン時の劣化方針 を明文化します。CLI を読み取り専用に落とせるか、暗黙の mode 切替を禁じて本番への誤接続を防ぐか、を決めてください。
専有リモート Mac のトポロジでは Gateway を Linux VPS に置きツール実行をレンタル macOS に載せる構成がよくあります。その場合も remote URL は VPS を指します。Mac へ SSH するアドレスを Gateway アドレスと取り違えないでください。本当にその Mac で第二の Gateway を動かす場合を除きます。
企業プロキシが長寿命 WebSocket をアイドル切断すると、断続的な切断が増幅されます。Runbook にハートビート・再接続・クライアントキャッシュ掃除を書き、モデルが劣化したという誤解を減らしてください。
レビューでは「プロセスがどこで動くか」と「クライアントの既定接続先」を軸にすると、セキュリティと運用の責務分担が早く揃います。
| モード | Gateway の位置 | 典型的なクライアント | 主なリスク |
|---|---|---|---|
| local（既定） | このマシン | ローカル CLI / UI | ローカルポート、トークン、個人セッションの絡み |
| remote | リモートホスト | ローカル CLI / UI が wss://… を指す | URL ドリフト、二重設定、プロキシ切断 |
| Tailscale / トンネル公開 | 対象ホストのループバックまたはバインドのまま | tailnet またはトンネル経由のブラウザ / CLI | ACL、MagicDNS、トークンと bind の組合せ |
| SSH ローカルフォワード | 対象ホスト | リモートポートをノートの 127.0.0.1 に写像 | セッション寿命、踏み台権限、remote URL との連結ミス |
リモートモードが直すのは コントロールプレーンの向き先 です。同じ CLI がノートから 別マシン上の監督者とツールレジストリ に安定して話します。TLS やトークンモデルそのものの代替ではありません。
データセンターまたは VPS で Gateway を常時稼働させ、エンジニアには軽量 CLI だけ持たせたいなら remote は妥当な既定です。UI へゼロトラストで届ける必要があるなら、リモートホスト上で Tailscale Serve を重ね、二つの関心事を一つのスイッチに潰さないでください。
RPC / 1000 の切り分け記事 と併用し、リモートモードではまず現在の CLI セッションがどの Gateway 実体に付いているか確認してからスコープやツール許可を議論してください。誤ったホストを編集し続けるのを防げます。
順序は「リモートを先に健全化し、次にクライアント mode を切り替え、最後にカナリアコマンド」です。上流のトラブルシュート推奨順と揃えています。
リモートでサービスユーザーとして：openclaw gateway status を実行し、Runtime: running と RPC プローブが健全であることを確認します。
リモート WebSocket URL と TLS 終端を記録：リバースプロキシがあるならパス接頭辞とヘルスチェック URL を文書化し、手打ちで一段多い path を付けないようにします。
ノートで現在のプロファイルをスナップショット：openclaw.json または同等の state パスを退避し、local へ一発で戻せるようにします。
gateway.mode=remote と gateway.remote.url を設定：公式の openclaw config set か管理されたテンプレートを使い、散在する手編集を禁止します。
openclaw status / openclaw health を実行：プローブ先と遅延を確認し、二重設定が食い違うなら次へ進みます。
サービスと同一コンテキストで openclaw gateway install --force の後 openclaw gateway restart：本当にローカルサービスを保守するときだけ。純粋なリモートクライアントは install を省略し doctor でドリフトを解消します。
openclaw config set gateway.mode remote openclaw config set gateway.remote.url "wss://gateway.example.internal/v1/ws" openclaw config get gateway.mode openclaw config get gateway.remote.url openclaw status openclaw doctor
ヒント：リモートで Tailscale Serve も有効なら、Tailscale プライベート公開 の ACL とトークン節で wss 終端と内部 DNS が一致するか確認してください。
ロールバックは変更チケットに書きます。旧 local 設定のスナップショットと切替時間帯を残し、大型アップグレード当日は remote URL を凍結してリモートのカナリアが通るまでクライアント設定の一括更新を遅らせます。
staging / prod など複数プロファイルがあるなら、シェル起動時に現在の OPENCLAW_PROFILE を表示し、staging だと思い込み prod に付いているヒューマンエラーを減らします。
症状をクライアント／ゲートウェイ／プロキシの三層に写像すると、無意味な再起動が減ります。
401 / unauthorized：Control UI と CLI のトークンを同源に揃えます。リモートモードではノートが古いデバイストークンを保持していることが多いので、公式のデバイス一覧ローテーションまたは再認可に従ってください。
Runtime running だが RPC probe failed：まず gateway closed(1000) で「誤インスタンス」と「正しいインスタンスだがスコープ不足」を分け、同一時間窓で リモートホスト 上の openclaw logs --follow を取得します。
注意：リモートの待ち受けを確認する前にノートで gateway restart を連打しないでください。ローカルのアイドルプロセスだけが回り、ログが汚れます。
昨日まで動いていた（アップグレード後）：リリースノートで既定認証の強化や WebSocket path の変更がないか確認し、リモートとクライアントのバージョンと digest をチケットに残し、片側だけの更新を避けます。
チャネル系の無音と比べると、リモートモードの問題は 接続とセッション層 に寄ります。メッセージフローを疑うなら channels プローブの記事へ移り、remote URL を試行錯誤しないでください。
常時稼働チームではプローブ失敗率と再接続間隔を既存の可観測性基盤へ送ります。OpenClaw が健康でも企業ネットのジッターは見えるべきです。
以下は社内合意用の目安です。閾値はユーザー規模とリージョンに合わせて調整してください。
wss 終端へのハンドシェイク失敗は 60 秒以内 に DNS / TCP / TLS / WSS の層別チェックでどこで落ちたか特定できること。Config (cli) と Config (service) が食い違う場合の既定手順は 同一ユーザーで install --force → restart → doctor とし、state ディレクトリを記録する。ノート単体で Gateway を動かすとスリープや会議アプリとのポート争いが出ます。リモート CLI だけでは 安定して到達できるコントロールプレーン がなく、VPN のジッターでまとめて落ちます。Gateway を 専有で常時オンラインかつ SSH で保守できる クラウド Mac または VPS に置き、エンジニア端末を remote クライアントに統一するのが 2026 年でもっとも一般的な折衷です。不安定なコンテナやブラックボックス仮想化に監督プロセスを押し込むより、NodeMini の Mac Mini クラウドレンタル は SSH 基線と明確なティア、再現可能なノード像の面で OpenClaw を本番コンポーネントとして統治しやすいです。スペックと価格の比較は レンタル価格、オンボーディングは ヘルプセンター を参照してください。関連記事は OpenClaw カテゴリ から辿れます。
展開時は本 Runbook を内部の環境段階（開発／ステージング／本番）に紐付け、それぞれ別の remote URL とトークンローテーション周期を持たせ、本番 URL を個人設定へ手コピーしないルールを徹底してください。
リモートモードは CLI が別マシンの Gateway に接続します。Tailscale はすでにノートで待ち受けている Gateway を tailnet へ安全に出す側面が強いです。併用可能です。OpenClaw 関連は ブログの OpenClaw 絞り込み も参照してください。
サービスと同一ユーザー・同一 state ディレクトリで openclaw gateway install --force と restart を行い、openclaw doctor で検証します。ノードや請求は ヘルプセンター も参照してください。
環境変数の上書き、シェルプロファイルの残り、gateway.mode がまだ local かを確認してください。Gateway をクラウドで常駐させる算力は レンタル価格 で比較できます。