プロキシとリバースプロキシとは？誰の代わりに立つかの違い¶

2026-10-27 更新約9分で読めます

最終確認: 2026-10-27
SASEの全体像に戻る

30秒で復習¶

プロキシ（フォワードプロキシ）＝利用者の代わりに、インターネットへ出ていく代理人。 社員のPCとインターネットの間に置き、Webアクセスを検査・記録する。
リバースプロキシ＝サーバーの代わりに、利用者からの通信を受ける代理人。 Webサーバーの前に置き、HTTPS・振り分け・負荷分散・WAFなどを引き受ける。
見分け方は「誰の代わりか・誰が存在を知っているか」。フォワードは利用者側が設定して使う。リバースは利用者からは見えず、サーバーそのものに見える。
SWGはクラウド版のフォワードプロキシ。IIS・Nginx・ロードバランサー・Entra のアプリケーションプロキシはリバースプロキシの仲間。
どちらも、後ろに渡すときに本当の接続元IPを X-Forwarded-For などで伝える。このヘッダーは偽装できるので、信頼してよい相手を決める。
覚え方：フォワード＝「社員の代わりに買い物に行く総務」、リバース＝「お店の入口の受付」

用語の正式名称と読み方¶

用語	意味
プロキシ（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 の設定が必要

質問：気をつけることは？¶

注意点	起きること	対策
オープンプロキシ	誰でも使えるフォワードプロキシをインターネットに出すと、攻撃の踏み台にされる	社内やログインしたユーザーだけが使えるようにする
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・アプリケーションプロキシ

確認したいこと¶

社内のフォワードプロキシは、明示的プロキシ（PACファイル）と透過プロキシのどちらか
HTTPS の検査（SSL/TLS 検査）をしているか。検査の対象外にしているサイトはどれか
社内のWebアプリの前に、リバースプロキシ（IIS ARR、Nginx、ロードバランサーなど）はあるか。何台か
リバースプロキシの後ろのアプリで、本当の接続元IPがログに残っているか