プロキシサーバーとリバースプロキシサーバーの違いは何ですか？

以前の答えは正確でしたが、おそらく簡潔すぎます。いくつか例を追加してみます。

まず、「プロキシ」という言葉は、誰かまたは他の誰かのために行動する何かを表します。

コンピューターの領域では、1台のサーバーが別のコンピューターの代わりに動作することについて話します。

アクセシビリティのために、私は議論をWebプロキシに限定しますが、プロキシの概念はWebサイトに限定されません。

フォワードプロキシ

Webプロキシに関するほとんどの議論は、「フォワードプロキシ」と呼ばれるプロキシのタイプに言及しています。

この場合のプロキシイベントは、「フォワードプロキシ」が元の要求先に代わって別のWebサイトからデータを取得することです。

3台のコンピューターの物語（パートI）

例として、インターネットに接続されている3台のコンピューターをリストします。

• X =ご使用のコンピューター、またはインターネット上の「クライアント」コンピューター
• Y =プロキシWebサイト、proxy.example.org
• Z =アクセスしたいWebサイト、www.example.net

通常は、 X --> Z.

ただし、一部のシナリオでは、次のように連鎖Y --> Zするの代わりに使用する方が適してXいますX --> Y --> Z。

Xがフォワードプロキシサーバーを使用する理由：

フォワードプロキシサーバーの使用の（非常に）部分的なリストを次に示します。

• 1）XはZに直接アクセスできません。

  • a）Xインターネット接続の管理権限を持つ誰かが、サイトへのすべてのアクセスをブロックすることを決定しましたZ。

    • 例：

      • ストームワームウイルスはfamilypostcards2008.com、人々をだまして訪問させることで拡散しているため、システム管理者はサイトへのアクセスをブロックして、ユーザーが誤って自分自身に感染するのを防ぎます。

      • 大企業の従業員は時間を浪費しすぎているfacebook.comため、経営者は営業時間中にアクセスをブロックしたいと考えています。

      • 地元の小学校では、playboy.comウェブサイトへのインターネットアクセスを禁止しています。

      • 政府はニュースの発行を制御できないため、などのサイトをブロックして、ニュースへのアクセスを制御しますwikipedia.org。TORまたはFreeNetを参照してください。

  • b）の管理者がZをブロックしましたX。

    • 例：

      • Zの管理者は、Xからのハッキングの試みに気付いたため、XのIPアドレス（および/またはネットレンジ）をブロックすることにしました。

      • Zはフォーラムのウェブサイトです。 Xフォーラムをスパムしています。ZはXをブロックします。

REVERSEプロキシ

3台のコンピューターの物語（パートII）

この例では、インターネットに接続されている3台のコンピューターをリストします。

• X =ご使用のコンピューター、またはインターネット上の「クライアント」コンピューター
• Y =リバースプロキシWebサイト、proxy.example.com
• Z =アクセスしたいWebサイト、www.example.net

通常は、 X --> Z.

ただし、一部のシナリオでは、管理者がZ直接アクセスを制限または禁止し、訪問者に最初にYを通過させることをお勧めします。したがって、以前と同様に、のY --> Z代わりにによって取得されるデータがありX、次のようにチェーンされますX --> Y --> Z。

今回の「フォワードプロキシ」との違いは、ユーザーXはと通信しているだけなZので、今回はユーザーがアクセスしていることを知らないという点です。サーバーはクライアントからは見えず、リバースプロキシのみが外部から見えます。リバースプロキシは、クライアント側で（プロキシ）構成を必要としません。XYZY

クライアントXは、彼がY（X --> Y）とのみ通信していると考えていますが、実際には、Yすべての通信を（X --> Y --> Z再び）転送しています。

Zがリバースプロキシサーバーをセットアップする理由：

• 1）Zは、Webサイトへのすべてのトラフィックが最初にYを通過するように強制したいと考えています。
  • a）Zには大規模なWebサイトがあり、何百万もの人々が見たいと思っていますが、単一のWebサーバーがすべてのトラフィックを処理することはできません。したがって、Zは多くのサーバーをセットアップし、インターネットにリバースプロキシを配置して、ユーザーがZにアクセスしようとしたときに最も近いサーバーにユーザーを送信します。これは、コンテンツ配信ネットワーク（CDN）の概念の一部です。
    • 例：
      • Apple TrailersはAkamaiを使用しています
      • Jquery.comは、CloudFront CDNを使用してJavaScriptファイルをホストします（サンプル）。
      • 等
• 2）Zの管理者は、サーバーでホストされているコンテンツの報復について心配しており、メインサーバーを直接公開したくない。
  • a）「カナダ薬局」などのスパムブランドの所有者は何千ものサーバーを所有しているように見えますが、実際にはほとんどのWebサイトがはるかに少ないサーバーでホストされています。さらに、スパムに関する不正行為の苦情は、メインサーバーではなくパブリックサーバーのみをシャットダウンします。

上記のシナリオでZは、を選択する機能がありますY。

投稿からのトピックへのリンク：

コンテンツ配信ネットワーク

• CDNのリスト
  • http://www.mytestbox.com/miscellaneous/content-delivery-networks-cdn-list/
  • http://blog.streamingmedia.com/the_business_of_online_vi/2008/01/updated-list-of.html

フォワードプロキシソフトウェア（サーバー側）

• PHPプロキシ
• cgi-proxy
• phproxy （廃止）
• グリープ
• インターネット検閲Wiki：Webプロキシのリスト
• イカ （どうやら、リバースプロキシとしても機能します）

HTTP用のリバースプロキシソフトウェア（サーバー側）

• Apache mod_proxy（HTTPのフォワードプロキシとしても機能します）
• nginx （hulu.com、スパムサイトなどで使用）
• HAProxy
• キャディウェブサーバー
• lighthttpd
• perlbal（livejournal用に作成）
• 移植
• ポンド
• ニスキャッシュ（FreeBSDカーネルの第一人者によって書かれた）
• 安息

TCP用リバースプロキシソフトウェア（サーバー側）

• 残高
• 委任する
• ペン
• 移植
• 純粋なロードバランサー（機能しないWebサイト）
• Pythonディレクター

以下も参照してください。

• ウィキペディア-コンテンツ配信ネットワーク
• ウィキペディア-カテゴリ：Reverse_proxy
• ウィキペディア-負荷分散
• ウィキペディア-スケーラビリティ

簡単な定義のペアは次のようになります。

フォワードプロキシ：リクエスタ（またはサービスコンシューマ）に代わって動作

リバースプロキシ：サービス/コンテンツプロデューサーに代わって動作します。

下の図は非常に参考になりました。それだけのアーキテクチャを示して前方対逆インターネット経由でクライアントからサーバーへのプロキシ設定を。この画像は、qyb2zm302の回答と他の回答をよりよく理解するのに役立ちます。

Peter SilvaによるF5のDevCentralからこのビデオを視聴することもできます。

画像ソース：Quora。ただし、Martijn Pietersによると、この画像はPulse Secure Communityから、または開発者のJulien Pauliのサイト（フランス語）からのものである可能性があります。

それは私に古典的なことわざを思い出させました：

写真は1000語の価値があります。

フォワードプロキシとリバースプロキシ（2012）は、フォワードプロキシとリバースプロキシの違いを非常に明確に説明しています。

qyb2zm302の回答では、プロキシのアプリケーションについて詳しく説明していますが、フォワードプロキシとリバースプロキシの間の基本的な概念についてはずれています。リバースプロキシの場合、X→Y→Zの場合、XはYではなくZを認識します。逆も同様です。

プロキシは、単に通信の仲介者です（要求と応答）。クライアント<->プロキシ<->サーバー

• クライアントプロキシ：（クライアント< - >プロキシ） < - >サーバー

プロキシはクライアントに代わって機能します。クライアントは、チェーンに含まれる3つのマシンすべてを知っています。サーバーにはありません。

• サーバープロキシ：クライアント<-> （プロキシ<->サーバー）

プロキシはサーバーに代わって機能します。クライアントはプロキシについてのみ知っています。サーバーはチェーン全体を認識しています。

フォワードとリバースは、クライアントとサーバーのプロキシを単に混乱させ、パースペクティブに依存した名前であるように私には思えます。明確なコミュニケーションのために、前者を後者のために放棄することをお勧めします。

もちろん、問題をさらに複雑にするために、すべてのマシンがクライアントまたはサーバーだけであるわけではありません。コンテキストがあいまいな場合は、プロキシの場所と、トンネルする通信を明示的に指定することをお勧めします。

一部の図が役立つ場合があります。

フォワードプロキシ

リバースプロキシ

違いは主に展開にあります。Webフォワードプロキシとリバースプロキシはすべて、同じ基本機能を備えています。さまざまな形式のHTTPリクエストのリクエストを受け入れ、通常はオリジンサーバーまたはコンタクトサーバーにアクセスしてレスポンスを提供します。

フル機能のサーバーには通常、アクセス制御、キャッシュ、およびいくつかのリンクマッピング機能があります。

フォワードプロキシは、クライアントマシンを構成することによってアクセスされるプロキシです。クライアントには、プロキシ機能（リダイレクト、プロキシ認証など）のプロトコルサポートが必要です。プロキシはユーザーエクスペリエンスには透過的ですが、アプリケーションには透過的ではありません。

リバースプロキシは、Webサーバーとして展開され、Webサーバーのように動作するプロキシです。ただし、プログラムやディスクからコンテンツをローカルで作成する代わりに、要求をオリジンサーバーに転送します。クライアントの観点からは Webサーバーであるため、ユーザーエクスペリエンスは完全に透過的です。

実際、単一のプロキシインスタンスは、異なるクライアント集団に対してフォワードプロキシおよびリバースプロキシとして同時に実行できます。

プロキシ：クライアントに代わってリクエストを作成しています。したがって、サーバーはプロキシに応答を返し、プロキシは応答をクライアントに転送します。実際、サーバーはクライアントが誰であるか（クライアントのIPアドレス）を「学習」することはありません。プロキシのみを認識します。ただし、クライアントは本質的にサーバーを宛先とするHTTP要求をフォーマットするため、サーバーは確実にサーバーを認識していますが、プロキシーにそれを渡しています。

リバースプロキシ：サーバーに代わってリクエストを受信して​​います。要求をサーバーに転送し、応答を受信して​​、応答をクライアントに返します。この場合、クライアントは実際のサーバー（サーバーのIPアドレス）をだれも「学習」することはありません（一部例外があります）。プロキシのみを認識します。サーバーは、リバースプロキシの構成に応じて、実際のクライアントを認識するか、認識しません。

最良の説明は図でここにあります：

しばらくフォワードプロキシクライアントに代わってプロキシ（または要求するホスト）、リバースプロキシサーバの代わりにプロキシ。

実際には、フォワードプロキシはクライアントのIDを隠しますが、リバースプロキシはサーバーのIDを隠します。

プロキシサーバーは、インターネット上のさまざまな不要なパブリックリソースへの発信ネットワーク要求をプロキシ（およびオプションでキャッシュ）します。リバースプロキシは、インターネットからの着信要求をキャプチャ（およびオプションでキャッシュ）し、通常は高可用性を目的として、それらをさまざまな内部プライベートリソースに配布します。

Cloudflareには、これを詳細に説明する画像付きの素晴らしい記事があります。

ここをチェック： リバースプロキシとは | プロキシサーバーの説明

プロキシ（転送プロキシ）：

LAN上のコンピューターがインターネットにアクセスするプロキシサーバーに接続する場合。利点には、インターネットに公開されているサーバーのみが含まれます。外の人はコンピュータに直接アクセスできません。フォワードプロキシは、ダウンロードをキャッシュすることにより、ユーザーのインターネットアクセスを改善できます。特定のサイトへのアクセスを制限するためにも使用できます。また、パブリックアドレスが必要なのはプロキシサーバーだけであり、それに接続しているクライアントは必要ありません。

リバースプロキシ：

リバースプロキシは、フォワードプロキシの逆です。代わりに、接続されているサーバーに代わってプロキシとして機能します。ユーザーはリモートサーバーに直接アクセスする代わりに、リバースプロキシを経由して、そこから適切なサーバーにリダイレクトされます。SSL証明書が必要なのはリバースプロキシだけで、パブリックIPアドレスは1つだけ必要です。また、受信リクエストの負荷分散を処理して、全体的なユーザーエクスペリエンスを向上させることができます。

画像ソース：Application Request Routingを使用したフォワードプロキシの作成

Apacheの観点からの私の理解は、プロキシは、サイトxがサイトyのプロキシになる場合、xのリクエストがyを返すことを意味するということです。

リバースプロキシは、yへのすべての参照がxになるようにyからの応答が調整されることを意味します。

ユーザーがプロキシが関係していることを認識できないように...

私の理解に従って...

まず、誰もが知っているように、プロキシは「他の誰かを代表する権限」を意味します。現在、フォワードプロキシとリバースプロキシの2つがあります。

フォワードプロキシ

「Google」にアクセスしたいとし、「Google」がその特定のリクエストに応答するn台のサーバーを持っているとします。

この場合、Googleに何かをリクエストしていて、GoogleにあなたのIPアドレスを見させたくないときは、以下で説明するように、フォワードプロキシを使用します。

A→B→C

これであなたはAで、Bを介してリクエストを送信しています。したがって、CはリクエストがAではなくBから送信されたと見なします。このようにして、クライアントのIPアドレスが外部に公開されないようにすることができます。

リバースプロキシ

ここでは、理解を深めるために、フォワードプロキシの同じケースを取り上げます。ここでは、Googleに何かをリクエストしました。これは、1つのリクエストをアプリサーバーまたは別のプロキシサーバーに送信してレスポンスを取得します。したがって、これらは以下で説明するように発生します。

A→B→C

C→D

C←D

A←B←C

上の図から、リクエストがAからではなくBからCに送信されていることがわかります。その後、Cから1つのリクエストがDに送信されます。同様に、応答はDからCに送信され、次にBとAに送信されます。

上の図は、両方のプロキシが同じように動作しているにもかかわらず重要なのはコンテキストのみであることを示していますが、クライアント側のプロキシはクライアント情報を隠しているのに対し、サーバー側のプロキシはサーバー側の情報を隠しています。

フォワードプロキシはクライアントに匿名性を付与します（Torと考えます）。

リバースプロキシは、バックエンドサーバーに匿名性を付与します（つまり、DMZの背後にあるサーバーと見なします）。

（ロードバランサーとしての）リバースプロキシの例を次に示します。

クライアントがwebsite.comにアクセスし、ヒットしたサーバーでリバースプロキシが実行されています。逆プロキシはたまたまPoundです。Poundは要求を受け取り、その背後にある3つのアプリケーションサーバーの1つに送信します。この例では、Poundはロードバランサーです。つまり、3つのアプリケーションサーバー間で負荷を分散しています。

アプリケーションサーバーは、ウェブサイトのコンテンツをクライアントに提供します。

フォワードプロキシはユーザーにサービスを提供します：ユーザーがサーバーにアクセスするのに役立ちます。

リバースプロキシはサーバーにサービスを提供し、ユーザーからサーバーを保護します。

プロキシがない場合

クライアント側とサーバー側から見ることは同じです：

クライアント->サーバー

代理

クライアント側から：

クライアント->プロキシ->サーバー

サーバー側から：

クライアント->サーバー

リバースプロキシ

クライアント側から：

クライアント->サーバー

サーバー側から：

クライアント->プロキシ->サーバー

クライアントユーザーが設定した場合はプロキシと呼ばれます。サーバーマネージャーが設定した場合はリバースプロキシです。

設定の目的と理由が異なるため、データをさまざまな方法で処理し、さまざまなソフトウェアを使用します。

   User side          |      Server side
client  <->  proxy  <-->  reverse_proxy <-> real server

利用者の視点から見ると：にリクエストを送信するときに、プロキシまたはリバースプロキシサーバー：

• proxy - 2つの引数が必要です
  
  。1）取得するものと2）中間サーバーを使用するプロキシサーバー
  
  

• リバースプロキシ -1 つの引数が必要：
  
  1）取得するもの

リバースプロキシは、ユーザーに認識されていない別のサーバーからコンテンツをフェッチし、リバースプロキシサーバーから発信されたかのように結果を返します。

以前の回答のほとんどは良いですが、私の意見では、この2つを差別化する「逆」の品質に十分に対処することはできません。これを行うには、本質的に同じもの（プロキシ）の「逆」の性質を視覚化する何らかの方法を指定する必要があり、それを十分に抽象化された方法で指定する必要があります。

プロキシ（暗黙のうちに「フォワードプロキシ」）は、いずれかのリモートサーバに複数のローカルのクライアントを接続します。

c--
   |--p--s
c--

リバースプロキシは、いずれかのリモートクライアント（予告どのようにレイアウトが反転）に複数のローカルサーバを接続します。

s--
   |--p--c
s--

プロキシ操作の実用性に関しては非常に重要かもしれませんが、概念を正しく適切に理解するには、（特定の概念にとって）本質的でない詳細を抽象化する必要があります。このような詳細には、両方のシナリオで、複数のクライアントが複数のサーバーに接続するという現実があり、そのクライアントとサーバーは、実際にはローカルまたはリモートではなく、インターネットクラウドが配置されているか、クライアントとサーバー間にどのような種類の可視性が存在するかが含まれます。