オンボードは通っているのに、CLI やダッシュボードが長くGateway not ready / not readyのままになるのは、多くの場合プロセスが本当にリッスンする前に起きます。サイト内のgateway closed (1000) 切り分け記事（セッション、scope、トークン寄り）とはレイヤーが異なります。本稿はプラットフォーム担当者向けに最短ルートを示します。7 項目でポート、メモリ、タイムアウト、イメージ、ボリューム権限を切り分け、ベアメタル systemd と Dockerの対照表でログの当たりを決め、openclaw doctor とログコマンド例を含む6 ステップ Runbookを実行し、インストール総覧、Docker 本番、観測編と役割分担して読んでください。
not ready は多くの場合、コントロールプレーンがリッスン成功・依存プロセスの準備完了・ヘルスプローブ合格のいずれかをまだ確認できていないことを意味します。WebSocket が張られたあとにポリシーで切断されるケースとは別層です。その場合は先に closed (1000) の記事を参照してください。以下 7 つは、インストール後 1 週間以内のプラットフォーム自己点検用です。
古いプロセスや別サービスによるポート占有：アップグレードや繰り返しの docker compose up のあとも、ホストに古い Gateway が同じポートを握っていると、新プロセスは半起動のまま CLI には not ready だけが出ます。
メモリと swap 不足による OOM：小さな VPS でモデル取得と Gateway を同時に動かすと、Node プロセスが ready 前に落とされることがあります。ログには exit 137 が出るか、無言で消えることが多いです。
起動タイムアウトが短すぎる：コールドプルやネイティブビルドが既定の startupTimeout を超えるとヘルスチェックが早く失敗し、「ずっと not ready」に見えます。
ログの取り違え：systemd と Docker を混在デバッグするとき、コンテナだけ tail してホストの unit がまだ古いバイナリを起動している（またはその逆）を見落とします。
名前付きボリュームの権限と UID マッピング：コンテナユーザーが状態ディレクトリに書けず、Gateway がクラッシュループすると外からは not ready にしか見えません。
イメージ digest と設定のドリフト：compose が :latest を指しているのにキャッシュ層が新しい openclaw.json フィールドと合わず、エントリスクリプトが早期終了します。
ネットワーク問題を起動失敗と誤認：モデルやプラグインレジストリのタイムアウトで初期化に留まる場合、DNS／外向き通信と Gateway 本体を切り分けます。
共通点はサービス可能な状態にプロセスが到達していないことです。そのため status／RPC が「半分だけ緑」に見えます。チケットテンプレートに書き込んだうえで、下の表でログの当たりを決め、journal と docker logs の往復を減らしてください。
クロスプラットフォームのインストール記事は「入る」ところまで、本稿は「上がらない」ところです。観測編は長期メトリクスとアップグレード／ロールバック、本稿は初回 ready 前のハード障害です。
Gateway を専用のリモート Macや小さな Linux VPS で動かすなら、変更レビューに最小メモリとディスク余裕も書き、バージョン固定だけにしないとデモ直前に not ready が集中します。下の表で「どのログを読むか」を一つの判断に落とします。
リッスン面が未確認のまま Gateway を一時的に公網に晒して「疎通確認」をしないでください。セキュリティ強化編の最小露出の順序に従ってください。
not ready を切り分けるとき、最初の分岐は入口の形です。systemd がプロセスを上げるのか、compose がコンテナで上げるのか。混在させると時間を浪費します。
| 観点 | Linux／macOS ベアメタル＋systemd（または launchd） | Docker／Compose |
|---|---|---|
| 最初のログ画面 | journalctl -u <unit> -n 200 --no-pager またはプラットフォーム同等コマンド | docker compose logs --tail=200 <service> で再起動タイムスタンプに揃える |
| ポート競合の確認 | ホストで lsof -nP -iTCP:<port> -sTCP:LISTEN（例示） | ホストとコンテナ内の両方のリスナー、公開ポートと既存ホストサービスの衝突を確認 |
| 権限／ボリューム | 状態ディレクトリの所有者と実行ユーザーの一致 | 名前付きボリュームの UID、読み取り専用ルートと書き込みマウントの分離。Docker 本番編を参照 |
| タイムアウトと再試行 | unit の TimeoutStartSec、Restart= 方針 | healthcheck の start_period、retries とイメージのコールドスタート時間 |
| アップグレード／ロールバックの手がかり | パッケージ版＋最後に良好だった設定バックアップのパス | 固定したイメージ digest＋バージョン管理された compose。観測編のロールバック節と同趣旨 |
「まずリッスンを確かめ、次にセッション」：not ready の段階で最も効くのはポート＋リソース＋正しいログの時間窓であり、先にトークンを変えることではありません。
Ubuntu 24.04＋systemd＋Tunnel 構成では、Tunnel の上流がまだ古いポートを指していないかも確認してください。ずれていると外向きはずっと not ready、ローカルの curl 127.0.0.1 だけ正常に見えます。
Docker では「コンテナは Exited なのに compose が creating のまま」という読み違いがよくあります。docker compose ps -a で終了コードを確認し、ボリューム権限とエントリスクリプトに戻ります。
プロセスがリッスンしプローブも通ったのにクライアントがおかしい場合は、closed (1000) のセッション系の手順に切り替えます。
下の順序は低コストの確認を前に出しています。リソースとポートを確かめてから設定とイメージに触ります。サブコマンドの詳細は利用中の OpenClaw ビルドに合わせてください。
同時リトライを止める：同僚の自動再接続スクリプトを一時停止し、接続ストームで調査が埋もれないようにします。
バージョンとリソースのスナップショット：openclaw --version、uname -a、空きメモリとディスクをチケットに記録します。
ポートと古いプロセスの確認：設定ポートでリッスンを確認し、古い PID があれば systemd／Docker の手順に沿って順に止めてから再起動します。
doctor／validate：openclaw doctor または同等コマンドで不足を直し、再度起動を試します。
起動観測の時間窓を広げる：可能なら一時的に gateway.startupTimeout または compose healthcheck の start_period を上げ、「遅い」のか「死んでいる」のかを分けます。
最小受け入れ：ローカルの curl ヘルスまたは公式 status サブコマンドが ready を返したら他利用者を戻します。まだ失敗する場合は第 4 節のログ抜きでエスカレーションします。
openclaw --version openclaw doctor # systemd の例: # journalctl -u openclaw-gateway -n 120 --no-pager # Docker の例: # docker compose logs --tail=120 gateway # その後、ディストリの手順に従って unit／compose サービスを再起動
ヒント：CLI にモデルやプラグインのダウンロードタイムアウトが出る場合は、外向き通信と Gateway 本体を分けます。メンテナンス枠で一時的に egress 許可を広げ、あとで再び絞ります。詳しくは セキュリティ強化編 を参照してください。
インストール総覧と整合させます。Anthropic の課金や API キー形態を変えた直後は、環境変数と設定ファイルを同一ソースに揃えないと、鍵のパースでブロックして not ready に見えることがあります。
専用リモート Mac で Gateway を長期稼働させる場合は、launchd／unit の自動再起動とディスク掃除を同じ Runbook に書き、ログでディスクが満杯になって not ready がループするのを防ぎます。
下の「口頭表現 → アクション」をオンコールチャンネルに固定するとノイズが減ります。WebSocket のクローズコードが絡むなら closed (1000) に切り替えてください。
ポートが使用中：古いプロセスを止めてから新しいプロセスを上げ、ポートを空けないまま scale しない。メモリ不足：並列度を下げるか swap／スペックを上げてからパラメータ調整。イメージ取得失敗：先に docker pull またはレジストリ資格情報を直し、そのあと Gateway 設定を見ます。
注意：本番で記録なく docker system prune 系を試さないでください。使用中の名前付きボリュームのバックアップまで消えることがあります。掃除手順は変更票に書きます。
観測編と連携し、not ready 解消後に根本原因ラベル（ポート／メモリ／イメージ／ボリューム）をダッシュボードに残し、翌週同じクラスが再オープンされないようにします。
Gateway と MCP 子プロセスを同じホストで動かす場合、起動段階で子プロセスの実行パスとサンドボックスのマウントがコンテナ内から見えるかも確認します。見えないとツール発見で親がブロックします。
チーム横断で揃えるためのフィールドです。外部共有前にマスキングしてください。
個人ノートだけで Gateway を動かすとスリープや OS アップデートに弱く、メモリの小さい VPS はコールドスタートで OOM しがちです。OpenClaw と周辺ツールチェーンのために長期稼働で契約上明確な macOS 実行層が必要なら、専用リモート Macの方が端末の貸し借りより安定しやすいです。バラバラな自前機より、NodeMini の Mac mini クラウドレンタルは固定 SSH とディスク段階がはっきりしており、「Gateway＋ツールチェーン」をエステートのノードのように引き継ぎやすくします。仕様と料金は レンタル料金、接続や運用の質問は ヘルプセンター、OpenClaw シリーズは ブログの OpenClaw カテゴリから入ってください。
プロセスがリッスンしておらず、ポート・メモリ・タイムアウトが疑わしいときは本稿。WebSocket が張られたあとにポリシーやセッションで閉じられたときは closed (1000) の記事です。実行層の容量やオンボーディングの計画には レンタル料金 と ヘルプセンター も参照してください。
同一時間帯の docker compose logs --tail=120 gateway とホスト側の dmesg／リソーススナップショットです。ボリューム権限が疑わしい場合は docker compose ps -a の終了コードも添付します。
ブログの OpenClaw カテゴリからインストール、Docker、systemd、セキュリティ、観測、MCP の各記事へ進みます。本稿は「起動しない」段階向けです。