2026年6月6日

Imperva Cloud WAF でオリジンサーバーを設定する方法｜DNS の向け替え・オリジン IP の保護・証明書・実 IP の扱い

ネットワーク・接続

Imperva Cloud WAF でオリジンサーバーを設定する手順は、管理画面でサイトを追加 → オリジンサーバーの IP（またはホスト名）を登録 → 証明書を用意 → 動作を確認してから DNS を Imperva へ向ける → オリジンへの直接アクセスを Imperva の IP だけに絞る、の 5 段階です。DNS を最後に変えるのは、途中で切り替えると閲覧者が設定途中のオリジンへ届いてしまうためです。

結論を先にまとめます。

Imperva Cloud WAF はリバースプロキシ型です。閲覧者 → Imperva のネットワーク → オリジンサーバーの順に通り、オリジン側にソフトを入れる必要はありません。
サイトを追加すると Imperva からそのサイト用の CNAME（サブドメイン向け）と A レコード（ドメイン直下向け）が示されます。
オリジンの設定と証明書が整うまで DNS は変えません。
DNS を向けた後は、オリジンサーバーのファイアウォールで Imperva の IP 範囲以外からの 80/443 番を拒否します。これをしないと WAF を素通りして直接オリジンを攻撃できます。
オリジンから見た送信元 IP は Imperva のものになります。実 IP は Imperva が付けるヘッダー（Incap-Client-IP、X-Forwarded-For）から復元します。
2026年11月現在、Imperva の製品ドキュメントは Thales グループのサイト（docs-cybersec.thalesgroup.com）に移っています。

Imperva Cloud WAF のオリジン設定の流れ。サイトを追加、オリジン IP と証明書を設定、動作確認、DNS を Imperva へ、オリジンのファイアウォールで Imperva の IP 以外を拒否

Imperva Cloud WAF の仕組み

Imperva Cloud WAF は、DNS の向け先を Imperva に変えることで閲覧者のアクセスをいったん Imperva のネットワークに通し、WAF・DDoS 対策・CDN（キャッシュ）を適用してからオリジンサーバーへ転送するサービスです。構成要素は次のとおりです。

要素	役割
サイト（Website）	保護対象のドメイン。管理画面で追加する単位
オリジンサーバー（Origin server）	実際に WordPress が動いているサーバー。IP かホスト名で登録する
CNAME / A レコード	閲覧者を Imperva へ導くための DNS 設定。Imperva が値を提示する
証明書	Imperva が発行するサイト証明書、アカウント証明書、または自分で用意する証明書
配信ルール（Delivery rules）	ヘッダーの書き換えや転送など、通過するリクエストへの操作

このサイトで扱っている Cloudflare や Fastly と同じリバースプロキシ型であり、設定の考え方（DNS を向ける、オリジンを隠す、実 IP を復元する）は共通です。

手順 1: サイトを追加する

Imperva の管理画面でサイトを追加し、保護するドメイン（example.com や www.example.com）を登録します。追加直後は、Imperva が示す CNAME と A レコードの値を控えるだけにし、まだ DNS は変えません。

HTTPS のサイトでは、追加時に SNI のみ対応の設定が既定になっています。非 SNI の古いクライアントに対応する必要があるかどうかは、この時点では既定のままで進めて構いません。

手順 2: オリジンサーバーを設定する

サイトの設定で、オリジンサーバーの IP アドレス（またはホスト名）と、Imperva からオリジンへ接続するときのプロトコル・ポートを登録します。

オリジンへは HTTPS（443 番）で接続する設定にします。Imperva が HTTPS を終端してオリジンへは HTTP で送る構成（SSL オフロード）も可能ですが、公式の説明でも Imperva とオリジンの間が暗号化されない構成として位置づけられています。
1 台のオリジンで複数のドメインを運用している場合、同じオリジン IP を使うサイトどうしで CNAME を共用する設定があります。
オリジン側のバーチャルホストは、閲覧者が使ったホスト名（Host ヘッダー）がそのまま届く前提で動きます。オリジンのホスト名が公開ドメインと違う場合は、配信ルールで Host ヘッダーを書き換える設定を使います。

手順 3: 証明書を用意する

Imperva と閲覧者の間の HTTPS に使う証明書は 3 通りです。

種類	特徴
Imperva が発行するサイト証明書	SNI 対応クライアント向け。サイトに登録したドメインが対象。発行と更新は Imperva が自動で行う
Imperva が発行するアカウント証明書	SNI 非対応のクライアントにも対応。CNAME を共用する構成で使う
自分で用意する証明書	既存の証明書をアップロードする。SNI 対応クライアント向け。CNAME を共用するなら全ドメインを証明書に含める

Imperva が発行する証明書はドメインの所有確認を CNAME で行い、更新も自動です。確認用の CNAME レコードは更新のたびに使われるため、発行後も削除しません。

オリジンサーバー側の証明書はそのまま残します。Imperva からオリジンへ HTTPS で接続するときに使われます。

手順 4: 動作を確認してから DNS を向ける

DNS を変える前に、Imperva が示した IP に対して Host ヘッダーを指定して確認します。

# Imperva 経由でオリジンの応答が返るか（IP は管理画面に表示されたもの）
curl -sI --resolve example.com:443:<Imperva の A レコードの IP> https://example.com/ | head -n 10

応答ヘッダーに Imperva のものが含まれ、ページの内容がオリジンと同じなら通っています。問題がなければ DNS を変更します。

www.example.com などのサブドメイン: Imperva が示した CNAME を設定します。
example.com（ドメイン直下）: CNAME を置けないため、Imperva が示した A レコードを設定します。

変更後、dig +short www.example.com で Imperva の値が返ることを確認し、ブラウザーでログイン画面まで開けるかを見ます。

手順 5: オリジンへの直接アクセスを絞る

DNS を Imperva に向けても、オリジンの IP を知っている相手は直接アクセスできます。Imperva の公式の案内でも、送信元 IP でオリジンへのアクセスを制限しないとオリジンは保護されない、と明記されています。Imperva が使う IP 範囲の一覧は管理画面と API（my.imperva.com/api/integration/v1/ips）から取得でき、範囲が追加されることがあるため定期的に更新します。

Ubuntu の ufw での例です。実際の範囲は取得した一覧に置き換えます。

# いまの許可を確認
sudo ufw status numbered
# Imperva の範囲だけ 80/443 を許可（範囲ごとに繰り返す）
sudo ufw allow from 192.0.2.0/24 to any port 80,443 proto tcp
# それ以外からの 80/443 を拒否
sudo ufw deny 80/tcp
sudo ufw deny 443/tcp

Nginx の設定で allow / deny を書く方法もありますが、ファイアウォールで止めるほうが PHP まで届きません。IP 制限ができない共用サーバーでは、Imperva が付ける独自のヘッダーの有無をオリジン側で確認する方法を補助的に使いますが、ヘッダーだけでは直接アクセスを防げない点は Imperva のコミュニティでも説明されています。

手順 6: 実 IP を復元する

Imperva を通すと、オリジンの Web サーバーから見た送信元はすべて Imperva の IP です。Imperva は閲覧者の IP を Incap-Client-IP ヘッダーと X-Forwarded-For ヘッダーに入れて転送します。Web サーバーで復元します。

Nginx:

# Imperva の IP 範囲を信頼する（範囲は一覧に置き換える）
set_real_ip_from 192.0.2.0/24;
real_ip_header Incap-Client-IP;

Apache（mod_remoteip）:

RemoteIPHeader Incap-Client-IP
RemoteIPTrustedProxy 192.0.2.0/24

set_real_ip_from と RemoteIPTrustedProxy に Imperva の範囲だけを書くことが重要です。範囲を書かずにヘッダーだけ信じると、直接アクセスしてきた相手が任意の IP を名乗れます。

WordPress の観点

ログイン画面: WordPress のログイン試行の制限やコメントの IP 記録は、手順 6 の実 IP 復元が済んでいないとすべて Imperva の IP として扱われます。
キャッシュ: Imperva の CDN がページをキャッシュすると、ログイン中の表示や更新直後の反映が遅れます。管理画面（/wp-admin/）とログイン後のページはキャッシュ対象から外す設定にし、キャッシュプラグインとの二重キャッシュで更新が反映されない状態を避けます。
HTTPS 判定: Imperva が HTTPS を終端し、オリジンへ HTTP で送る構成にした場合は、WordPress がリダイレクトを繰り返します。オリジンへも HTTPS で接続する構成にするか、wp-config.php で X-Forwarded-Proto を見て HTTPS を補います（詳しい説明は「Caddy を WordPress の前に置くリバースプロキシ構成」の手順 2 と同じです）。
サーバー移転: オリジンの IP が変わるときは、Imperva 側のオリジン設定を更新し、新サーバーのファイアウォールにも Imperva の IP 範囲を入れます。移転の段取りは「サーバー移行を頼む場合の費用・期間・準備」を参照してください。

よくある質問

Imperva のオリジン設定で IP とホスト名のどちらを登録しますか

IP が固定なら IP で問題ありません。クラウドのロードバランサーのように IP が変わる相手はホスト名で登録します。ホスト名で登録した場合、Imperva がその名前を解決して接続します。

DNS を向けたらサイトが表示されなくなりました

オリジンのファイアウォールで Imperva の IP 範囲が許可されていない、オリジンへの接続プロトコルやポートの設定が実際と合っていない、証明書がまだ有効になっていない、のいずれかが多いです。手順 4 の curl --resolve で Imperva 経由の応答を確認し、オリジン側の access.log に Imperva からの接続が届いているかを見ます。

オリジンの IP を隠せば WAF を素通りされませんか

DNS の履歴やメールのヘッダーなどから過去の IP は分かるため、隠すだけでは足りません。ファイアウォールで Imperva の IP 範囲以外を拒否することが対策の中心です。可能ならオリジンの IP を新しいものに変えてから制限を掛けます。

Imperva のドキュメントが見つかりません

2026年11月現在、Imperva は Thales グループに属しており、製品ドキュメントは docs-cybersec.thalesgroup.com、コミュニティは community-cybersec.thalesgroup.com に移っています。旧 URL（docs.imperva.com）からは転送されます。

まとめ

Imperva Cloud WAF のオリジン設定は、サイト追加 → オリジン IP と証明書 → 確認 → DNS 変更の順で、DNS は最後に変えます。
DNS を向けた後は、オリジンのファイアウォールで Imperva の IP 範囲以外からの 80/443 番を拒否し、範囲の一覧を定期的に更新します。
実 IP は Incap-Client-IP を Web サーバーで復元し、信頼するのは Imperva の範囲だけにします。WordPress ではキャッシュの除外と HTTPS 判定を確認します。

参考: Imperva Cloud Application Security ドキュメント（Thales）、Imperva コミュニティ – Cloud WAF Workshop: Website Onboarding and TLS Implementation（2025-10）、nginx – ngx_http_realip_module、Apache – mod_remoteip

更新履歴: 2026-11-09 全面改訂（定型文を Imperva Cloud WAF のオリジン設定の手順に書き換え、DNS を最後に変える理由・オリジン IP の保護・実 IP の復元・WordPress のキャッシュと HTTPS 判定の注意を追加）。この記事はワードプレス博士（ライトセンド株式会社）が運営しています。