【図解】フォワードプロキシとリバースプロキシの違いとは？企業の構成例で初心者向けに解説

プロキシの設定画面やセキュリティ製品の資料を読んでいると、「フォワードプロキシ」と「リバースプロキシ」という言葉がよく出てきます。どちらも通信を代わりに中継する仕組みですが、誰の代わりをするのか、何を守るのかがまったく違います。

この記事では、2つのプロキシの違いを、企業ネットワークでよく見る構成の図と、通信の流れ（シーケンス）で説明します。設定ファイルや製品の画面ではなく、「どこに置いて、何をしているのか」がイメージできることを目指しています。

この記事でわかること

プロキシとは何か、フォワードとリバースは誰の代理なのか
フォワードプロキシの企業での構成と、通信の流れ
リバースプロキシの企業での構成と、通信の流れ
それぞれの主な機能と、メリット・注意点
CASBなどのセキュリティ製品で出てくる「プロキシ」とのつながり

この記事について

この記事は、HTTPの標準（RFC）と、Squid、NGINX、Apache、HAProxy、F5、Broadcom、Microsoft、AWS などが公開しているドキュメントを参考に、プロキシに共通する考え方を一般化してまとめたものです。特定の製品の機能や動作を説明・保証するものではありません。製品ごとの対応状況や設定は、各メーカーや販売代理店に確認してください。

プロキシを一言でいうと
1. 違いを表で整理する
フォワードプロキシ：社員の代わりに外へ出る
リバースプロキシ：サーバの代わりに受け付ける
2つを並べて理解する
セキュリティ製品の「プロキシ」とのつながり
まとめ

プロキシを一言でいうと

プロキシ（proxy）は「代理」という意味です。通信の間に入り、本来の相手の代わりに話をする中継役を指します。HTTPの仕様（RFC 9110）でも、クライアントが自分で選んで使う中継役を「プロキシ」、サーバの代わりに振る舞う中継役を「ゲートウェイ（別名リバースプロキシ）」と呼び分けています。

会社の窓口にたとえると分かりやすくなります。フォワードプロキシは、社員の手紙をまとめて外へ出してくれる郵便室です。宛先の会社には、社員個人ではなく会社の郵便室から手紙が届きます。リバースプロキシは、外からの電話を受ける代表窓口です。電話をかけた人は窓口としか話さず、裏で誰が対応しているかは知りません。

図1　フォワードプロキシはクライアントの代理、リバースプロキシはサーバの代理

違いを表で整理する

比べること	フォワードプロキシ	リバースプロキシ
誰の代理か	クライアント（社員のPC）	サーバ（Webサーバやアプリ）
置く場所	クライアントの近く（社内の出口、またはクラウド）	サーバの手前（DMZ、クラウドの公開側）
通信の向き	社内から外へ出ていく通信	外から入ってくる通信
守るもの	社員とその端末、社内の情報（外へ出すもの）	サーバと公開しているサービス
クライアントの設定	必要（ブラウザやOSにプロキシを指定する）。透過型なら不要	不要。利用者はプロキシがあることを意識しない
相手から見えるもの	Webサーバからは、プロキシのIPアドレスが見える	利用者からは、プロキシがWebサーバそのものに見える
主な役割	認証、URLフィルタ、ウイルス検査、ログ	負荷分散、TLSの終端、WAF、キャッシュ
よく見る製品の種類	プロキシサーバ、SWG（Secure Web Gateway）	ロードバランサ、WAF、CDN、Webサーバのプロキシ機能

フォワードプロキシ：社員の代わりに外へ出る

フォワードプロキシは、社員のPCがインターネットへ出ていくときの出口です。社員のPCは宛先のWebサーバに直接つながらず、プロキシに「このサイトを見たい」と頼みます。プロキシは誰が頼んだのかを確かめ、見てよいサイトかを判断してから、代わりにWebサーバへアクセスします。

企業でよくある構成（社内に置く場合）

昔からある形は、本社のネットワークの出口にプロキシサーバを置く構成です。支店の通信もWAN経由で本社に集め、同じプロキシから外へ出します。プロキシは止まると全員がWebを使えなくなるので、2台以上で冗長化するのが普通です。

図2　社内に置くフォワードプロキシの構成例

この構成のポイントは、ファイアウォールで「Web通信はプロキシからだけ許可する」ことです。社員のPCが直接インターネットへ出られないので、プロキシを通らない抜け道がなくなります。プロキシはActive Directoryと連携してユーザーを確かめ（Kerberosなど）、ダウンロードするファイルはICAPという仕組みでウイルス検査サーバに渡して調べます。

企業でよくある構成（クラウドに置く場合）

在宅勤務が増えると、本社のプロキシに通信を集める形では、社外のPCを守りにくくなります。そこで、プロキシの機能をクラウドのサービスとして使う形（SWG）が広がりました。拠点はルータからトンネルでつなぎ、在宅や外出先のPCは専用のエージェントで通信をクラウドへ送ります。

図3　クラウドに置くフォワードプロキシ（SWG）の構成例

PCをプロキシへ向ける方法

フォワードプロキシを使うには、PCの通信をプロキシへ向ける必要があります。方法は大きく「明示型（PC側で設定する）」と「透過型（ネットワーク側で横取りする）」に分かれます。

方法	やり方	特徴
手動設定	ブラウザやOSにプロキシのアドレスとポートを入力する	台数が多いと管理が大変
PACファイル	「どのサイトをどのプロキシへ送るか」を書いたファイルを配る	社内サイトは直接、外はプロキシ、のように振り分けられる。プロキシの切り替えも書ける
WPAD	DHCPやDNSで、PACファイルの場所をPCに自動で知らせる	PCの設定なしで配れる
グループポリシー・MDM	PACファイルのURLやプロキシ設定を、管理ツールで一括配布する	企業ではこの方法がよく使われる
透過型	ルータやスイッチ（WCCP、ポリシーベースルーティング）や通信経路上の機器で、Web通信をプロキシへ転送する	PCの設定が要らない。ただし、プロキシの認証が使いにくいなどの制約がある

PACファイルは、JavaScriptで書かれた小さな関数です。たとえば次のように書くと、社内のサイトは直接つなぎ、それ以外はプロキシ1号機を使い、つながらなければ2号機を使います。

PACファイルの例（proxy.pac）

function FindProxyForURL(url, host) {
  // 社内のサイトはプロキシを通さない
  if (isPlainHostName(host) || dnsDomainIs(host, ".example.local")) {
    return "DIRECT";
  }
  // それ以外は1号機、だめなら2号機
  return "PROXY proxy1.example.local:8080; PROXY proxy2.example.local:8080";
}

通信の流れ（HTTPSのサイトを見るとき）

HTTPSのサイトを見るとき、PCはプロキシに CONNECT というリクエストを送り、「このサーバまでトンネルを作ってほしい」と頼みます。プロキシが認証を求める場合は、まず 407 という応答で認証情報を要求し、PCが認証情報を付けて送り直します。

図4　フォワードプロキシ経由でHTTPSのサイトを見るときの流れ

トンネルができたあとは、PCとWebサーバが直接TLSで暗号化した通信をし、プロキシはそれを中継するだけです。この状態では、プロキシに見えるのは宛先のサーバ名くらいで、URLの細かい部分やファイルの中身は分かりません。中身まで検査したい場合は、プロキシが一度TLSを復号する「TLS復号（SSLインスペクション）」を使います。

主な機能

機能	内容
ユーザー認証	Active Directoryなどと連携し、誰の通信かを確かめる。ログにユーザー名が残る
URLフィルタ	サイトを「ギャンブル」「ショッピング」などのカテゴリに分け、業務に関係ないカテゴリを禁止する
TLS復号	HTTPSを一度復号して中身を検査する。端末には、プロキシが発行する証明書を信頼させておく
ウイルス・情報漏えいの検査	ファイルを検査サーバ（ICAP連携など）に渡して調べる
キャッシュ	よく見られるコンテンツをためて、通信量を減らす
ログ	誰が、いつ、どこへアクセスしたかを記録する。インシデントの調査に使う

メリットと注意点

メリット	注意点
Webへの出口を1か所にまとめ、ルールとログを一元化できる	止まると全員がWebを使えない。冗長化が必要
誰がどこへアクセスしたかを、ユーザー単位で記録できる	PCをプロキシへ向ける設定（PACの配布など）を管理する手間がある
危険なサイトやファイルを、社員の端末に届く前に止められる	TLS復号には証明書の配布が必要。証明書を固定しているアプリは復号できず、除外の設定が要る
社員のPCをインターネットに直接さらさずに済む	Web会議などの大量の通信が集中すると、遅くなりやすい

補足

フォワードプロキシを誰でも使える状態（オープンプロキシ）でインターネットに公開すると、攻撃の踏み台に使われます。社内の利用者だけが使えるように、送信元のアドレスや認証で利用者を限定してください。

リバースプロキシ：サーバの代わりに受け付ける

リバースプロキシは、サーバの手前に置いて、外からのアクセスを代わりに受け付ける仕組みです。利用者がアクセスするURLはリバースプロキシを指していて、利用者はその奥にあるサーバを意識しません。リバースプロキシは受け取ったリクエストを、裏にある複数のサーバへ振り分けます。

企業でよくある構成①：公開Webサイト

いちばんよく見るのが、会社のWebサイトやWebサービスを公開する構成です。DMZにリバースプロキシ（ロードバランサ）を2台置いて、片方が止まってももう片方が引き継げるようにします。Webサーバは内部のネットワークに置き、インターネットから直接は届かないようにします。

図5　公開Webサイトのリバースプロキシ構成例

リバースプロキシはHTTPSの暗号化をここで解き（TLSの終端）、Webサーバの負荷を減らします。サーバへの通信を再び暗号化することもできます。また、定期的にサーバの状態を確かめ（ヘルスチェック）、止まっているサーバにはリクエストを送りません。

企業でよくある構成②：社内アプリを社外から使う

社内の業務アプリを、在宅勤務の社員にも使わせたい場面です。昔はDMZにリバースプロキシを置き、ファイアウォールに外からの通信用の穴を開けていました。最近は、クラウドのアプリプロキシと、社内に置いた「コネクタ」を組み合わせる形が増えています。

図6　社内アプリを公開するコネクタ型の構成例

コネクタは社内からクラウドへ外向きにつながっておき、クラウドが受けたリクエストをその接続に乗せて社内アプリへ届けます。外から社内へ入る通信用のポートを開けなくてよいのが大きな利点です。利用者はクラウド側でIdP（ID基盤）の認証を受けるので、認証済みの通信だけが社内に届きます。ゼロトラストの考え方でよく出てくるZTNAも、これに近い仕組みです。

企業でよくある構成③：クラウド上のシステム

クラウド上にシステムを作る場合も、考え方は同じです。クラウドのL7ロードバランサが入口のリバースプロキシになり、サーバやコンテナはインターネットに直接さらさない側に置きます。さらに手前にCDN（コンテンツ配信ネットワーク）を置いて、キャッシュやWAFを任せることもよくあります。

図7　クラウドでのリバースプロキシ構成例

通信の流れ

利用者がWebサイトにアクセスすると、DNSはリバースプロキシのIPアドレスを返します。利用者のブラウザは、リバースプロキシをWebサーバそのものだと思ってHTTPSでつなぎます。

図8　リバースプロキシ経由の通信の流れ

リバースプロキシはサーバ証明書を持っていて、ここでTLSを終端します。中身を確かめたうえで正常なサーバを選び、リクエストを転送します。Webサーバからの応答も、いったんリバースプロキシを通って利用者に返ります。

主な機能

機能	内容
負荷分散	リクエストを複数のサーバに振り分ける（順番に、接続数の少ないサーバへ、など）
ヘルスチェック	サーバの状態を定期的に確かめ、止まっているサーバを振り分けから外す
TLSの終端	HTTPSの暗号化をここで解き、サーバの処理を減らす。証明書の管理もここに集約できる
WAF	SQLインジェクションなど、Webアプリへの攻撃を止める
キャッシュ・圧縮	画像などをためて返す。応答を圧縮して転送量を減らす
URLによる振り分け	`/images` は画像用のサーバへ、のように、URLやホスト名で送り先を変える
認証の肩代わり	サーバの手前でIdPの認証を済ませ、認証済みの利用者だけを通す
サーバを隠す	利用者からはリバースプロキシしか見えず、サーバの数やアドレスは分からない

クライアントのIPアドレスはどうなるのか

リバースプロキシが代わりにサーバへつなぐので、Webサーバから見た送信元は、利用者ではなくリバースプロキシのIPアドレスになります。そのままでは、Webサーバのアクセスログに利用者のIPアドレスが残りません。

そこでリバースプロキシは、元の送信元をHTTPヘッダーに書いてサーバへ渡します。よく使われるのが X-Forwarded-For で、標準化された Forwarded ヘッダー（RFC 7239）もあります。

リバースプロキシからWebサーバへ渡るリクエストの例

GET /index.html HTTP/1.1
Host: www.example.com
X-Forwarded-For: 203.0.113.10     <- 利用者のIPアドレス
X-Forwarded-Proto: https          <- 利用者が使ったプロトコル

このヘッダーは利用者が自分で書き換えて送ることもできます。Webサーバ側では、信頼できるリバースプロキシから来た値だけを使う設定にしておきます。

メリットと注意点

メリット	注意点
サーバを増やしても、利用者のURLは変わらない	止まるとサービス全体が止まる。冗長化（稼働系と待機系など）が必要
サーバを直接インターネットにさらさずに済む	証明書をリバースプロキシで管理する。サーバまで暗号化するなら、サーバ側にも証明書が要る
TLSや攻撃対策を入口でまとめて処理できる	サーバから見た送信元がプロキシになる。X-Forwarded-Forなどの扱いを決めておく
メンテナンス時に、サーバを1台ずつ振り分けから外せる	ホスト名やURLを書き換えると、アプリのリダイレクトやCookieがうまく動かないことがある。WebSocketなどは追加の設定が要る場合がある

補足

ロードバランサには、TCPやUDPのレベルで振り分ける「L4」と、HTTPの中身（URLやヘッダー）まで見て振り分ける「L7」があります。この記事でいうリバースプロキシは、主にL7の動きです。L4のロードバランサは、HTTPの中身を見ないぶん高速ですが、URLによる振り分けやWAFはできません。

2つを並べて理解する

実際の企業では、フォワードプロキシとリバースプロキシの両方を使っています。社員がインターネットへ出ていく通信はフォワードプロキシ、社外の利用者が会社のWebサイトへ入ってくる通信はリバースプロキシ、と向きで分けると整理しやすくなります。

図9　1つの会社の中のフォワードプロキシとリバースプロキシ

セキュリティ製品の「プロキシ」とのつながり

CASBやSWGなどのクラウドのセキュリティ製品の説明にも、フォワードプロキシとリバースプロキシが出てきます。考え方はこの記事と同じです。

製品の説明での言葉	この記事の考え方でいうと
フォワードプロキシ（インライン）	会社のPCの通信をすべてクラウドのプロキシに通す。図3の形で、社員の代理として外へ出る
リバースプロキシ	サインインのときに通信をプロキシへ振り向け、クラウドサービスの代わりに受け付ける。エージェントを入れられない個人のPCでも制御できる

セキュリティ製品のリバースプロキシは、自社のサーバではなく、利用しているクラウドサービス（SaaS）の手前に入る点が、この記事の公開Webサイトの例と違います。仕組みは同じで、利用者がアクセスする先をプロキシに向け、プロキシが本物のサービスへ中継します。

まとめ

フォワードプロキシとリバースプロキシは、どちらも通信を代わりに中継する仕組みです。違いは「誰の代理か」で、フォワードはクライアント（社員）の代理として外へ出る通信を、リバースはサーバの代理として外から入る通信を受け持ちます。

	フォワードプロキシ	リバースプロキシ
ひと言で	社員の代わりに外へ出る出口	サーバの代わりに外から受け付ける入口
企業での構成	社内の出口に置く（図2）、クラウドに置く（図3）	公開Webサイト（図5）、社内アプリの公開（図6）、クラウド（図7）
代表的な機能	認証、URLフィルタ、TLS復号、ウイルス検査、ログ	負荷分散、ヘルスチェック、TLSの終端、WAF、キャッシュ
気を付けること	冗長化、PACの配布、TLS復号の除外設定	冗長化、証明書の管理、クライアントIPの引き継ぎ