2026 年に OpenClaw Gateway がパブリック ネットワークに公開されると、5 つの層の障害はそれぞれどのようになるでしょうか?
最初の層はクラウドベンダーのセキュリティグループと境界ACL:マシン内部の監視は正常に行われていますが、公衆回線の入り口からは入れません。通常、受信ルールは 22 と 80 のみを開き、18789 や実際に公開する外部ポートが許可リストに入っていないことが多いです。二つ目の層はホスト側ファイアウォールです。Ubuntu の ufw、CentOS の firewalld、イメージ既定の deny 方針は、セキュリティグループで NIC を開けたあとも背後でパケットを落とします。三つ目の層はリバースプロキシと WebSocketです。Nginx や Caddy が Upgrade と Connection を正しく透過しないと、ブラウザ側ではハンドシェイク失敗や再接続ループに見えますが、Gateway プロセス自体はまだ健全なままです。
4番目の層は、ゲートウェイのバインドと認証: 監視をループバックから LAN またはカスタム アドレスに変更すると、公式のガードレールではトークンまたは同等の認証が必要になります。これが欠落している場合は、「バインドを拒否する」か、「バインドはできるが、コントロール プレーンが RPC 検出を完了できない」ことになります。 5階は、チャネルと戦略: Telegram、Discord、Webhook のいずれかの側のレート制限、ペアリング ステータス、グループ ポリシー、DM ポリシーにより、「ゲートウェイはオンラインですがビジネス側が認識していない」という現象がログに表示されます。
5 つのレイヤーを分離した後は、エラーが発生するたびに再インストールする必要はありません。次のセクションの表は、ネットワーク入口の問題、コントロール プレーン構成の問題、またはチャネル製品の問題のいずれを解決しているかを判断するために使用されます。
セキュリティグループ:パブリック IP からの最小のプローブを使用してポートが到達可能であることを確認し、比較のためにイントラネットにフォールバックします。
ホストファイアウォール:「両方の層がもう一方の層がそれを許可すると考える」ことを避けるために、セキュリティ グループのルールを照合してください。
リバースプロキシ:TLS 終端ポイントがアップストリーム プロトコルと一致していること、および WebSocket ヘッダーが変更されずに転送されていることを確認します。
バインディングと認証:チェックgateway.mode、gateway.bindそしてgateway.auth同じ一連の仮定。
通路:バンドルchannels status --probeプロバイダーコンソールのタイムスタンプと一致します。
このサイトの記事「OpenClaw のインストールからゲートウェイ接続まで」をすでに読んでいる場合は、この記事を「パブリック ネットワークへの入り口とリバースプロキシに関する特別章」と考えることができます。その記事ではインストールとデーモン プロセスの受け入れについて説明し、この記事では外部ネットワーク パスと WebSocket の詳細について説明します。 2 つの記事を重ねて「全天候型の安定運用とクラウド ノード ソリューション」を読むと、モチベーション、コマンド ライン、ネットワーク層を一度に調整できます。
ループバック、LAN、テールネットを監視およびバインドする際の認証と暴露を比較する方法
ループバック バインディングは最小限に公開され、同じマシン上でのみコントロール プレーンを使用するのに適しています。別のラップトップでダッシュボードを開こうとすると、監視を非ループバック アドレスに拡張する必要があります。現時点では、認証はオプションではなく、ガードレールです。 LAN バインディングでは、どのネットワーク カードとネットワーク セグメントが信頼できるかを明確にする必要があります。テールネットまたはゼロトラスト トンネルのシナリオでは、「誰が内部ネットワークとしてカウントされるか」をチームの合意として記述する必要があります。そうしないと、デバッグ中に間違ったレイヤーに繰り返しジャンプしてしまいます。
| 観点 | ループバックバインディングのみ | 非ループバインディング + リバースプロキシ |
|---|---|---|
| 露出面 | 少なくとも、デフォルトでは外部ネットワークにアクセスできません | セキュリティグループ、ファイアウォール、TLS、トークンの組み合わせの管理が必要 |
| ダッシュボードのエクスペリエンス | SSHトンネルまたはピアアクセスが必要です | 利用可能なドメイン名と証明書。チームがコントロール プレーンを共有するのに適しています。 |
| トラブルシューティングの順序 | ゲートウェイとドクターを優先する | まずポートとリバースプロキシを見て、次にゲートウェイとドクターを見てみましょう |
| 一般的なリスク | ループバック専用アドレスをパブリック ネットワークで使用可能なアドレスと間違える | トークンなしのリバースプロキシの Upgrade 欠落または非ループバック |
| VPSとの互換性 | 一時的なテストに最適 | ゲートウェイを長期的なコントロール プレーン コンポーネントとして使用するのに適しています |
パブリック ネットワークのトラブルシューティングの最初の原則は、まずパケットが到着できることを証明し、次にハンドシェイクが通過できることを証明し、最後にビジネス ロジックがオンラインであることを証明することです。
Gateway を VPS 上に配置しても、スタックの再コンパイルとブラウザ ツールのロードが同じマシン上で行われる場合、競合が増幅されて「ランダムな異常」が発生します。多くの場合、コントロール プレーンと重い負荷を異なるベア メタル インスタンスに分割する方が、JVM スタイルのパラメーターを繰り返し調整するよりも効果的です。並列処理とリース期間を組み合わせる必要がある場合は、同日に公開された記事「Mac mini M4 Buy or Rent TCO」を参照して、予算とマイルストーンを結び付けて検討できます。
Nginx または Caddy を使用して OpenClaw ゲートウェイをリバースする場合の、WebSocket の透過的な送信スケルトンのアップグレード
次のスケルトンは、WebSocket に関連する主要な命令のみを意図的に保持しています。コアは次のとおりです。proxy_http_version 1.1、UpgradeそしてConnection頭。 TLS がリバースプロキシで終了すると、アップストリームは平文ループバックを使用できます。エンドツーエンド TLS に変更する場合は、アップストリーム プロトコルと証明書検証用に別のリストのセットを作成する必要があります。 Runbook の同じページで 2 つの前提条件を混在させないでください。
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 443 ssl;
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;
}
}
ヒント:リバースプロキシ層に IP 制限または地理的ブロックを実装している場合は、チャネル プロバイダーのコールバック エントリをホワイトリストに登録することを忘れないでください。そうしないと、「ヘルス チェックが常に緑色で、実際のメッセージが受信できない」などの誤検知が発生します。
Caddy のルートは自動証明書と短いサイト ファイルですが、WebSocket の透過的な送信の原則は変わりません。これは依然として HTTP/1.1 アップグレード セマンティクスであり、正しいものです。Host透明な伝送。どのリバースプロキシセットを選択する場合でも、同僚の半数が古い IP にアクセスし、同僚の半数が新しいドメイン名にアクセスして、OAuth とコールバック ドメイン名の間に不一致が生じることを避けるために、チーム文書に「リバースプロキシ後の最終 URL」を記述することをお勧めします。
「外部ネットワークが接続できない」を収束する入口からチャネル層までの6つのステップ
次のシーケンスでは、意図的に「ローカル カール」を一番下に配置しています。パブリック ネットワークの問題は、内部ネットワークの観点から騙されるのを避けるために、まず外部ネットワーク プローブで検証されます。各ステップの出力を作業指示書に貼り付けると、オンコールの引き継ぎがはるかに簡単になります。
到達 URL を固定する:ダッシュボードが最終的に叩くドメインとポート、TLS 終端の有無をメモし、HTTP と HTTPS や別ドメインを混ぜた検証を避けます。
外部ネットワーク プローブ ポートから:セキュリティ グループのスクリーンショットと一致して、別のネットワーク パスを使用して 443 または 18789 に到達できることを確認します。
ホストのファイアウォールを確認します。ufw または firewalld ルールをリストして、ローカル拒否がグローバル パスをオーバーライドしていないことを確認します。
WebSocket を確認します。ブラウザのネットワーク パネルまたはカールを使用してリクエストを手動でアップグレードし、リクエストが 101 かどうかを確認します。
ゲートウェイに戻る:openclaw gateway status と openclaw doctor を実行し、bind とトークンの前提がリバースプロキシ層で隠れていないか確認します。
検証チャネル:埋め込むopenclaw channels status --probe、プロバイダ側の電流制限とペアリングのステータスを一緒に記録します。
01 ~ 04 が緑、05 が赤の場合は、構成のドリフトまたはアップグレード後のデフォルト値の変更が最初に疑われます。 05 が緑、06 が赤の場合は、急いでゲートウェイを再起動せず、まずチャネルを独立したサブシステムとして扱います。
変更レビューに書き込むことができる 3 つの基準とクラウド上の永続的な分業
ポートとプロトコルの適合性:パブリック ネットワークの入り口が 443 を使用して TLS を終了する場合、すべてのブックマーク、OAuth コールバック、および Webhook URL を同時に同じドメイン名空間に書き換える必要があります。そうしないと、「ローカルで使用可能」と「グローバルで使用不可」の間で変動します。
レイヤリングを検出します。「ポート到達可能」、「HTTP 200」、「WebSocket 101」、「ゲートウェイ RPC OK」、「チャネル準備完了」を 5 つのレベルの信号に分割し、あるレベルを別のレベルの結論に置き換えることを禁止します。
コントロール プレーンはコンピューティング パワー プレーンから分離されています。同じマシンで高負荷の IDE または並列シミュレーターも実行している場合は、スワップを無限に増やすのではなく、競合を減らすために、ゲートウェイを独立したベア メタル ノードに移動することを評価する必要があります。
知らせ:認証を行わずにゲートウェイをパブリック ネットワークに直接接続することは、運用事故のリスクが高いモードです。必ず公式のガードレールに従ってトークンまたは同等のコントロール プレーン認証を設定し、変更を監査ログに記録してください。
いつでも閉じられる可能性があるラップトップにゲートウェイを結び付けると、TLS、コールバック ドメイン名、トークンの更新が監査できない個人の習慣に結び付けられます。重い負荷とブラウザ ツール チェーンを同じ VPS に結び付けると、「ネットワークは正常に見えます」と「ランダムなプロセスのジッター」が同じブラック ボックスに混在します。比較すると、MESHLAUNCHによるMac Miniクラウドベアメタルレンタル独自の Apple Silicon、日次、週次、月次ベースでの柔軟な注文と複数地域の切り替えを提供し、実稼働コンポーネントとしての OpenClaw コントロール サーフェスの長期運用により適しています。最初に開けてもいいよレンタル料金ページコントロール サーフェスとコンストラクション サーフェスのレベルをそれぞれ 1 つ選択し、ヘルプセンターSSH とネットワークの要件を確認します。動機と背景は組み合わせることができる全天候型クラウドノードソリューションそして医師による取り付けとトラブルシューティング両方の記事を一緒にレビューします。
はい、一般的な競合は、ポートの占有と 2 セットの構成ルート ディレクトリです。コントロール プレーンの 1 セットのみを同じホスト上に保持するか、ポートの分離とデータ ディレクトリの分離をドキュメントに明確に記載することをお勧めします。注文入口でお会いしましょうレンタル料金ページ。
まず、公式の移行手順に従ってローカル構成とデーモン構成を調整してから、サービスを再起動します。より完全なコマンド チェーンについては、を参照してください。医師による取り付けとトラブルシューティング。
検索してくださいヘルプセンターネットワークと SSH の手順、ポートとセキュリティ グループの検証は、Runbook の同じページに書き込まれます。