2026年 OpenClaw Docker on VPS の立ち上げトラブルシュート
Exit 137 と Control UI エラーの対照表

前提リソース：free -h、mem_limit、初回WASMビルドの「固まり」との見分け方

OpenClaw Gateway がコンテナ内で初回起動するとき、CPUが張り付いたままポートが開かない 多くはWASMサンドボックスのビルド段階であり、デッドロックではありません。v2026.4 インストール長文 のリソース推奨に合わせます。ホストの空きメモリと mem_limit の両方が厳しすぎると、Linux の OOM が Exit 137 を返し、ログには親切なエラーが間に合わないことがあります。

1. 01

   ホスト側： ホストで free -h を実行し、利用可能メモリがおおよそ 1.5～2 GiB の余裕を常時下回っていないか確認します。swap が 0 のときは137が出やすくなります。

2. 02

   Compose側： サービスに mem_limit: 2g 以上を設定し、同一マシン上の重いサービスとメモリを奪い合わないようにします。

3. 03

   初回ウィンドウ： コールドスタートでは失敗判定の前に 3～7分 を見込みます。その間は docker logs -f でビルドチェーンが動いているか観察します。

4. 04

   ヘルスチェック： healthcheck.start_period は少なくとも 360s を推奨し、WASM完了前に compose が誤って再起動しないようにします。

5. 05

   誤判定の抑制： 初回ウィンドウ内で連続して docker compose restart しないでください。毎回コールドビルドのピークが再発火します。

この5行を「VPSにOpenClawを載せる」Runbookの表紙に書くと、「手順どおりなのに起きない」チケットを大きく減らせます。Gateway のレイヤー別の詳細は 運用期三段の長文 を参照してください。

Control UI、127.0.0.1 バインド、リバースプロキシ：allowedOrigins と Host オプションの選び方

VPS上で 18789 を公網に晒すのはよくある誤設定です。インストール長文 では コンテナはループバックのみにバインド し、TLSはCaddyまたはNginxで443側で終端することを推奨しています。Control UI の non-loopback 系エラーは、ブラウザのオリジンとGatewayが許可するOriginが一致していないことが本質で、「Dockerが壊れた」わけではありません。

{
  "gateway": {
    "mode": "local",
    "controlUi": {
      "allowedOrigins": ["https://openclaw.example.com"]
    }
  }
}

コピー用compose骨子、本番前10チェック、「ノートPC常時起動」の代替案

次の三つはコミュニティと本番でよく使う レビュー帯 です。自ホストの実測に置き換え、READMEに書くと新人が同じ穴に落ちにくくなります。

• 初回起動の見積もり： コールドスタートではチケットを開く前に少なくとも 3～7分 を見込みます。3分未満で再起動すると137が増えやすくなります。
• メモリ水位： 単一インスタンスではホスト空きメモリを常時 2 GiB 以上の余裕を確保するのが目安です。この帯を下回るなら機能追加より昇格を優先します。
• ログローテーション： Docker json-file は 単一ファイル10MiB以下、保持3個以下 に抑え、ディスク満杯による二次障害を避けます。

services:
  openclaw:
    image: ghcr.io/openclaw/openclaw:latest
    restart: unless-stopped
    mem_limit: 2g
    ports:
      - "127.0.0.1:18789:18789"
    volumes:
      - ${HOME}/.openclaw:/home/node/.openclaw
    env_file:
      - .env
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:18789/health"]
      interval: 60s
      timeout: 15s
      retries: 5
      start_period: 360s

ノートPCでGatewayを長時間動かすと、スリープ、蓋閉じ、不安定な上り回線 に引きずられがちです。家庭用回線だけではSLAを契約どおりに測りにくい面もあります。対照的に、期間課金のクラウドMac Miniノード は、VPS上のOpenClawとmacOSやXcode側作業を組み合わせるハイブリッド向きです。

Dockerゲートウェイを安定稼働 させつつ、重いビルドや実機作業を 契約可能なmacOS環境 に寄せたい場合、自前資産の調達と多地点同期では不利になりがちです。7×24で検収できるノードと弾力的なスペック が欲しい場面では、VpsMesh のクラウドMac Miniレンタルがより現実的な解 になります。VPS上のOpenClawと専用リモートMacの役割分担をアーキテクチャ図に書き、容量レビューは口約束ではなく 料金ページ と 注文ページ で進めると着地しやすくなります。