---
read_when:
    - SSRF攻撃とDNSリバインディング攻撃に対する多層防御が必要な場合
    - OpenClaw ランタイムトラフィック用の外部フォワードプロキシの設定
summary: OpenClaw ランタイムの HTTP および WebSocket トラフィックを、オペレーター管理のフィルタリングプロキシ経由でルーティングする方法
title: ネットワークプロキシ
x-i18n:
    generated_at: "2026-05-02T05:05:49Z"
    model: gpt-5.5
    provider: openai
    source_hash: 9207d349e4410e38631ae7665be19b536e4a4128a4e80dd095e802804dfd66a3
    source_path: security/network-proxy.md
    workflow: 16
---

# ネットワークプロキシ

OpenClaw は、実行時の HTTP および WebSocket トラフィックを、運用者が管理するフォワードプロキシ経由でルーティングできます。これは、集中型の外向き通信制御、より強い SSRF 保護、より優れたネットワーク監査性を必要とするデプロイ向けの、任意の多層防御です。

OpenClaw はプロキシを同梱、ダウンロード、起動、設定、認証しません。環境に合うプロキシ技術を利用し、OpenClaw は通常のプロセスローカル HTTP クライアントおよび WebSocket クライアントをそのプロキシ経由でルーティングします。

## プロキシを使う理由

プロキシは、外向き HTTP および WebSocket トラフィックに対して、運用者に単一のネットワーク制御点を提供します。これは SSRF 強化以外でも有用です。

- 集中ポリシー: すべてのアプリケーション HTTP 呼び出し箇所がネットワークルールを正しく扱うことに頼るのではなく、外向き通信ポリシーを 1 か所で維持します。
- 接続時チェック: DNS 解決後、かつプロキシが上流接続を開く直前に宛先を評価します。
- DNS リバインディング防御: アプリケーションレベルの DNS チェックと実際の外向き接続の間の差を小さくします。
- より広い JavaScript 対応範囲: 通常の `fetch`、`node:http`、`node:https`、WebSocket、axios、got、node-fetch、および同様のクライアントを同じ経路にルーティングします。
- 監査性: 外向き通信境界で、許可および拒否された宛先をログに記録します。
- 運用制御: OpenClaw を再ビルドせずに、宛先ルール、ネットワーク分離、レート制限、または外向き許可リストを適用します。

プロキシルーティングは、通常の HTTP および WebSocket の外向き通信に対するプロセスレベルのガードレールです。サポートされる JavaScript HTTP クライアントを独自のフィルタリングプロキシ経由でルーティングするフェイルクローズ経路を運用者に提供しますが、OS レベルのネットワークサンドボックスではなく、OpenClaw がプロキシの宛先ポリシーを認証するものでもありません。

## OpenClaw がトラフィックをルーティングする仕組み

`proxy.enabled=true` でプロキシ URL が設定されている場合、`openclaw gateway run`、`openclaw node run`、`openclaw agent --local` などの保護された実行時プロセスは、通常の HTTP および WebSocket の外向き通信を設定済みプロキシ経由でルーティングします。

```text
OpenClaw process
  fetch                  -> operator-managed filtering proxy -> public internet
  node:http and https    -> operator-managed filtering proxy -> public internet
  WebSocket clients      -> operator-managed filtering proxy -> public internet
```

公開契約はルーティング動作であり、それを実装するために使われる内部 Node フックではありません。OpenClaw Gateway のコントロールプレーン WebSocket クライアントは、Gateway URL が `localhost`、または `127.0.0.1` や `[::1]` などのリテラルループバック IP を使用する場合、local loopback Gateway RPC トラフィックに対して狭い直接経路を使用します。そのコントロールプレーン経路は、運用者プロキシがループバック宛先をブロックしている場合でも、ループバック Gateway に到達できる必要があります。通常の実行時 HTTP および WebSocket リクエストは、引き続き設定済みプロキシを使用します。

内部的には、OpenClaw はこの機能に 2 つのプロセスレベルのルーティングフックを使用します。

- Undici ディスパッチャールーティングは、`fetch`、undici ベースのクライアント、および独自の undici ディスパッチャーを提供するトランスポートを対象にします。
- `global-agent` ルーティングは、Node コアの `node:http` および `node:https` 呼び出し元を対象にします。これには、`http.request`、`https.request`、`http.get`、`https.get` の上に重ねられた多くのライブラリが含まれます。マネージドプロキシモードはそのグローバルエージェントを強制するため、明示的な Node HTTP エージェントが運用者プロキシを誤って迂回することはありません。

一部の Plugin は、プロセスレベルのルーティングが存在する場合でも、明示的なプロキシ配線を必要とするカスタムトランスポートを所有しています。たとえば、Telegram の Bot API トランスポートは独自の HTTP/1 undici ディスパッチャーを使用するため、その所有者固有のトランスポート経路で、プロセスプロキシ環境とマネージド `OPENCLAW_PROXY_URL` フォールバックを尊重します。

プロキシ URL 自体は `http://` を使用する必要があります。HTTPS 宛先も、HTTP `CONNECT` によりプロキシ経由で引き続きサポートされます。これは、OpenClaw が `http://127.0.0.1:3128` のようなプレーン HTTP フォワードプロキシリスナーを想定しているという意味にすぎません。

プロキシが有効な間、OpenClaw は `no_proxy`、`NO_PROXY`、`GLOBAL_AGENT_NO_PROXY` をクリアします。これらの迂回リストは宛先ベースであるため、そこに `localhost` や `127.0.0.1` を残しておくと、高リスクの SSRF ターゲットがフィルタリングプロキシを迂回できてしまいます。

シャットダウン時に、OpenClaw は以前のプロキシ環境を復元し、キャッシュされたプロセスルーティング状態をリセットします。

## 関連するプロキシ用語

- `proxy.enabled` / `proxy.proxyUrl`: OpenClaw 実行時の外向き通信向けの外向きフォワードプロキシルーティング。このページではこの機能を説明します。
- `gateway.auth.mode: "trusted-proxy"`: Gateway アクセス向けの、受信側の ID 対応リバースプロキシ認証。[Trusted proxy auth](/ja-JP/gateway/trusted-proxy-auth) を参照してください。
- `openclaw proxy`: 開発およびサポート向けのローカルデバッグプロキシおよびキャプチャインスペクター。[openclaw proxy](/ja-JP/cli/proxy) を参照してください。
- チャネルまたはプロバイダー固有のプロキシ設定: 特定のトランスポート向けの所有者固有の上書き。目的が実行時全体にわたる集中型の外向き通信制御である場合は、マネージドネットワークプロキシを優先してください。

## 設定

```yaml
proxy:
  enabled: true
  proxyUrl: http://127.0.0.1:3128
```

設定で `proxy.enabled=true` を維持しながら、環境経由で URL を指定することもできます。

```bash
OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run
```

`proxy.proxyUrl` は `OPENCLAW_PROXY_URL` より優先されます。

`enabled=true` だが有効なプロキシ URL が設定されていない場合、保護されたコマンドは直接ネットワークアクセスへフォールバックするのではなく、起動に失敗します。

`openclaw gateway start` で開始されるマネージド Gateway サービスでは、URL を設定に保存することを推奨します。

```bash
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway install --force
openclaw gateway start
```

環境フォールバックはフォアグラウンド実行に最適です。インストール済みサービスで使用する場合は、`OPENCLAW_PROXY_URL` を `$OPENCLAW_STATE_DIR/.env` や `~/.openclaw/.env` などのサービスの永続環境に置き、その後サービスを再インストールして、launchd、systemd、または Scheduled Tasks がその値で Gateway を開始するようにしてください。

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

## プロキシ要件

プロキシポリシーがセキュリティ境界です。OpenClaw は、プロキシが正しいターゲットをブロックしていることを検証できません。

プロキシを次のように設定してください。

- ループバックまたは信頼されたプライベートインターフェイスのみにバインドします。
- OpenClaw プロセス、ホスト、コンテナー、またはサービスアカウントのみが使用できるようにアクセスを制限します。
- 宛先を自ら解決し、DNS 解決後に宛先 IP をブロックします。
- プレーン HTTP リクエストと HTTPS `CONNECT` トンネルの両方について、接続時にポリシーを適用します。
- ループバック、プライベート、リンクローカル、メタデータ、マルチキャスト、予約済み、または文書用範囲に対する宛先ベースの迂回を拒否します。
- DNS 解決経路を完全に信頼していない限り、ホスト名許可リストは避けます。
- リクエスト本文、認証ヘッダー、Cookie、その他のシークレットをログに記録せずに、宛先、判断、ステータス、理由をログに記録します。
- プロキシポリシーをバージョン管理下に置き、セキュリティ上重要な設定と同様に変更をレビューします。

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

この拒否リストを、任意のフォワードプロキシ、ファイアウォール、または外向き通信ポリシーの出発点として使用してください。

OpenClaw のアプリケーションレベル分類ロジックは、`src/infra/net/ssrf.ts` および `src/shared/net/ip.ts` にあります。関連するパリティフックは、`BLOCKED_HOSTNAMES`、`BLOCKED_IPV4_SPECIAL_USE_RANGES`、`BLOCKED_IPV6_SPECIAL_USE_RANGES`、`RFC2544_BENCHMARK_PREFIX`、および NAT64、6to4、Teredo、ISATAP、IPv4 マップ形式向けの埋め込み IPv4 センチネル処理です。これらのファイルは外部プロキシポリシーを維持する際に有用な参照ですが、OpenClaw はそれらのルールをプロキシへ自動的にエクスポートまたは適用しません。

| 範囲またはホスト                                                                     | ブロックする理由                                     |
| ------------------------------------------------------------------------------------ | ---------------------------------------------------- |
| `127.0.0.0/8`, `localhost`, `localhost.localdomain`                                  | IPv4 ループバック                                    |
| `::1/128`                                                                            | IPv6 ループバック                                    |
| `0.0.0.0/8`, `::/128`                                                                | 未指定アドレスおよびこのネットワークのアドレス       |
| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`                                      | RFC1918 プライベートネットワーク                     |
| `169.254.0.0/16`, `fe80::/10`                                                        | リンクローカルアドレスおよび一般的なクラウドメタデータ経路 |
| `169.254.169.254`, `metadata.google.internal`                                        | クラウドメタデータサービス                           |
| `100.64.0.0/10`                                                                      | キャリアグレード NAT 共有アドレス空間                |
| `198.18.0.0/15`, `2001:2::/48`                                                       | ベンチマーク範囲                                     |
| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | 特殊用途および文書用範囲                             |
| `224.0.0.0/4`, `ff00::/8`                                                            | マルチキャスト                                       |
| `240.0.0.0/4`                                                                        | 予約済み IPv4                                        |
| `fc00::/7`, `fec0::/10`                                                              | IPv6 ローカル/プライベート範囲                       |
| `100::/64`, `2001:20::/28`                                                           | IPv6 破棄および ORCHIDv2 範囲                        |
| `64:ff9b::/96`, `64:ff9b:1::/48`                                                     | 埋め込み IPv4 を含む NAT64 プレフィックス            |
| `2002::/16`, `2001::/32`                                                             | 埋め込み IPv4 を含む 6to4 および Teredo              |
| `::/96`, `::ffff:0:0/96`                                                             | IPv4 互換および IPv4 マップ IPv6                     |

クラウドプロバイダーまたはネットワークプラットフォームが追加のメタデータホストや予約済み範囲を文書化している場合は、それらも追加してください。

## 検証

OpenClaw を実行する同じホスト、コンテナー、またはサービスアカウントからプロキシを検証します。

```bash
openclaw proxy validate --proxy-url http://127.0.0.1:3128
```

デフォルトでは、カスタム宛先が指定されていない場合、このコマンドは `https://example.com/` が成功することを確認し、プロキシが到達してはならない一時的なループバックカナリアを開始します。デフォルトの拒否チェックは、プロキシが非 2xx の拒否レスポンスを返すか、トランスポート障害でカナリアをブロックした場合に成功します。成功レスポンスがカナリアに到達した場合は失敗します。プロキシが有効化および設定されていない場合、検証は設定の問題を報告します。設定を変更する前の 1 回限りの事前確認には `--proxy-url` を使用してください。デプロイ固有の期待値をテストするには、`--allowed-url` と `--denied-url` を使用してください。カスタム拒否宛先はフェイルクローズです。HTTP レスポンスがある場合は宛先がプロキシ経由で到達可能だったことを意味し、トランスポートエラーは、OpenClaw が到達可能なオリジンをプロキシがブロックしたことを証明できないため、結論不明として報告されます。検証失敗時、このコマンドはコード 1 で終了します。

自動化には `--json` を使用してください。JSON 出力には、全体の結果、有効なプロキシ設定ソース、設定エラー、各宛先チェックが含まれます。プロキシ URL の認証情報は、テキスト出力および JSON 出力で編集されます。

```json
{
  "ok": true,
  "config": {
    "enabled": true,
    "proxyUrl": "http://127.0.0.1:3128/",
    "source": "override",
    "errors": []
  },
  "checks": [
    {
      "kind": "allowed",
      "url": "https://example.com/",
      "ok": true,
      "status": 200
    }
  ]
}
```

`curl` を使って手動で検証することもできます:

```bash
curl -x http://127.0.0.1:3128 https://example.com/
curl -x http://127.0.0.1:3128 http://127.0.0.1/
curl -x http://127.0.0.1:3128 http://169.254.169.254/
```

公開リクエストは成功するはずです。ループバックとメタデータのリクエストは、プロキシによってブロックされるはずです。`openclaw proxy validate` では、組み込みのループバックカナリアにより、プロキシによる拒否と到達可能なオリジンを区別できます。カスタムの `--denied-url` チェックにはそのカナリアがないため、プロキシがデプロイ固有の拒否シグナルを公開しており、それを別途検証できる場合を除き、HTTP レスポンスと曖昧なトランスポート障害の両方を検証失敗として扱ってください。

次に、OpenClaw のプロキシルーティングを有効にします:

```bash
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway run
```

または、次を設定します:

```yaml
proxy:
  enabled: true
  proxyUrl: http://127.0.0.1:3128
```

## 制限

- プロキシは、プロセスローカルの JavaScript HTTP および WebSocket クライアントに対するカバレッジを改善しますが、OS レベルのネットワークサンドボックスではありません。
- 生の `net`、`tls`、`http2` ソケット、ネイティブアドオン、子プロセスは、プロキシ環境変数を継承して尊重しない限り、Node レベルのプロキシルーティングを迂回する可能性があります。
- ユーザーのローカル WebUI とローカルモデルサーバーは、必要に応じてオペレーターのプロキシポリシーで許可リストに追加する必要があります。OpenClaw は、それら向けの一般的なローカルネットワーク迂回を公開しません。
- Gateway コントロールプレーンのプロキシ迂回は、意図的に `localhost` とリテラルのループバック IP URL に限定されています。ローカルの直接 Gateway コントロールプレーン接続には、`ws://127.0.0.1:18789`、`ws://[::1]:18789`、または `ws://localhost:18789` を使用してください。他のホスト名は、通常のホスト名ベースのトラフィックと同様にルーティングされます。
- OpenClaw は、プロキシポリシーを検査、テスト、認証しません。
- プロキシポリシーの変更は、セキュリティ上重要な運用変更として扱ってください。
