プロキシとリバースプロキシとは？誰の代わりに立つかの違い¶
最終確認: 2026-10-27
SASEの全体像に戻る
30秒で復習¶
- プロキシ（フォワードプロキシ）＝利用者の代わりに、インターネットへ出ていく代理人。 社員のPCとインターネットの間に置き、Webアクセスを検査・記録する。
- リバースプロキシ＝サーバーの代わりに、利用者からの通信を受ける代理人。 Webサーバーの前に置き、HTTPS・振り分け・負荷分散・WAFなどを引き受ける。
- 見分け方は「誰の代わりか・誰が存在を知っているか」。フォワードは利用者側が設定して使う。リバースは利用者からは見えず、サーバーそのものに見える。
- SWGはクラウド版のフォワードプロキシ。IIS・Nginx・ロードバランサー・Entra のアプリケーションプロキシはリバースプロキシの仲間。
- どちらも、後ろに渡すときに本当の接続元IPを
X-Forwarded-Forなどで伝える。このヘッダーは偽装できるので、信頼してよい相手を決める。 - 攻撃者の視点で見ると：攻撃者もプロキシで身元を隠すので、IPや国だけのブロックは効きにくい。会社のプロキシは攻撃者にとって邪魔な関所なので、正規のクラウドや検査対象外の通信に紛れようとする。さらに、攻撃者自身がプロキシ（中間者）になって、MFAのあとのログイン情報を盗む手口（AiTMフィッシング）もある。
- 覚え方：フォワード＝「社員の代わりに買い物に行く総務」、リバース＝「お店の入口の受付」
こんな場面で出会う¶
- ブラウザやアプリの設定に「プロキシサーバー：proxy.example.com:8080」と入っている
- Web サーバーの前に IIS・Nginx・ロードバランサーが置いてあり、アプリのログの IP が全部同じになる
- 本物そっくりのログイン画面のフィッシング（AiTM）で、MFA まで突破されたというニュースを見る
用語の正式名称と読み方¶
| 用語 | 意味 |
|---|---|
| プロキシ（proxy） | 代理。間に入って、代わりに通信するサーバー |
| フォワードプロキシ | 利用者側の代理。ふつう「プロキシ」と言ったらこちら |
| リバースプロキシ | サーバー側の代理。逆（reverse）向きのプロキシ |
| 明示的プロキシ | PCやブラウザに「このプロキシを使う」と設定して使う方式 |
| 透過プロキシ | PCには設定せず、ネットワーク機器で通信を横取りしてプロキシへ通す方式 |
| PACファイル | 「この宛先はプロキシ経由、この宛先は直接」を決める設定ファイル |
| CONNECT | HTTPS の通信を、プロキシの中を素通りするトンネルにする命令 |
| TLS終端 | HTTPS の暗号をプロキシでほどき、後ろへは中身を見える形で渡すこと |
| X-Forwarded-For | プロキシが後ろへ伝える「本当の接続元IP」のヘッダー |
質問：プロキシとリバースプロキシは何が違う？¶
答え： どちらも「間に入る代理人」。違いは誰の代わりに立つか。
| 観点 | フォワードプロキシ | リバースプロキシ |
|---|---|---|
| 誰の代理？ | 利用者（社員のPC） | サーバー（Webサイト・アプリ） |
| 置き場所 | 社内ネットワークの出口、またはクラウド | Webサーバーの前（データセンター・クラウド） |
| 守るもの | 社員と会社（危険なサイト、情報の持ち出し） | サーバー（攻撃、負荷、内部構成の露出） |
| 存在を知っているのは | 利用者側（PCに設定する） | サーバー側だけ（利用者からはサーバーそのものに見える） |
| 相手から見えるIP | プロキシのIP（社員のIPは隠れる） | プロキシのIP（後ろのサーバーのIPは隠れる） |
| 主な機能 | URLフィルタ、ウイルス検査、ログ、キャッシュ、送信元IPの固定 | HTTPS（TLS終端）、振り分け、負荷分散、WAF、キャッシュ、圧縮 |
| 例 | Squid、社内プロキシ機器、SWG（Zscaler など） | Nginx、IIS、Apache、HAProxy、F5、Azure Application Gateway、AWS ALB、Cloudflare |
イメージ（たとえ話）¶
- フォワードプロキシ＝社員の代わりに買い物に行く総務。社員は総務に頼むだけ。お店から見えるのは総務の人で、総務は「その店はダメ」「それは持ち出し禁止」とチェックもする。
- リバースプロキシ＝お店の入口の受付。お客さんは受付をお店そのものだと思って話しかける。受付が、混んでいない店員に案内し、怪しい人は入口で止める。奥の店員の顔は外からは見えない。
質問：フォワードプロキシはどう動く？¶
答え： PCがインターネットへ出るとき、直接ではなくプロキシに頼む。プロキシが中身を確かめて、代わりに相手のサイトへつなぐ。
つなぎ方は2通り¶
| 方式 | 仕組み | 特徴 |
|---|---|---|
| 明示的プロキシ | PC・ブラウザに、プロキシのアドレスや PACファイルを設定する | ユーザー認証やログが取りやすい。設定の配布が必要 |
| 透過プロキシ | ルーターやファイアウォールで、Web通信をプロキシへ横取りする | PCの設定がいらない。HTTPS の扱いが難しい |
HTTPS はどう通る？（CONNECT と SSL/TLS 検査）¶
今のWebの大半は HTTPS（暗号化）なので、プロキシはそのままでは中身を見られない。
- CONNECT（トンネル）：PCが「
www.example.com:443へのトンネルを作って」と頼み、プロキシは行き先（ドメイン名）だけ見て、中身は素通しにする。URLの細かいパスやファイルの中身は見えない。 - SSL/TLS 検査：プロキシがいったん暗号をほどいて中身を検査し、もう一度暗号化して送る。ウイルス検査やDLPができる代わりに、PCに検査用のルート証明書を入れておく必要がある（→証明書の仕組み）。金融・医療サイトなどは検査の対象外にすることが多い。
質問：リバースプロキシは何をしてくれる？¶
答え： サーバーの入口の受付として、Webサーバーが自分でやると大変なことを、まとめて引き受ける。
| 機能 | 内容 | うれしいこと |
|---|---|---|
| TLS終端 | HTTPS の暗号をリバースプロキシでほどく | 証明書の管理が1か所で済む。後ろのサーバーが楽になる |
| 振り分け（ルーティング） | ホスト名やパスで、後ろのサーバーを選ぶ | 1つの入口（443番）で、複数のアプリを公開できる |
| 負荷分散 | 後ろの複数台に通信を分ける。止まった台は外す | 台数を増やして混雑に強く、1台壊れても止まらない |
| WAF | SQLインジェクションなど、Webアプリへの攻撃を止める | アプリを直さなくても、入口で守れる |
| キャッシュ・圧縮 | 画像などを覚えておいて返す、データを縮める | 速くなり、サーバーの負荷が減る |
| 内部構成を隠す | 後ろのサーバーのIPや台数は外から見えない | 攻撃の手がかりを与えない |
- Kestrel（ASP.NET Core のWebサーバー）を、IIS や Nginx の後ろに置くのは、まさにこの使い方。
- CDN（Cloudflare など）や、クラウドのロードバランサー（Application Gateway、ALB）も、大きなリバースプロキシと考えられる。
質問：これまでのノートとどうつながる？¶
| ノート | プロキシとの関係 |
|---|---|
| SWG | クラウド版のフォワードプロキシ。社内のプロキシ機器を置き換える |
| SASE導入時の設計ポイント | 社内のフォワードプロキシを廃止するときのチェック項目（PACファイル、送信元IPの固定など） |
| ZTNA | 社内アプリを外から使わせる仕組み。Entra のアプリケーションプロキシは、外向きにつなぐコネクタを使ったリバースプロキシの一種 |
| DLP | プロキシ（SWG）で HTTPS を検査できて初めて、通信の中身の DLP が効く |
| Kestrel | リバースプロキシの後ろに置くときは、Forwarded Headers の設定が必要 |
質問：攻撃者から見ると、プロキシはどう見える？（逆の視点）¶
答え： 攻撃者にとってプロキシは、①身元を隠す道具であり、②会社に入る・持ち出すときの邪魔な関所であり、③自分が化けて中間に入る手段でもある。守る側は、この3つの立場を知っておくと対策を選びやすい。
① 攻撃者がプロキシを使う：身元を隠す¶
攻撃者は、自分のIPアドレスを隠すために、プロキシを何段も経由して攻撃してくる。
| 攻撃者が使うもの | 中身 | 守る側への影響 |
|---|---|---|
| 匿名プロキシ・VPNサービス | 誰でも使える中継サービス | 接続元のIPが、攻撃者の本当のIPではない |
| Tor | 何段も中継して、発信元をたどれなくする仕組み | 出口のIPは公開されているので、まとめて拒否はできる |
| 住宅用プロキシ（レジデンシャル） | 一般家庭の回線（乗っ取られた機器や、アプリに仕込まれた中継）を経由する | 普通の家庭のIPに見えるので、IPの評判では見分けにくい |
| 踏み台（オープンプロキシ・乗っ取ったサーバー） | 設定の甘いプロキシや、乗っ取った他社のサーバーを中継に使う | 被害者のIPに見える。自社のプロキシが踏み台にされることもある |
守る側の考え方： 「海外のIPだから拒否」「怪しいIPリストで拒否」だけでは足りない。IDの認証（MFA）・端末の状態・振る舞いで判断する（→SASEの認証と条件による制御）。
② 会社のプロキシは、攻撃者にとって邪魔な関所¶
社内のPCにマルウェアを入れても、外の攻撃者のサーバー（C2：指令サーバー）と通信できなければ、操ることも情報を持ち出すこともできない。会社のプロキシ（SWG）はその出口に立ちはだかるので、攻撃者は関所をすり抜けようとする。
| プロキシが攻撃者を邪魔すること | 攻撃者の狙い（すり抜け方の考え方） | 守る側の対策 |
|---|---|---|
| 危険なサイトへの通信を止める | 正規のクラウドサービス（ファイル共有・チャット・コード置き場など）に紛れる。登録したばかりのドメインを使う | CASBのテナント制御で個人アカウントを止める（→CASB）。新しく登録されたドメインを止める |
| HTTPS の中身を検査する | 検査の対象外にしているカテゴリ（金融・医療など）に紛れる | 対象外は必要最小限にする |
| 通信を記録する | プロキシを通らない出口を探す（直接の外向き通信、DNS を使った持ち出し） | ファイアウォールでプロキシ以外の外向き通信を止める、DNS も検査する（→FWaaS） |
| ログインしないと使えない（認証プロキシ） | PCの中に入ってしまえば、利用者の設定と認証でそのまま通れる | プロキシだけに頼らず、EDRで端末の中の怪しい動きを見る |
- 攻撃者から見ると、プロキシがない会社は出口が素通し。プロキシ（SWG）があると、少なくとも「普通のやり方では外と話せない」「やり取りが記録される」状態にできる。
- ただし、プロキシは通信の出口しか見ていない。中に入られた後の動き（社内同士の移動）は、EDR やセグメント分割で見る。
③ 攻撃者がプロキシになる：中間者（AiTM）フィッシング¶
いちばん注意したいのが、攻撃者自身がリバースプロキシになる手口。偽のログイン画面が、実は本物のサイトへの中継になっていて、利用者は本物と同じ画面でログインし、MFAも通ってしまう。攻撃者は中継しながら、MFAのあとに発行されるログイン済みの情報（セッションCookie）を盗む。
| 手口 | 何が起きる | 守る側の対策 |
|---|---|---|
| AiTMフィッシング | パスワードとMFAを本物に中継され、ログイン済みのCookieを盗まれる。普通のMFAでは防げない | フィッシングに強いMFA（パスキー・FIDO2、証明書による認証）。条件付きアクセスで会社の端末からだけ許可する。トークンの保護 |
| プロキシ設定の乗っ取り（WPAD・PACファイル） | PCが自動で探すプロキシ設定を偽物にすり替えられ、通信が攻撃者のプロキシを通る | 自動検出（WPAD）を使わないなら止める。PACファイルの配布元を固定する |
| 怪しい無料のプロキシ・VPN | 利用者が自分で使った中継サービスに、通信をのぞかれる・書き換えられる | 会社の端末では使わせない。SASEのエージェントで通信を必ず会社の経路に通す |
④ リバースプロキシを、攻撃者はどう見る？¶
Webサイトの前にリバースプロキシ（WAF・CDN）があると、攻撃者からは後ろのサーバーが見えないし、入口で攻撃が止められる。そこで攻撃者は、受付を通らない道や、受付と奥の食い違いを狙う。
| 攻撃者の狙い | 中身 | 守る側の対策 |
|---|---|---|
| 後ろのサーバーに直接つなぐ | 本当のサーバーのIP（オリジン）を調べて、WAFを通らずに攻撃する | オリジンはリバースプロキシからの通信だけ受けるようにする |
| 接続元IPを偽る | X-Forwarded-For を自分で付けて、IP制限をすり抜ける |
信頼するプロキシから来た値だけを使う（→Kestrel） |
| 受付と奥の解釈のずれを突く | プロキシと後ろのサーバーで、リクエストの区切り方の解釈がずれると、1つのリクエストに別のリクエストを紛れ込ませられる（HTTPリクエストスマグリング） | プロキシと後ろのサーバーを最新に保つ。おかしな形のリクエストは入口で拒否する |
質問：気をつけることは？¶
| 注意点 | 起きること | 対策 |
|---|---|---|
| オープンプロキシ | 誰でも使えるフォワードプロキシをインターネットに出すと、攻撃の踏み台にされる | 社内やログインしたユーザーだけが使えるようにする |
| X-Forwarded-For の偽装 | 利用者が自分でこのヘッダーを付けて送ると、接続元IPを偽れる | 信頼するプロキシから来た値だけを使う（KnownProxies など） |
| SSL/TLS 検査の証明書 | 検査用のルート証明書がPCにないと、証明書エラーが大量に出る | Intune などで事前に配る。検査対象外のサイトを決める |
| リバースプロキシが1台だけ | そこが止まると、後ろのサービスが全部止まる | 2台以上にする、クラウドのロードバランサーを使う |
| プロキシで全部を守った気になる | 社内同士の通信や、プロキシを通らない通信は守れない | EDR、セグメント分割、FWaaSなどと組み合わせる |
具体例¶
| 場面 | 使うもの |
|---|---|
| 社員が危険なサイトを開かないようにしたい | フォワードプロキシ（今ならクラウドの SWG） |
| 取引先のシステムが「うちのIPからだけ許可」している | フォワードプロキシで送信元IPを固定する |
1台のサーバーで、app.example.com と api.example.com を公開したい |
リバースプロキシでホスト名で振り分け |
| Webアプリを2台に増やして、止まらないようにしたい | リバースプロキシ（ロードバランサー）で負荷分散 |
| 社内のWebアプリを、VPNなしで社外から使わせたい | ZTNA・アプリケーションプロキシ |
関連メモ¶
- SWG（Secure Web Gateway）とは？
- SASE導入時の設計ポイント：社外の通信とプロキシ廃止
- ZTNA（Zero Trust Network Access）とは？
- 電子署名・証明書・ルート証明書の仕組み
- Kestrelとは？（ASP.NET Core のWebサーバー）
確認したいこと¶
- 社内のフォワードプロキシは、明示的プロキシ（PACファイル）と透過プロキシのどちらか
- HTTPS の検査（SSL/TLS 検査）をしているか。検査の対象外にしているサイトはどれか
- 社内のWebアプリの前に、リバースプロキシ（IIS ARR、Nginx、ロードバランサーなど）はあるか。何台か
- リバースプロキシの後ろのアプリで、本当の接続元IPがログに残っているか
- プロキシを通らずに外へ出られる経路（直接の外向き通信、DNS）は止めているか
- MFAは、AiTMフィッシングに強い方式（パスキー・FIDO2、証明書）になっているか。会社の端末からだけ許可しているか
- Webサイトの本当のサーバー（オリジン）は、リバースプロキシからの通信だけを受けるようになっているか