OpenClaw GatewayをLAN内で使っていて、
「HTTPではなくHTTPSで接続した方が安全なのでは？」と考えていませんか？
たしかにHTTPS化は通信保護として有効です。
しかし、OpenClawのようにWebSocketやControl UIを使うツールでは、安易にSSL化すると一部機能が動かなくなることがあります。
この記事では、OpenClaw GatewayをSSL化する方法と、
動作不良が起きたときにHTTP接続へ戻す手順を整理します。
よこやま良平ITエンジニアとして20年以上WordPressやサーバーまわりのトラブル対応に携わってきたよこやま良平です。わたしの現場経験をもとに、設定変更で起きやすい落とし穴と安全な戻し方を解説します。
- OpenClaw GatewayをHTTPS化する基本手順
- HTTPS化で一部機能が動かなくなる理由
- HTTP接続へ戻すための解除コマンド
- LAN内でOpenClawを使うときの現実的な判断基準
結論から言うと、OpenClaw GatewayはHTTPS化できます。
ただし、自己署名証明書・WebSocket・ブラウザのセキュリティ制約が絡むため、すべての環境で安定するとは限りません。
LAN内だけで使う場合は、トークン認証を有効にしたHTTP運用の方が安定するケースもあります。
まずは仕組みと戻し方を把握してから設定しましょう。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
OpenClawをSSL化する前に確認すべきこと
OpenClawをSSL化する前に、まず現在のGatewayがHTTPで正常に動いているか確認することが重要です。
正常な状態を把握しないままHTTPS化すると、問題がSSL設定なのか元の接続なのか判断できなくなります。
OpenClaw Gatewayは、ブラウザで表示するControl UIだけでなく、
内部的にはWebSocket接続も使います。HTTPなら `ws://`、HTTPSなら `wss://` の接続に切り替わります。
現在のGateway状態を確認する
まずは以下のコマンドで、Gatewayの状態・URL・疎通確認を見ます。
openclaw gateway statusHTTP接続で正常に動いている場合、表示の中に次のような情報が出ます。
Dashboard: http://192.168.1.2:1234567/
Probe target: ws://127.0.0.1:1234567
Connectivity probe: ok- `Dashboard` が現在アクセスすべきURL
- `Probe target` が内部のWebSocket接続先
- `Connectivity probe: ok` ならGateway自体は動作中
allowedOriginsだけではSSL化されない
よくある誤解が、`allowedOrigins` に `https://…` を追加すればSSL化されるというものです。
これは正しくありません。
`allowedOrigins` は「どのURLからのアクセスを許可するか」を決める設定です。
GatewayそのものをHTTPSで待ち受けさせる設定ではありません。
`allowedOrigins` にHTTPSのURLを追加しても、
Gateway側でTLSが有効になっていなければSSL接続はできません。
OpenClawをSSL化する設定コマンド
OpenClawをSSL化するには、`gateway.tls` を有効にします。
試験的に使うだけなら、自動生成証明書を使う方法が一番簡単です。
ただし、自動生成証明書は自己署名証明書です。
ブラウザで警告が出る可能性があるため、業務利用や外部公開には向きません。
自動生成証明書でHTTPS化する
以下は、GatewayをHTTPSで待ち受けるようにする設定例です。
IPアドレスやポートは利用環境に合わせて変更してください。
openclaw config patch --stdin <<'JSON5'
{
gateway: {
tls: {
enabled: true,
autoGenerate: true
},
controlUi: {
allowedOrigins: [
"https://192.168.1.2:1234567",
"https://localhost:1234567",
"https://127.0.0.1:1234567",
"http://192.168.11.2:1234567",
"http://localhost:1234567",
"http://127.0.0.1:1234567"
]
}
}
}
JSON5
openclaw config validate
openclaw gateway restart再起動後、状態確認で `Dashboard` が `https://…`、
`Probe target` が `wss://…` になっていればHTTPS化は反映されています。
Dashboard: https://192.168.1.2:1234567/
Probe target: wss://127.0.0.1:1234567
Connectivity probe: ok自己署名証明書の警告は避けられないことがある
`autoGenerate: true` は、OpenClaw側で証明書を自動作成する設定です。
手軽ですが、ブラウザやスマホから見ると「信頼されていない証明書」と判断される場合があります。
これはOpenClawが壊れているわけではありません。
証明書を発行した機関をブラウザが信頼していないために起きる警告です。
- 信頼済み証明書を用意する
- DNS名と証明書の名前を一致させる
- 証明書更新の運用を決める
- WebSocketの `wss://` 接続まで確認する
OpenClawを安易にSSL化すると動作しなくなる理由
OpenClawのSSL化で一部機能が動かなくなる理由は、
画面表示だけでなく、内部通信・ブラウザ制約・証明書信頼が同時に変わるためです。
単純なWebページならHTTPS化して終わりですが、
Gateway系ツールはWebSocketやControl UIの接続先も含めて整合性を取る必要があります。
HTTPからHTTPSに変えるとWebSocketも変わる
HTTP接続では、WebSocketは `ws://` で接続されます。
HTTPS接続では、通常 `wss://` に切り替わります。
この切り替えで、ブラウザ・Gateway・証明書のどこかに不整合があると、
画面は開けても一部操作が動かない状態になることがあります。
ブラウザの保存状態が初期化されたように見えることがある
同じIPアドレスでも、`http://` と `https://` は別のオリジンとして扱われます。
そのため、ブラウザのLocalStorageや設定が別扱いになり、表示が初期化されたように見えることがあります。
これはデータが消えたというより、ブラウザが別サイトとして扱っている状態です。
OpenClawの表示設定やセッション状態が変わったように感じる原因になります。
自己署名証明書は端末ごとに信頼が必要
Mac本体では開けても、別のPCやスマホでは警告が出ることがあります。
自己署名証明書は、接続する端末ごとに信頼設定が必要になる場合があるためです。
LAN内で複数端末からOpenClawにアクセスする場合、
この証明書まわりの手間がHTTP運用より大きくなることがあります。
- ログイン画面や表示設定が初期化されたように見える
- 画面は開くが一部ボタンや通信が動かない
- ブラウザや端末によって接続可否が違う
- HTTPでは動くのにHTTPSでは不安定になる
OpenClawをHTTP接続へ戻す解除手順
HTTPS化後に一部機能が動かない場合は、まずHTTP接続へ戻すのが安全です。
原因調査を続ける前に、正常に動いていた状態へ戻せることを確認しましょう。
以下の例では、`gateway.tls` を無効化し、
`allowedOrigins` もHTTPのURLだけに戻しています。
TLSを無効化してHTTPへ戻す
openclaw config patch --stdin <<'JSON5'
{
gateway: {
tls: {
enabled: false,
autoGenerate: false
},
controlUi: {
allowedOrigins: [
"http://192.168.1.2:1234567",
"http://localhost:1234567",
"http://127.0.0.1:1234567"
]
}
}
}
JSON5
openclaw config validate
openclaw gateway restart再起動後に、以下のように `http://` と `ws://` に戻っていればHTTP運用へ戻っています。
Dashboard: http://192.168.1.2:1234567/
Probe target: ws://127.0.0.1:1234567
Connectivity probe: okHTTP接続の疎通を確認する
ターミナルからHTTPで応答するか確認する場合は、以下のように `curl` を使います。
curl -I --max-time 5 http://127.0.0.1:1234567/`HTTP/1.1 200 OK` が返ってくれば、HTTP側のControl UIは応答しています。
そのうえでブラウザから `http://192.168.11.2:18789/` にアクセスしてください。
OpenClawはLAN内ならHTTP運用でも現実的
OpenClawをLAN内だけで使うなら、HTTP運用も現実的な選択肢です。
特にHTTPS化で動作が不安定になる場合は、安定性を優先した方がよい場面があります。
もちろん、インターネットに直接公開するならHTTPS化は必須です。
しかし、家庭内LANや社内LANの限定利用であれば、まずは認証とネットワーク制限を重視する判断もあります。
トークン認証を有効にしておく
HTTP運用に戻す場合でも、認証なしで使うのは避けるべきです。
OpenClaw Gatewayはトークン認証を有効にしておくのが基本です。
NEW_TOKEN=$(openssl rand -base64 32)
echo "$NEW_TOKEN"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$NEW_TOKEN"
openclaw gateway restart`echo “$NEW_TOKEN”` で表示されたトークンを、Gatewayのログイン画面に入力します。
トークンを知らない端末からは操作できない状態にしておくことが大切です。
外部公開するならHTTPのまま使わない
HTTP運用が現実的なのは、あくまで信頼できるLAN内で使う場合です。
インターネットへ直接公開するなら、HTTPのまま使うべきではありません。
外部公開する場合は、正式な証明書・DNS名・リバースプロキシ・ファイアウォールを含めて設計します。
単に `https://` で開けるかどうかだけで判断しないようにしましょう。
- LAN内だけで使う
- トークン認証を有効にする
- 不要なポート公開をしない
- 外部公開時は正式なHTTPS構成にする
OpenClawのSSL化でよくある質問
OpenClawのSSL化は戻せる前提で試すのが安全
OpenClaw GatewayはSSL化できますが、安易にHTTPSへ切り替えると、
表示設定の初期化・WebSocket接続不良・端末ごとの証明書警告が起きることがあります。
特にLAN内で安定して使えている場合は、HTTPS化そのものよりも、
トークン認証・ポート公開範囲・Gatewayの稼働確認を優先する方が現実的です。
SSL化を試すなら、必ずHTTPへ戻すコマンドも手元に用意してから実行しましょう。
設定変更後は `openclaw gateway status` で、Dashboard URLとProbe targetを確認するのが基本です。
サーバー設定変更後の不具合が自分で解決できない時は
ホームページの乗っ取り・マルウェア感染・不正アクセスでお困りなら、
クイックレスキューが解決します。
- サーバー設定を変えたら管理画面に入れなくなった
- SSL化やリダイレクト設定後にサイトが表示されない
- ホームページが乗っ取られた・改ざんされた
- Googleに危険なサイトと表示されている
- 自分で復旧しようとしたが直らない
- WordPressを安全に復旧・修正したい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
