OpenClaw Gateway コンソール、Webhook、または統合用に安定した HTTPS URL が必要な場合、アプリのポートをインターネットに直接公開することが最終状態になることはほとんどありません。このガイドは、すでにベアメタルまたはリモート Mac 上で OpenClaw を実行しており、公開を計画しているチームを対象としています。ダイレクトプロキシとリバースプロキシの決定表, 最小限の Nginx と Caddy スニペットWebSocket 対応ヘッダーを使用すると、TLS とファイアウォールのチェックリスト、そしてVNC に適した検証パスループバックから別のネットワークへ。クロスリンクは、このサイトの Docker、一般的なエラー、サイレント「応答なし」トラブルシューティングを示しています。
1. プロキシなしでゲートウェイを公開する場合の問題点
- プレーン HTTP と信頼:TLS を使用しないオープン インターネット上の認証情報とコールバックは脆弱です。多くのプロバイダーは HTTPS を必要とします。
- 単純な転送下の WebSocket:ない
Upgrade/Connectionまたは、積極的なタイムアウトは UI では「ランダムな切断」のように見えます。 - より大きな攻撃対象領域:アプリのポートを公開すると、スキャン ノイズが直接増加します。プロキシは、許可リスト、レート制限、一貫したアクセス ログを添付する場所です。
- リモート Mac の盲点:「SSH が機能する」ということは、macOS ファイアウォールとクラウド セキュリティ グループが VNC で表示されるものと一致していることを証明するものではありません。
- Docker 対ホスト リスナー:
127.0.0.1対0.0.0.0プロキシを実行する必要がある場所を変更します。このサイトの公式 Docker ガイドを参照してください。
2. デシジョンテーブル: ダイレクト vs TLS + リバース プロキシ
| 寸法 | ダイレクトパブリックポート | TLS + Nginx/キャディ |
|---|---|---|
| 暗号化 | アプリ内で TLS を終了するか、HTTP を使用し続ける必要があります | TLS をエッジで終了します。アップストリームはループバックで HTTP を維持できる |
| ウェブソケット | すべてのホップが協力する必要がある | Nginx での明示的なヘッダー/タイムアウト。 Caddy は通常、自動的にアップグレードします |
| 複数のサービス | サービスごとに 1 つのポート | 1 つの IP 上の仮想ホスト |
| 運営 | ゼロ日目の可動部品が少ない | 追加サービス、長期にわたる安全性と可観測性の向上 |
| VNC でのトラブルシューティング | テストを重ねるのが難しい | curl -v上流に対して、それから上流に対してhttps://domain |
3. Nginx または Caddy を追加する必要がある場合
- ブックマーク、OAuth リダイレクト、または Webhook には安定したドメインと HTTPS が必要です。
- 適切なアップグレード処理を行わないと、長いパスではリアルタイム UI の動作が低下します。
- 同じリモート Mac 上で他のサイトをホストしており、1 つの証明書ストーリーが必要です。
- ポリシーにより、アプリがループバック状態にある間、インターネットからの 443/80 のみが許可されます。
openclaw doctor機密性の高いサービスをローカルホストにバインドし、それらをプロキシで処理することを提案します (バージョンの出力に従ってください)。
4. 最小限の Nginx: 18789、ホスト、WebSocket
ティーチング スニペット - ホスト名、証明書パス、およびアップストリーム ポートを置き換えます。実稼働用に強化します (暗号、OCSP ステープル、ログ編集、レート制限)。
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 443 ssl http2;
server_name claw.example.com;
ssl_certificate /etc/letsencrypt/live/claw.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/claw.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:18789;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
}
上流への HTTP/1.1 の使用、転送Upgrade/Connection、アプリがクライアント スキームを認識できるように、転送ヘッダーを正直に保ちます。
5. 最小限のキャディ: 自動 HTTPS
claw.example.com {
reverse_proxy 127.0.0.1:18789
}
Caddy は、ACME がポート 80/443 に到達できるときに証明書を取得して更新します。ポリシーの必要に応じて、マッチャー、追加のヘッダー、または IP フィルターを追加します。
6. 証明書、DNS、セキュリティグループ
DNS はパブリック エントリをポイントします
A/AAAA レコードを検証します。 CDN がホストの前面にある場合は、WebSocket とチャレンジ パスが引き続き機能することを確認します。
クラウドファイアウォール
HTTP-01 には 443 を許可しますが、通常は 80 を許可します。アップストリームのループバックを使用する場合は、18789 をパブリック ルール セットから外してください。
VNC の macOS ファイアウォール
システム設定を確認してください。 nginx/caddy を OpenClaw プロセスから区別します。
リニューアルリロード
更新後、サイレントに期限切れにならないように、nginx をリロードするか、Caddy に証明書を取得させます。
レイヤードカールテスト
アップストリーム、ローカル HTTPS、外部ネットワークの順にループバックします。
6b.オプションの IP 許可リストとレート制限
小規模チームの場合は、送信元 IP または VPN 下りによって管理画面を制限します。 Nginxを使用する場合allow/denyまたはWAF。 Caddy では次のようなマッチャーを使用しますremote_ipバージョンのドキュメントごとに。追加limit_req(または同等の) をホット エンドポイント上で実行するため、ブルート フォースや偶発的なループによってゲートウェイがダウンすることはありません。
Webhook の場合は、プロバイダーからの署名検証を優先します。 IP 範囲は変更される可能性があります。許可リストと証明書の有効期限をカレンダーに文書化します。
7. VNC リモート Mac での 7 段階認証
- VNC ターミナルで次を実行します。
openclaw doctorそしてリッスンアドレスが設定と一致していることを確認します。 curl -v http://127.0.0.1:18789/（またはアップストリーム）ステータス コードを確認します。- nginx/caddy 構文を検証し、正常にリロードします。
- 開ける
https://your-domainMac 上のブラウザで。 devtoolsでWebSocket 101を確認します。 - LAN のみの誤検知を回避するために、モバイル データまたは別のネットワークから再テストします。
- サイレント障害をデバッグするときに、プロキシ アクセス ログを OpenClaw ログと関連付けます (応答なしの記事を参照)。
- ファイアウォールを変更した後、伝播を待って外部テストを再実行します。
8. 引用可能なパラメータと関連ガイド
proxy_read_timeout値を指定すると、長期間にわたる接続が切断されます。十分なアップストリーム タイムアウトから始めて、メトリクスに基づいて調整します。インストールエラーと実行時エラーについては、以下を参照してください。よくあるエラーと 10 の修正。無音チャンネルの場合は、次のとおりです応答なしのトラブルシューティング。コンテナの場合は、次から始めますリモート Mac 上の公式 Docker Compose.
終わりに: リモート Mac 上の VNC が依然として役立つ理由
パブリック ゲートウェイのセットアップには、TLS、存続期間の長い接続、および OS レベルのファイアウォールが混在しています。ブラウザとシステム プロンプトを 1 か所で必要とする場合に、SSH だけからデバッグするのは困難です。 VNC 対応のリモート Mac (VNCMac など) をレンタルすると、短期間のプロジェクトにのみ必要なハードウェアを購入することなく、ドクターの実行、プロキシのリロード、WebSocket の検証を視覚的に行うことができます。エッジをロックダウンします。443 の TLS、アップストリームのループバック、このサイトの Docker とトラブルシューティングの投稿をランブックとして使用します。