リバースプロキシとフォワードプロキシの違いを簡単に解説

プロキシとは？

プロキシサーバには主に

1. フォワードプロキシ（プロキシ）
2. リバースプロキシ

があります。

そもそも、プロキシ(proxy)は英語で「代理」という意味があります。

つまり、プロキシサーバとは代わり（代理）になってくれるサーバのことです。

何の代わりになってくれるのでしょうか？

プロキシを使わない時（代理無しで直接）

web検索の例を見てみましょう。

プロキシを介さない接続

www.example.comというウェブページを検索する人（クライアント）がwebサーバーにページデータを要求（リクエスト）します。

するとwebサーバはその要求にあったデータをクライアントに返します。

このときは代理となるサーバーはいないので直接的な接続、プロキシサーバなしの接続です。

プロキシサーバ（フォワードプロキシ）は伝言係

それではプロキシサーバを使って接続した場合を見てみましょう。

プロキシサーバは人間で言えば「伝言係」です。

プロキシサーバはクライアントとwebサーバーの伝言係

クライアントはwww.example.comのデータをもっているwebサーバ(www.example.comのサーバー）に直接webページを要求せずにプロキシサーバに要求します。

プロキシサーバはクライアントの代わりにwebサーバからページを要求し受け取ったページをクライアントに返します。

プロキシサーバの必要性

なぜわざわざプロキシサーバを使うのか？というと

1. webサーバに身バレせずにwebページを閲覧したい(匿名アクセス）
2. クライアントが接続できるwebサーバを制限したい（社内や学校）

1つ目の匿名アクセスは、webサーバ上に自分の足跡が残るのを避けるためにプロキシサーバに代わりにページを取得してもらうというような匿名アクセスをするために使ったりします。

また、日本国内のみのアクセスしか許していないwebサーバに海外からアクセスしたいときに日本にあるプロキシサーバを介してアクセスしてリージョン制限を回避したいときに使うこともできます。

2つ目のクライアントの接続先制限は主に学校や社内で業務に関係ないサイトへのアクセスを禁止したいという場合にプロキシサーバが役立ちます。

インターネットへのアクセスはプロキシサーバを介して接続するように設定することで、プロキシサーバ側でwww.example.comへの接続は許可、aaa.example.netへの接続は拒否というようなアクセス制限を設定することができます。

リバースプロキシとは？

リバースプロキシはパッと見ではプロキシと違いは分かりにくいです。動きは通常のプロキシと同様にwebサーバとクライアントの間に入って仕事をします。

分かりやすくするためにもう一度普通のプロキシサーバ(フォワードプロキシ）を見てみます。

クライアントはプロキシサーバのIPアドレス198.51.100.10を登録してプロキシサーバを介してwebサーバに接続するように設定します。

www.example.comのページを見るときも、別のサーバにあるnetdekagaku.comを見るときもこのプロキシサーバ（198.51.100.10)を代理にしてアクセスします。

普通のプロキシサーバ

リバースプロキシサーバの場合はwebサーバの代わりにクライアントのリクエストを受け付けてwebサーバのコンテンツを要求、クライアントに返します。

リバースプロキシはwebサーバ側に設置されていてクライアントは意図してプロキシサーバを利用できない

飲食店でいえば、クライアントがお客さんだとするとリバースプロキシとwebサーバは店員で、リバースプロキシは注文を受け取る「ウェイター」のような存在です。

クライアントから見ればリバースプロキシもwebサーバもwww.example.comの店員で区別できない感じです。

そのため、例えばnetdekagaku.comのwebサーバにアクセスする時は、フォワードプロキシの時のように同じプロキシサーバは使いません。

www.example.comとは別の店(netdekagaku.com)なので、ウェイターであるリバースプロキシもnetdekgaku.comのリバースプロキシが使われます。

適格な表現ではありませんが、フォワードプロキシがクライアント側の使い走りで注文を店員に伝言する人（クライアント側の人間）ならリバースプロキシは店側のウェイターのような感じです。

ちょっとややこしいので整理します。

プロキシサーバとリバースプロキシを下図に両方登場させてみました。

プロキシサーバはクライアント側の者（的確ではない）なのでクライアントがwebブラウジングするときはクライアントが指定したプロキシサーバを介してwebサーバに接続します。（www.example.comもnetdekagaku.comに接続する時もこのプロキシサーバを中継します。）

しかし、リバースプロキシサーバはwebサーバ側が用意するものなのでwww.example.comはリバースプロキシサーバが無いけど、netdekagaku.comには有るという状況があり得ます。netdekagaku.comにアクセスするときはプロキシサーバがnetdekagaku.comのサーバにアクセスしてリバースプロキシサーバは要求を受け取って、webサーバからコンテンツを受け取り、返します。

リバースプロキシとフォワードプロキシの両方が登場した場合

リバースプロキシサーバは何のために使う？

一見注文を受け取るだけのリバースプロキシサーバをwebサーバが用意するのはなぜでしょうか？

その一つの目的が「負荷分散：ロードバランシング」です。

リバースプロキシはクライアントからの注文受付係で、実データはwebサーバ側にあります。この時容量の大きいデータをリバースプロキシに返す時webサーバが一台だけでは要求にこたえられない場合があります。飲食店でいえば注文多すぎてキッチン要員が1人では回せない状態になるパターンがあります。

下図のようにwebサーバを2台用意すれば仮に1台がまだ返せなくてももう一方がコンテンツを返すというように負荷を複数台間で分散（負荷分散）することが可能です。これはフォワードプロキシではできないですよね？

webサーバAと同じデータを持つwebサーバAコピーを用意して複数台構成でクライアントからの要求にこたえる（負荷を分散できる）

こういった負荷を分散する役割があるものをロードバランサ―といいます。

リバースプロキシは注文を受け付けるだけの役割であれば、受け付けるものはwww.example.comだけでなくても構いません。サイト運営者が管理しているドメインwww.example.comの他にaaa.example.jpがあればその要求がきたらそのwebサーバにコンテンツ要求をするといった使い方もできます。

リバースプロキシはセキュリティの観点からも有用です。サーバをインターネット上に公開するというのはそれだけ外部からの攻撃の的になるので、なるべくは避けたいものです。

こんな時にwebサーバは全く外部に公開しなくても、外部に公開したリバースプロキシを一つ用意すれば、インターネットからの注文受付はリバースプロキシで行って、リバースプロキシからローカルの外部公開されていないwebサーバにコンテンツを要求、受け取って、インターネット上のクライアントに返すといったことも可能です。こういった感覚からリバースプロキシの裏にあるwebサーバはバックエンドサーバと呼ぶことがあります。

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

apacehはメジャーなwebサーバです。apacheを使ってリバースプロキシ設定を行う方法を紹介します。

apachenのバージョンによって違いますが、まずmod_proxyが必要です。

netdekagaku.com/proxyのファイルはwebサーバbbb.example.com/proxyを表示するようにしたい時

apacheのconfファイルに

これでクライアント側からはnetdekagaku.com/proxyを取得していますが、実際はbbb.example.com/proxyのデータを参照していることになる。