OpenClaw セキュリティ監査：リバースプロキシ、Trusted Proxies＆ゲートウェイ強化 [2026]

openclaw security audit を実行して "reverse proxy headers are not trusted" という警告とコード gateway.trusted_proxies_missing が表示された場合、OpenClaw デプロイメントで最も一般的で最も重要なセキュリティ指摘の1つに直面しています。このガイドでは、この警告の意味、無視すると危険な理由、そしてすべての主要リバースプロキシでの修正方法を詳しく説明します。

セキュリティ監査が伝えていること

openclaw security audit を実行すると、ゲートウェイ設定に対して一連のチェックが行われます。OpenClaw が転送ヘッダー（X-Forwarded-For など）を受信しているのに gateway.trustedProxies リストが設定されていないことを検出すると、以下の出力が生成されます：

WARN  gateway.trusted_proxies_missing
      Reverse proxy headers are not trusted.
      Configure gateway.trustedProxies in openclaw.json

これは、OpenClaw がリバースプロキシの背後にあるにもかかわらず、どの転送ヘッダーを信頼すべきか検証する方法がないことを意味します。すべてのリクエストはソース IP 127.0.0.1（プロキシ）で到着し、OpenClaw は実際のクライアント IP を判別できません。

なぜこれが重要か：IP スプーフィングとヘッダーインジェクション

X-Forwarded-For ヘッダーは、リバースプロキシが元のクライアント IP をバックエンドサービスに伝える方法です。問題は、このヘッダーは攻撃者を含む誰でも設定できることです。Trusted Proxies 設定がないと、2つの問題が発生します：

1. クライアント IP スプーフィング。 攻撃者は偽の X-Forwarded-For: 192.168.1.1 ヘッダー付きのリクエストを送信できます。OpenClaw がそのヘッダーを盲目的に信頼すると、間違った IP を記録し、間違ったアクセス制御を適用し、クライアントごとのレート制限が機能しなくなります。[^1]

2. アクセス制御のバイパス。 OpenClaw はクライアント IP を使用してローカル接続とリモート接続を区別します。ローカル接続はデバイスペアリングや管理操作などの昇格されたアクセスを取得します。プロキシ IP が信頼リストにない場合、OpenClaw はすべての接続をローカルとして扱う（127.0.0.1 から来るため）か、転送ヘッダーの信頼を完全に拒否します。どちらの結果もセキュリティを損ないます。

gateway.trustedProxies 設定は OpenClaw に以下を伝えます：「これらの特定の IP からのみ X-Forwarded-For ヘッダーを除去して信頼してください。」それ以外はヘッダーが破棄されます。

修正方法：gateway.trustedProxies の設定

使用するリバースプロキシに関係なく、基本的な修正は同じです：

openclaw config set gateway.trustedProxies '["127.0.0.1"]'
openclaw restart

これは、リクエストが 127.0.0.1（ローカルリバースプロキシ）から発信された場合のみ転送ヘッダーを信頼するようゲートウェイに指示します。プロキシが別のマシンで実行されている場合は、そのマシンの IP を代わりに使用してください。

openclaw.json を直接編集することもできます：

{
  "gateway": {
    "mode": "local",
    "trustedProxies": ["127.0.0.1"]
  }
}

変更後、ゲートウェイを再起動して監査を再実行します：

openclaw restart
openclaw security audit

以下が表示されるはずです：

OK  gateway.trusted_proxies — reverse proxy headers are trusted

サーバー別リバースプロキシ設定

OpenClaw 側は修正の半分に過ぎません。リバースプロキシも正しい転送ヘッダーを設定するように構成する必要があります。

Caddy

Caddy は転送ヘッダーを自動的に処理します。最小限の Caddyfile だけで十分です：[^2]

openclaw.yourdomain.com {
    reverse_proxy localhost:3001
}

Caddy はデフォルトで X-Forwarded-For、X-Forwarded-Proto、X-Forwarded-Host を設定します。追加のヘッダー設定は不要です。

変更後のリロード：

caddy reload --adapter caddyfile --config /etc/caddy/Caddyfile

Nginx

Nginx には明示的なヘッダーディレクティブが必要です。これがないと、OpenClaw は転送情報を一切受信しません：[^3]

server {
    listen 443 ssl;
    server_name openclaw.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

重要な行は proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for です。これは既存の X-Forwarded-For チェーンに実際のクライアント IP を追加します（置換するのではなく）。これはマルチプロキシ構成で重要です。

編集後、テストしてリロードします：

nginx -t && systemctl reload nginx

Apache

mod_proxy を使用する Apache の場合、mod_headers を有効にして転送を設定します：

<VirtualHost *:443>
    ServerName openclaw.yourdomain.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3001/
    ProxyPassReverse / http://127.0.0.1:3001/

    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-For "%{REMOTE_ADDR}e"

    # WebSocket サポート
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} websocket [NC]
    RewriteRule /(.*) ws://127.0.0.1:3001/$1 [P,L]
</VirtualHost>

必要なモジュールを有効にします：

a2enmod proxy proxy_http proxy_wstunnel headers rewrite
systemctl restart apache2

セキュリティ監査の完全な出力を理解する

trusted_proxies_missing チェックは、セキュリティ監査が評価するいくつかの項目の1つです。完全な openclaw security audit は以下をカバーします：

OK   gateway.token_set — gateway token is configured
WARN gateway.trusted_proxies_missing — reverse proxy headers are not trusted
OK   gateway.port_restricted — gateway port is not publicly exposed
OK   security.device_pairing — device pairing is enabled
OK   security.webhook_auth — webhook endpoints require authentication

--deep フラグは追加のチェックを実行します：

openclaw security audit --deep

これは開いているポート、有効なブラウザコントロールツール、ファイルパーミッションの露出、スキルサンドボックスの完全性のチェックを追加します。

複数のプロキシホップ

トラフィックが複数のプロキシを通過する場合（例：Cloudflare → Nginx → OpenClaw）、各ホップを信頼する必要があります：

openclaw config set gateway.trustedProxies '["127.0.0.1", "172.17.0.1"]'

転送ヘッダーを設定するすべてのプロキシ IP をリストします。OpenClaw は X-Forwarded-For チェーンを右から左に走査し、信頼された IP を除去して、最初の信頼されていない IP を見つけます。それが実際のクライアント IP になります。

["0.0.0.0/0"] やワイルドカード CIDR を使用しないでください。すべての IP を信頼すると、設定の目的全体が無効になり、監査が警告するのと同じスプーフィング攻撃に対して脆弱になります。

修正の検証

両側を設定した後、エンドツーエンドで検証します：

# 1. セキュリティ監査を再実行
openclaw security audit

# 2. ゲートウェイログで実際のクライアント IP を確認
openclaw logs --follow

# 3. 全体的な健全性のために doctor を実行
openclaw doctor

監査が gateway.trusted_proxies に OK を報告していれば、転送ヘッダーが正しく検証されています。

設定を完全にスキップ

ClawTank はすべてのインスタンスに対してリバースプロキシ設定、TLS 証明書、Trusted Proxy 設定を自動的に処理します。セキュリティ監査はそのまま合格します — 手動でのゲートウェイ強化は不要です。

[^1]: OWASP Web Security Testing Guide — X-Forwarded-For ヘッダーの悪用と IP ベースのアクセス制御テストについて説明しています。 [^2]: Caddy reverse_proxy ディレクティブのドキュメント — 自動ヘッダー処理とアップストリーム設定の詳細。 [^3]: Nginx ngx_http_proxy_module のドキュメント — proxy_set_header と転送ヘッダー設定のリファレンス。