Skip to main content
OpenClaw は、ランタイムの HTTP および WebSocket トラフィックを、運用者が管理するフォワードプロキシ経由でルーティングできます。これはオプションの多層防御であり、送信トラフィックの一元管理、より強力な SSRF 保護、ネットワーク境界での宛先監査を実現します。プロキシは DNS 解決後、アップストリーム接続を開く直前の接続時に宛先を評価するため、アプリケーションレベルで先に行われた DNS チェックと実際の外部接続との間を利用する DNS リバインディング攻撃の余地も狭めます。また、単一のプロキシポリシーにより、運用者は OpenClaw を再ビルドせずに、宛先ルール、ネットワークセグメンテーション、レート制限、外向き通信の許可リストを一か所で適用できます。 OpenClaw はプロキシの同梱、ダウンロード、起動、設定、認証を行いません。環境に適したプロキシ技術を運用し、OpenClaw は自身の HTTP および WebSocket クライアントをそのプロキシ経由でルーティングします。

設定

環境変数を使用して URL を設定することもできます。
proxy.proxyUrlOPENCLAW_PROXY_URL より優先されます。URL を設定すると管理対象プロキシルーティングが有効になり、両方の URL を削除すると無効になります。 管理対象の Gateway サービスでは、フォアグラウンド環境変数に依存せず、再インストール後も保持されるように URL を設定へ保存します。
OPENCLAW_PROXY_URL 環境変数のフォールバックは、フォアグラウンド実行に最適です。インストール済みサービスで使用するには、サービスの永続的な環境($OPENCLAW_STATE_DIR/.env、デフォルトは ~/.openclaw/.env)に設定し、launchd/systemd/スケジュールされたタスクが取得できるように再インストールします。

プライベート CA を使用する HTTPS プロキシエンドポイント

proxy.tls.caFile は、プロキシエンドポイント自体の TLS 証明書を検証します。これは宛先の MITM 信頼設定、クライアント証明書、またはプロキシの宛先ポリシーの代替ではありません。Node プロセス全体が起動時から追加の CA を信頼する必要がある場合(たとえば、すべての HTTPS 宛先証明書を再署名する企業向け TLS インスペクションシステム)のみ、代わりに NODE_EXTRA_CA_CERTS を使用してください。この変数はプロセス全体に適用され、Node の起動前に設定する必要があるため、OpenClaw は proxy.tls.caFile のように実行途中で適用できません。HTTPS プロキシエンドポイントの信頼には proxy.tls.caFile を推奨します。これはプロセス全体ではなく、管理対象プロキシルーティングのみに適用されます。

ルーティングの仕組み

有効なプロキシ URL が設定されている場合、保護対象のランタイムプロセス(openclaw gateway runopenclaw node runopenclaw agent --local)は、通常の HTTP および WebSocket の外向き通信をプロキシ経由でルーティングします。
内部では、OpenClaw はプロセスレベルのルーティングランタイムとして Proxyline を導入します。これは fetch、undici ベースのクライアント、node:http/node:https、一般的な WebSocket クライアント、ヘルパーによって作成される CONNECT トンネルを対象とします。また、呼び出し元が指定した Node HTTP エージェントを置き換えるため、明示的なエージェント(axiosgotnode-fetch、および同様の Node エージェントベースのクライアントを含む)が密かにプロキシを迂回することはできません。 プロキシ URL のスキームは、最終的な宛先ではなく、OpenClaw からプロキシまでのホップを表します。
  • http://proxy.example:3128 — プロキシへの平文 TCP。OpenClaw は、HTTPS 宛先用の CONNECT を含む HTTP プロキシリクエストを送信します。
  • https://proxy.example:8443 — OpenClaw はプロキシ自体への TLS 接続を開き(プロキシの証明書を検証し)、そのセッション内で HTTP プロキシリクエストを送信します。
宛先の TLS は、プロキシエンドポイントの TLS とは独立しています。HTTPS 宛先の場合、OpenClaw は常にプロキシへ CONNECT トンネルを要求し、そのトンネル経由で宛先 TLS を開始します。 プロキシが有効な間、OpenClaw は no_proxy/NO_PROXY をクリアします。これらのバイパスリストは宛先に基づくため、localhost127.0.0.1 を残すと、SSRF の標的がプロキシを完全に迂回できてしまいます。シャットダウン時に、OpenClaw は以前のプロキシ環境を復元し、キャッシュされたルーティング状態をリセットします。 一部の Plugin は、プロセスレベルのルーティングが有効な場合でも、独自のプロキシ接続設定を必要とするカスタムトランスポートを所有しています。Telegram の Bot API クライアントは独自の HTTP/1 undici ディスパッチャーを使用し、プロセスのプロキシ環境変数と OPENCLAW_PROXY_URL フォールバックも個別に尊重します。

Gateway ループバックモード

ローカルの Gateway コントロールプレーンクライアントは通常、ws://127.0.0.1:18789 のようなループバック WebSocket に接続します。proxy.loopbackMode は、そのトラフィックが管理対象プロキシをバイパスするかどうかを制御します。
proxyUrl または OPENCLAW_PROXY_URL を設定すると、管理対象ルーティングが有効になります。URL を保存したまま有効化しない高度なオプトアウトとしてのみ、 proxy.enabled: false を設定してください。 Gateway コントロールプレーンのバイパスは、localhost およびリテラルのループバック IP URL に限定されます。ws://127.0.0.1:18789ws://[::1]:18789、または ws://localhost:18789 を使用してください。それ以外のホスト名は通常のトラフィックと同様にルーティングされます。

コンテナ

openclaw --container ... コマンドでは、OPENCLAW_PROXY_URL が設定されている場合、OpenClaw はそれをコンテナ対象の子 CLI に転送します。URL はコンテナ内部から到達可能でなければなりません。コンテナ内の 127.0.0.1 はホストではなく、コンテナ自体を指します。OpenClaw は、OPENCLAW_CONTAINER_ALLOW_LOOPBACK_PROXY_URL=1 を設定して明示的にチェックを上書きしない限り、コンテナ対象コマンドでループバックプロキシ URL を拒否します。

関連するプロキシ用語

  • proxy.enabled / proxy.proxyUrl — ランタイムの外向き通信に対する送信フォワードプロキシルーティング。このページで説明しています。
  • gateway.auth.mode: "trusted-proxy" — Gateway へのアクセスに対する、受信側の ID 対応リバースプロキシ認証。信頼済みプロキシ認証を参照してください。
  • openclaw proxy — 開発およびサポート用のローカルデバッグプロキシ兼キャプチャ検査ツール。openclaw proxyを参照してください。
  • tools.web.fetch.useTrustedEnvProxy — 厳格な DNS ピン留めとホスト名ポリシーをデフォルトで維持しながら、運用者が管理する HTTP(S) 環境プロキシによる DNS 解決を web_fetch に許可するオプトイン。Web フェッチを参照してください。
  • チャンネルまたはプロバイダー固有のプロキシ設定 — 単一のトランスポートに対する所有者固有の上書き。ランタイム全体の外向き通信を一元管理するには、管理対象ネットワークプロキシを推奨します。

プロキシの検証

実際のセキュリティ境界はプロキシの宛先ポリシーです。OpenClaw は、プロキシが適切な対象をブロックしているか検証できません。次のように設定してください。
  • local loopback または信頼できるプライベートインターフェースのみにバインドし、OpenClaw のプロセス、ホスト、コンテナ、またはサービスアカウントからのみ到達可能にします。
  • 宛先をプロキシ自身で解決し、平文 HTTP と HTTPS の CONNECT トンネルの両方について、DNS 解決後の接続時に IP に基づいてブロックします。
  • ループバック、プライベート、リンクローカル、メタデータ、マルチキャスト、予約済み、およびドキュメント用の範囲に対する、宛先ベースのバイパスを拒否します。
  • DNS 解決経路を完全に信頼できる場合を除き、ホスト名の許可リストは避けます。
  • 宛先、判定、ステータス、理由を記録します。リクエスト本文、認証ヘッダー、Cookie、その他のシークレットは決して記録しないでください。
  • ポリシーをバージョン管理下に置き、変更をセキュリティ上重要なものとしてレビューします。
OpenClaw を実行するものと同じホスト、コンテナ、またはサービスアカウントから検証します。
プライベート CA を使用する HTTPS プロキシエンドポイントの場合:
config、環境、または --proxy-url の値が利用できない場合、コマンドは設定上の問題を報告します。設定を変更する前の一時的な事前チェックには --proxy-url を渡してください。 --allowed-url/--denied-url を指定しない場合、デフォルトのチェックは次のとおりです。https://example.com/ は成功する必要があり、プロキシから到達できてはならない一時的な loopback カナリアサーバーはブロックされる必要があります。loopback チェックは、トランスポート障害が発生した場合、またはカナリアの実行ごとのトークンを含まない非 2xx レスポンスが返された場合に成功します。トークンのない 2xx レスポンス(カナリア以外からの予期しない成功)が返された場合は失敗し、特に一致するトークンを含むレスポンスが返された場合は、プロキシが拒否すべき loopback 宛先を実際に転送したことが証明されるため失敗します。カスタム --denied-url ターゲットにはこのようなカナリアトークンがないため、フェイルクローズ方式です。HTTP レスポンスはすべて到達可能(失敗)と見なされ、トランスポートエラーはブロックされた証拠ではなく判定不能として報告されます。これは、到達可能なオリジンをプロキシが拒否したのか、それとも別の問題が発生したのかを OpenClaw が確認できないためです。--apns-reachable は意図的に無効なプロバイダートークンを送信するため、403 InvalidProviderToken レスポンスはトンネルが Apple に到達した証拠と見なされます。検証に失敗するとコマンドは 1 で終了します。プロキシ URL の認証情報は、テキスト出力と JSON 出力の両方で編集されます。
手動の curl チェック(公開リクエストは成功し、loopback およびメタデータへのリクエストはプロキシ自体によってブロックされる必要があります。curl だけでは、openclaw proxy validate の組み込みカナリアのように、プロキシによる拒否と到達不能なオリジンを区別できません)。

推奨されるブロック対象の宛先

すべてのフォワードプロキシ、ファイアウォール、または送信ポリシー向けの初期拒否リストです。OpenClaw 独自の SSRF 分類器は src/infra/net/ssrf.tspackages/net-policy/src/ip.ts にあります(BLOCKED_HOSTNAMESBLOCKED_IPV4_SPECIAL_USE_RANGESBLOCKED_IPV6_SPECIAL_USE_RANGES、RFC 2544 ベンチマークプレフィックス、および NAT64/6to4/Teredo/ISATAP/IPv4 マップ形式に埋め込まれた IPv4 の処理)。参考として有用ですが、OpenClaw は外部プロキシでこれらのルールをエクスポートまたは適用しません。 クラウドプロバイダーまたはネットワークプラットフォームが文書化している追加のメタデータホストや予約済み範囲を追加してください。

制限

  • これは JavaScript の HTTP/WebSocket クライアントを対象とするプロセスレベルの保護であり、OS レベルのネットワークサンドボックスではありません。
  • 生の nettlshttp2 ソケット、ネイティブアドオン、および OpenClaw 以外の子プロセスは、プロキシ環境変数を継承して遵守しない限り、Node レベルのルーティングを迂回する場合があります。フォークされた OpenClaw の子 CLI は、マネージドプロキシ URL と proxy.loopbackMode の状態を継承します。
  • ユーザーのローカル WebUI とローカルモデルサーバーは、一般的なローカルネットワークのバイパス対象ではありません。必要に応じて、運用者のプロキシポリシーで許可リストに追加してください。例外は、同梱されている Ollama メモリ埋め込みプロバイダーの保護された直接パスで、設定済みの baseUrl に含まれる正確なホストローカル loopback オリジンに限定されます。LAN、tailnet、プライベートネットワーク、および公開 Ollama ホストでは、引き続きマネージドプロキシが使用されます。
  • ローカルデバッグプロキシによる直接のアップストリーム転送(プロキシリクエストおよび CONNECT トンネル用)は、マネージドプロキシモードの有効中はデフォルトで無効になります。承認済みのローカル診断にのみ有効化してください。
  • OpenClaw は、プロキシポリシーの検査、テスト、または認証を行いません。プロキシポリシーの変更は、セキュリティ上慎重な扱いを要する運用変更として扱ってください。