Service Unavailable と表示される OpenClaw は、単一の障害だけを示しているわけではありません。2026 年 2 月の IceWhale Community スレッドでは、トラブルシューティングにより、必須のゲートウェイトークン、ZimaOS ホストアカウントによる Docker の調査権限不足、そして初期設定を一度も完了していない OpenClaw コンテナという、3 つの異なる層が順に明らかになりました。
このスレッドが特に役立つのは、Big-Bear のパッケージ化されたイメージでは、途中で提案された内容の一部が誤っていることが判明したためです。存在しない GATEWAY_MODE 環境変数を設定しても再起動ループは解消せず、さらに次を追加すると --gateway.mode=local 誤ったコマンドに指定した結果、次のエラーが発生しました。 不明なオプション エラーです。現在の OpenClaw ドキュメントでは、 gateway.mode=local OpenClaw の永続設定に含める必要があり、Docker デプロイメントではオンボーディングまたはセットアップを実行してその設定を作成する必要があります。
まず OpenClaw コンテナが実際に実行されているか確認する
元の投稿では、OpenClaw アプリに、アプリケーションが正常に動作していないというメッセージと、次のヒントが表示されていました。 OPENCLAW_GATEWAY_TOKEN.
アプリケーション設定を変更する前に、ZimaOS または CasaOS ホストからコンテナの状態を確認してください。
docker ps -a | grep openclawコンテナが再起動を繰り返している、または終了している場合は、ログを確認します。
docker logs big-bear-openclaw --tail 100正確なコンテナ名は異なる場合があります。次を実行してください。 docker ps -a 常にこの名前とは限らない実際の名前を特定するには、次を実行します。 big-bear-openclaw.
OPENCLAW_GATEWAY_TOKEN を生成して保存する
最初のコミュニティからの提案は、強力なランダムゲートウェイトークンを生成することでした：
openssl rand -hex 32OpenSSL を利用できない場合、スレッドではローカルでランダムバイトを生成する方法として次を紹介していました：
head -c 32 /dev/urandom | xxd -p -c 32現在の公式 OpenClaw Docker ドキュメントでも、次を使用しています。 OPENCLAW_GATEWAY_TOKEN ゲートウェイ認証用です。標準のセットアップスクリプトはトークンを生成し、デプロイメントの .env ファイルに自動的に書き込まれます。手動でパッケージ化した CasaOS アプリケーションでは、生成された値をそのイメージが想定する環境変数フィールドに入力してください。
このトークンは秘密情報として扱ってください。公開フォーラム、スクリーンショット、サポートチケット、リポジトリには貼り付けないでください。
Docker の権限エラーは OpenClaw の権限エラーではない
トークンを追加した後、元の投稿者は次のエラーに遭遇しました：
Docker デーモンソケットへの接続中に権限がありません
/var/run/docker.sock: 接続: 権限がありません
コミュニティからは、管理者権限が必要な Docker コマンドを実行する前に、一時的に権限を昇格するよう推奨されていました。
sudo -i
docker psroot 権限は、本当に必要なコマンドにのみ使用してください。次の設定を弱めないでください。 /var/run/docker.sock 権限を変更したり、エラーを消すためだけに Docker ソケットを書き込み可能な状態にしたりしないでください。Docker へのアクセスは、実質的にホストの管理者権限を与えることになります。
本当の OpenClaw エラーは「Missing config」でした
Docker ログを確認できるようになると、重要なメッセージが表示されました。
Missing config. Run `openclaw setup` or set `gateway.mode=local`
これは、一般的な Service Unavailable ページよりも実用的でした。現在の OpenClaw ゲートウェイのドキュメントでは、設定に次の内容が含まれていない限り、ゲートウェイは通常どおり起動を拒否すると確認されています。
gateway.mode = local現在の OpenClaw では、次のいずれかも示されています。 openclawのセットアップ または openclaw onboard --mode local ローカルゲートウェイモードを永続設定に書き込みます。
なぜ GATEWAY_MODE=local ではこのイメージを修正できなかったのか
中間のコミュニティ返信では、次を追加するよう提案されていました。
GATEWAY_MODE=localユーザーはこれを試しましたが、再起動ループは続きました。これは重要な訂正事項として残す必要があります。現在の公式 OpenClaw ドキュメントでは、汎用的な GATEWAY_MODE 永続的な設定の代替となる環境変数 gateway.mode このワークフローで使用される設定。
すべてのドット区切りの OpenClaw 設定キーを、独自に作った大文字の環境変数へ変換しないでください。使用している OpenClaw イメージまたはデプロイテンプレートで文書化されている設定方法を使用してください。
なぜ --gateway.mode=local で「Unknown option」が発生したのか
その後、別のコミュニティメンバーが次を追加しました。
--gateway.mode=localCasaOS のコンテナコマンドに追加しました。すると、イメージは次を返しました。
unknown option '--gateway.mode'その理由をスレッドは正しく特定していました。CasaOS は、そのフラグを受け付けないコマンド層に追加していたのです。現在の OpenClaw CLI では、次のようなコマンドが使用されます。 openclaw gateway, openclawのセットアップ, openclaw onboardおよび openclaw config set; gateway.mode これは設定キーであり、コンテナコマンド内のどこにでも配置できる、汎用的なトップレベル実行フラグではありません。
Big-Bear イメージには、初期化済みの永続設定ディレクトリが必要でした
コミュニティでの最終的な診断は、次のマウントに焦点を当てていました。
/DATA/AppData/big-bear-openclaw
→ /home/node/.openclawコンテナは設定を次の場所に置く想定でした /home/node/.openclawただし、マウントされたディレクトリは初期化されていませんでした。これは現在の OpenClaw の Docker ドキュメントと一致します。マウントされた設定ディレクトリには、永続的な openclaw.json認証プロファイルデータと、環境変数から取得するシークレット。
スレッドの最後の提案は、マウントされたディレクトリに実際の OpenClaw 設定が作成されるよう、コンテナ内でセットアップを実行することでした。ただし、元の投稿者はその最後の返信後、最終確認を行っていません。したがって、これはスレッド内で最も有力な診断として扱い、確認済みの最終解決策とは見なさないでください。
新規インストールでは、現在のOpenClaw Dockerオンボーディングを優先する
現在のデプロイでは、エラーを一つずつ追いながら2026年のトラブルシューティング手順を再構成するのではなく、公式のOpenClaw Dockerインストールガイドに従ってください。
現在のOpenClawには、次の処理を行うDockerセットアップスクリプトが用意されています。
- ゲートウェイイメージをビルドまたはプルします。
- オンボーディングを実行します。
- ゲートウェイトークンを生成します。
- 永続的な設定を書き込みます。
- 必要なシークレットディレクトリを作成します。
- Docker Composeを通じてゲートウェイを起動します。
ヘッドレスDockerデプロイでは、現在のOpenClawはローカルゲートウェイモードとトークン認証を使用した非対話型オンボーディングも案内しています。環境変数を手動で作成したり、サポートされていないフラグを追加したりするよりも、この方法が望ましいです。
現在の手動設定パターン
OpenClawの現在のDockerガイドでは、次のような手動パターンを案内しています。
openclaw onboard --mode local --no-install-daemon
openclaw config set gateway.mode local
openclaw config set gateway.bind lanDocker Composeでは、これらのコマンドは通常、プロジェクトで定義された専用のCLIコンテナまたはオンボーディングコンテナを通じて実行します。エントリーポイントとマウントを最初に確認せず、ホスト側のコマンドをパッケージ化されたCasaOSイメージに貼り付けないでください。
現在のOpenClaw Gateway CLIドキュメントでは、openclaw setupとopenclaw onboard --mode localによって、必要なローカルゲートウェイ設定が作成されることが確認できます。
Control UIでも同じゲートウェイトークンを使用する
現在のOpenClaw Dockerドキュメントでは、Control UIを次のポートで公開しています 18789 標準のComposeセットアップで、デプロイ環境のゲートウェイトークンをUI設定に貼り付けるようユーザーに案内します。
トークンの不一致は、ゲートウェイが正常に動作した後に認証エラーを引き起こす可能性がありますが、設定が存在しないためコンテナが繰り返し終了する問題とは異なります。まず起動を診断し、その後UI認証を確認してください。
--allow-unconfiguredを恒久的な解決策にしない
OpenClawには --allow-unconfigured アドホックまたは開発用の起動に使用します。現在のドキュメントでは、設定の書き込みや修復を行わずにローカルモードのガードを回避すると明記されています。テストには便利ですが、永続サーバーの適切なオンボーディングに代わるものではありません。
OpenClawサービスが利用できない場合のトラブルシューティングチェックリスト
- OpenClawコンテナが実行中、終了済み、または再起動を繰り返しているか確認してください。
- 設定を変更する前に、現在のコンテナログを読み取ってください。
- 確認
OPENCLAW_GATEWAY_TOKENが存在し、シークレットとして扱われていること。 - Dockerコマンドでソケットの権限拒否が発生する場合は、Dockerソケットの権限を弱めるのではなく、認証済みの管理者シェルを使用してください。
- 特に次を確認してください
設定がありませんまたはgateway.mode=localエラー。 - ホストのAppDataパスが、イメージで想定されているOpenClaw設定ディレクトリにマウントされていることを確認してください。
- サポートされているOpenClawのセットアップまたはオンボーディングフローを実行し、
openclaw.json永続ストレージに作成されます。 - に依存しないでください
GATEWAY_MODE=localイメージのドキュメントで明示的に定義されている場合を除き、 - を追加しないでください
--gateway.mode=local任意のCasaOSコンテナコマンドに - 設定を書き込んだ後、コンテナを再起動してログを再確認してください。
- ゲートウェイが安定して起動してから、Control UIのトークン認証やモデルプロバイダーの設定をトラブルシューティングしてください。
OpenClawサービス利用不可に関するFAQ
OpenClawにはOPENCLAW_GATEWAY_TOKENが必要ですか？
現在のOpenClawのDockerデプロイでは、一般的に次の値がサポートされ、使用されています OPENCLAW_GATEWAY_TOKEN ゲートウェイ認証用です。公式セットアップスクリプトでは、トークンを自動的に生成できます。サードパーティ製のパッケージ化イメージでは値の公開方法が異なる場合があるため、実際の環境変数スキーマに従ってください。
「permission denied /var/run/docker.sock」とはどういう意味ですか？
現在のホストユーザーがDockerデーモンにアクセスできないという意味です。これだけで、OpenClawの内部データディレクトリに書き込みできないことを意味するわけではありません。Dockerの診断には、認証済みの管理者アカウントを使用してください。
gateway.mode=localを設定するにはどうすればよいですか？
OpenClawがサポートするセットアップ、オンボーディング、または設定コマンドを使用して、値を永続的な openclaw.json。現在のドキュメントには openclawのセットアップ または openclaw onboard --mode local この設定を作成します。
GATEWAY_MODE=localを追加すべきですか？
この提案では解決しませんでした。この提案によって、ユーザーが使用していたパッケージ化イメージの再起動ループは解消されておらず、現在の上流ドキュメントでは gateway.mode を、一般的な環境変数名ではなく設定として GATEWAY_MODE.
--gateway.mode=localが不明なオプションと表示されるのはなぜですか？
CasaOSパッケージで、このオプションが誤ったコマンド階層に追加されたためです。ドット区切りの設定キーが、すべてのOpenClawバイナリやエントリーポイントで自動的に有効なコマンドラインフラグになるわけではありません。
コミュニティスレッドでは、問題は確実に解決しましたか？
スレッドでは、永続構成ディレクトリが初期化されていないことが最終的な有力診断となり、次のコマンドの実行が推奨されました openclawのセットアップ コンテナ内。元の投稿者は、その最後の指示の後に最終確認を投稿していないため、ページでは、情報源にない解決が検証済みであるかのように主張すべきではありません。
