1. Home
  2. Next-Gen WAF
  3. セットアップと設定
  4. リバースプロキシのデプロイ

エージェントのリバースプロキシデプロイを設定する

Next-Gen WAF エージェントは、リバースプロキシとして設定することで、モジュールを必要とせずにリクエストとレスポンスを直接処理することができます。エージェントをリバースプロキシモードで実行することは、Web サービス用のモジュールがまだ存在しない場合や、Web サービスの設定を変更したくない場合 (例 : プロダクトのテスト中) に理想的です。このモードでは、エージェントは Web サービスの前にサービスとしてインラインで配置されます。

リバースプロキシモードでは、エージェントは1つ以上のリスナーを起動し、それらで受信したすべてのトラフィックを設定されたアップストリームサーバーにプロキシします。HTTP、HTTPS (TLS) リスナーの両方を有効にすることができます。エージェントをリバースプロキシモードで設定すると、RPC リスナーが無効になり、エージェントはどのモジュールでも機能しなくなります。

リバースプロキシリスナーを設定する

リバースプロキシモードは複数のリスナーをサポートします。設定ファイルでは、各リスナーは独自のディレクティブセットを持つ revproxy-listener ブロックで定義されています。各ブロックは TOML テーブルでフォーマットされています。各ブロックは以下の条件を満たさなければなりません。

  • [revproxy-listener.NAME] フォーマットで一意の名前を持ちます。ここで、NAME は、定義された文字列です。

  • 他のすべてのグローバルオプションの後で、設定の最後に配置されます。

たとえば、簡単な HTTP (暗号化なし) リスナーを設定するには、agent.conf ファイル (デフォルト : /etc/sigsci/agent.conf) を更新して、以下に示す設定ブロックを含めるようにします。これにより、example1 という名前の HTTP リバースプロキシリスナーが作成されます。

[revproxy-listener.example1]
listener = "http://203.0.113.13:80"
upstreams = "http://192.168.1.2:80"

listener オプションは、エージェントが URL の形式でリッスンするアドレスです。上の例では、203.0.113.13 は IP アドレスの例であり、ネットワークに適切なアドレスを設定する必要があります。不明な場合は、ループバックアドレス (127.0.0.1) に制限すると、外部アクセスを許可せずにローカルテストを実行できます。0.0.0.0 メタアドレスはホスト上のすべてのアドレスをリッスンするために使用できます。

upstreams オプションは、エージェントがリクエストをプロキシするアップストリームホストを定義します。アップストリームのホストはカンマ区切りの URL リストです。URL のスキームは、アップストリームへのリスニングとプロキシに使用されるプロトコルを指定します。

ヒント : リスナーの upstreams オプションに複数のホストを追加すると、リクエストは動的にラウンドロビンロードバランシングによってアップストリームホスト間で分散されます。ロードバランサーがスティッキーセッション (セッションアフィニティ) 用に設定されている場合、アップストリームホストごとに個別のリスナーを作成する必要があります。

TSL 暗号化リスナーを設定するには、https スキームをlistener オプションで使用し、tls-key と tls-cert オプションを設定して、キーと証明書を含むファイルを指定します。upstreams 方式は、アップストリームホストへのプロキシに使用するプロトコルを決定します。

アップストリームへのトラフィックを暗号化する

[revproxy-listener.example2]
listener = "https://203.0.113.13:8080"
upstreams = "https://192.168.1.2:8443,https://192.168.1.3:8443"
tls-cert = "/etc/sigsci/server-cert.pem"
tls-key = "/etc/sigsci/server-key.pem"

エージェントで TLS を終了する

このオプションは上記と類似していますが、upstreams で使用されるスキームのみが異なります。

[revproxy-listener.example3]
listener = "https://203.0.113.13:8443"
upstreams = "http://192.168.1.2:8001,http://192.168.1.2:8002"
tls-cert = "/etc/sigsci/server-cert.pem"
tls-key = "/etc/sigsci/server-key.pem"

ヒント : どちらのオプションでも、証明書ファイルと鍵ファイルを1つのファイルに連結することで同じファイルにすることができます。

希望する設定を完了したら、変更が有効になるように sigsci-agent 設定を再度読み込みます。ほとんどのシステムでは、SIGHUP シグナルをエージェントプロセス ID (例 : kill -HUP 12345、12345は PID) に送信するか、エージェントを再起動するだけでこれを実行できます。

[revproxy-listener.NAME] 設定とその利用可能なオプションは、エージェント設定ページに記載されています。

設定ファイルを使用せずに代替設定する

設定ファイルを使用していない場合、上記の新しいブロック形式を使用することはできず、代わりに別の形式を使用する必要があります。この形式は、単一の --revproxy-listener コマンドラインオプションまたは単一の SIGSCI_REVPROXY_LISTENER 環境変数で使用できます。

代替の revproxy-listener 値の一般形式

listener1:{opt=val,...}; listener2:{...}; ...

上記のいくつかの例は、代替形式でもここに再掲しています。

シンプルな HTTP リスナー

SIGSCI_REVPROXY_LISTENER="example1:{listener=http://203.0.113.13:80,upstreams=http://192.168.1.2:80}"

シンプルな HTTPS リスナー

SIGSCI_REVPROXY_LISTENER="example2:{listener=https://203.0.113.13:443,upstreams=https://192.168.1.2:8443,tls-cert=/etc/sigsci/server-cert.pem,tls-key=/etc/sigsci/server-key.pem}"

複数のリスナーを1つのオプションで指定するには、各リスナー定義をセミコロン (;) で区切ります。

複数のリスナー

SIGSCI_REVPROXY_LISTENER="example1:{...}; example2:{...}"

副作用と制限

HTTP ヘッダー名は正規化されます

リバースプロキシモードのエージェントは、各単語の最初の文字を大文字にして、すべてのヘッダー名を正規化します。たとえば、example-header が Example-Header になります。

HTTP ヘッダーの順序は維持されない場合があります

技術的な制限により、リバースプロキシモードのエージェントでは、ヘッダーの順序を追跡および維持することはできません。ヘッダーの順序はアップストリームサーバーに送信される際に変わることがあります。例 : 

GET /test HTTP/1.1
Host: example.com
X-Example-Header: example
X-Test-Header: test
X-Other-Header: other
Accept: */*

このリクエストは、アップストリームサーバーに次のように届きます。

GET /test HTTP/1.1
Host: example.com
Accept: */*
X-Test-Header: test
X-Other-Header: other
X-Example-Header: example

ヘッダーの追加

デフォルトでは、アップストリームリクエストには以下のヘッダーが追加されます。

  • X-Forwarded-For

  • X-Forwarded-Host

  • X-Forwarded-Proto

  • X-Forwarded-Server

エージェント v3.7+ では、各リスナーを設定でき、minimal-header-rewriting = true を使用することで、これらの追加ヘッダーは追加/変更されません。これらのヘッダーは、リクエストに存在している場合でも引き続き渡されます。さらに、trust-proxy-headers = false を使用して、プロキシヘッダーを信頼しないようにリスナーを設定すると、アップストリームに送信する前にこれらのヘッダーは削除されます。

さらに、上記の設定にかかわらず、以下のヘッダーが追加されます。

  • X-Sigsci-Agentresponse

  • X-Sigsci-Tags (信号が追加された場合のみ)

アップストリームへの HTTP/1.0 は、HTTP/1.1 にアップグレードされます

エージェントがリバースプロキシモードで処理した HTTP/1.0 リクエストは、アップストリームに送信されるときに HTTP/1.1 にアップグレードされます。その結果、以下のメリットが得られます。

  • HTTP キープアライブはデフォルトで有効です

  • リクエストラインには HTTP/1.1 バージョンが使用されます

  • HTTP Host ヘッダーが追加されます

  • Accept-Encoding: gzip ヘッダーが追加されます

HTTP/0.9 はサポートされていません

Go (エージェントが記述されている) は、HTTP/1.0 より前の HTTP バージョンをサポートしていません。HTTP/0.9 形式でのリクエストは、400 Bad Request エラー応答を引き起こします。これは、古い監視ツールやロードバランサーによる単純なモニタリングに影響を与える可能性があります。

たとえば、HTTP/0.9 形式のリクエストである GET / では、400 エラーが発生する可能性があります。対照的に、GET / HTTP/1.0 はサポートされている HTTP/1.0 形式で、HTTP のバージョンを指定します。

フェイルオープン

エージェントがリバースプロキシモードで実行されている場合、オープンに失敗したリクエストはクラウドバックエンドに送信されないため、Next-Gen WAF にアクセスするために使用するコンソールの「リクエスト」ページには表示されません。

F5 ロードバランサーのヘルスチェック

F5 ロードバランサーのヘルスチェックには、デフォルトで HTTP/0.9 が使用されます。しかし、Next-Gen WAF エージェントが記述されている Go が HTTP/0.9 をサポートしていないため、Next-Gen WAF のリバースプロキシでは HTTP/0.9 はサポートされていません。その結果、F5 のヘルスチェックが失敗し、レスポンスコードが 400 Bad Request になります。

この問題を解決するには、F5 ヘルスチェックを HTTP/1.0 もしくは HTTP/1.1 を使用するように強制します。送信文字列で HTTP バージョンを指定すると、モニターは代わりに HTTP/1.0 もしくは 1.1 リクエストを送信するように強制されます。

以下は、HTTP/0.9 GET リクエストの例です。

GET /index.html

HTTP/1.0 を指定すると、HTTP/1.0 GET リクエストになります。

GET /index.html HTTP/1.0

F5 ヘルスチェックリクエストの変更に関する追加情報については、F5 の公式ドキュメントをご覧ください。

次の手順

エージェントとモジュールのインストールを確認し、モジュールオプションを調査する。

関連コンテンツ

Fastly
© Fastly 2026