2026 OpenClaw Gateway × Tailscale
プライベートトンネル、ループバックとリモート CLI のトラブルシュート

なぜ「待ち受けを 0.0.0.0 にする」が、2026 年の定番解ではないか

OpenClaw Gateway は既定で制御面を 127.0.0.1 にバインドします。意図は、攻撃面を OS が約束する境界の内側に閉じることにあり、WebSocket／HTTP の制御面を直接触れられるのは同一ホスト上のプロセスに限られます。初回デプロイで「遠隔から openclaw したい」からといって、いきなり待ち受けを 0.0.0.0 に変え、手作業の fw で補う、という流れはデモ向きには成り立っても、本番では 無許可のスキャン、トークン漏えい、CORS 誤設定を同時に増幅しがちです。

1. 01

   走査面が桁違いに膨らみます。いったんポートがインターネットに見えると、数時間のうちにボット走査に当たります。仮に強いトークンを置いていても、ログはノイズで埋まり、SOC 側のアラート収束は難しくなります。

2. 02

   「露出面の最小化」と矛盾します。本サイトの Gateway 向け安全強化 では、ループバック、トークン入れ替え、実行承認を前提にしています。bind をインターネット側へ開くのは、第一関門を自分から外す行為です。

3. 03

   切り分けの信号が汚れます。インターネット経路では CDN やキャリアの NAT、社内プロキシが重なります。問題を OpenClaw 本体に帰属させがちですが、実際には half-close や MTU 由来の揺れが入り交じります。

4. 04

   監査向きではありません。「どのグローバル IP からエージェント制御面に入ったか」が、自然人に対応づきにくい形になります。プライベートの tailnet 上の身元（マシンに紐づく主体と ACL）のほうが、手順に書きやすいです。

5. 05

   複数 Gateway 構成のときに衝突しやすいです。同一ホストで二つ目のインスタンスを試す段階で、ポート衝突とトークン混在の確率が上がります。

6. 06

   遠隔 Mac 前提の作業配分と噛み合いません。長期に算力を要するのは Xcode、シミュレータ、大きなキャッシュの類です。Gateway は軽量のままにし、専有ノードへ重い処理を逃がすほうが自然です。

心がけるべき姿勢は、Gateway はループバックのまま、到達性は制御したネットワーク層（Tailscale など）で与えることです。データベースを 127.0.0.1 だけに束ね、SSH トンネル越しに触る、というのと同型の習慣に近いです。Cloudflare Tunnel に慣れている場合は、まず Linux VPS ＋ systemd ＋ Cloudflare Tunnel の「エッジの入口」が本文の「tailnet 内・ループバック中心」とどこが違うかを併せて把握すると、設計図を描きやすくなります。

Tailscale 側：MagicDNS、ACL、「運用端末からだけ Gateway へ」という受け入れ基準

Gateway ホストに Tailscale を入れログインしたら、同一 tailnet 上のノートから ping と tailscale ping の RTT を測ります。次に管理コンソールで、当該ノードに想定のタグが付いているか、MagicDNS が有効か、ACL が運用子網から Gateway 役へ TCP 18789（または自前の番号）を明示で許可しているかを照合します。

// ACL 断片の例：tag:ops の端末からだけ Gateway ノードの 18789 を許可
{
  "groups": { "group:ops": ["alice@github", "bob@github"] },
  "tagOwners": { "tag:gateway": ["group:ops"] },
  "acls": [
    {
      "action": "accept",
      "src":    ["tag:ops"],
      "dst":    ["tag:gateway:18789"]
    }
  ]
}

受け入れ基準のチェックは変更票に必ず落とし、① Gateway プロセスは依然として 127.0.0.1:18789 である、② 運用端末から、SSH ローカル転送抜きで tailnet IP 越しに同一のヘルス用エンドポイントが応答する（パスはデプロイした版に合わせる）、③ インターネット向けのセキュリティグループで 18789 への着信をすべて止めてある、を満たすこと。「チャンネル経由のメッセージが来ない」系は channels プローブと dmPolicy のゲーティング の記事と突き合わせるのが有効です。

症状の当たり付けと、手順に書き残したい三つの枠

小さな版の上げ直しの直後にだけ、「同じ ACL、同じトークンで、遠隔 CLI にだけ不具合が出る」形になったなら、まずリリースノート上の破壊的変更と既定の番号表を突き合わせ、一つ前の安定版に戻して二分割します。待ち受けの行列を確認する前に ACL を幾度も差し替えない方が、工番に偽陽性が積もりにくいです。

• 既定の番号と変更コスト： OpenClaw Gateway 周辺のエコシステムでは、多路化された制御面に 18789 を前提にしていることが多いです（正式な数は当該リリースの説明に従います）。番号を動かすなら、systemd、Docker Compose、クライアントの remote の三箇所で一斉に揃えないと「どこか一つが古い番号を見ている」状態に陥りがちです。
• 閉域上の RTT と操作感： tailnet が大陸をまたいでも、片道 80〜150ms 程度の遅延なら、CLI 操作はまだ成り立つことが多いです。往復が多いツール呼び出しは、チャット的な手数より、まとまったスクリプト化の方が体感的な待ちに強いです。
• 身元とホストの寿命： tag:gateway など、役割用のラベルを付けておくと、ACL 行数はチームの人数に近いペースで伸びます。手順に「退職と同時に端末失効＋ tailnet から外す」を固定の一行で書くと、あとで詰まりにくいです。

インターネットへ生の bindを当てにするか、ACL を広すぎる tailnet のどちらかに寄せると、2026 年のエージェント制御面を監査可能な形に保つことは難しくなります。一方、重い演算をすべて Gateway と同居する小さな一台の VPS に乗せると、メモリとディスクの両方で早く踏み抜けます。前者はネットワーク上の層の厚みが足りず、後者はクラウドホストのように横展開しにくい実行面が足りない、という整理になります。

目指す積み方は、Gateway は軽量の常駐、到達面は閉域のトンネルで畳み、重い作業負荷は専有の macOS ノードへです。Xcode ツールチェーンを安定的に使い、長期セッションを前提に、ディスク水準まで契約に書ける必要があるなら、NodeMini の Mac Mini クラウドレンタルは、多くの局面で理にかなう選択です。