web-dev-qa-db-ja.com

ProxyPassReverseディレクティブの使用とは

Apache.orgの定義によると：

このディレクティブを使用すると、Apache httpdはHTTPリダイレクト応答のLocation、Content-Location、およびURIヘッダーのURLを調整できます。これは、Apache httpdがリバースプロキシ（またはゲートウェイ）として使用され、リバースプロキシの背後にあるバックエンドサーバー上のHTTPリダイレクトが原因でリバースプロキシがバイパスされるのを避けるために不可欠です。

上記で具体的に説明したHTTP応答ヘッダーのみが書き換えられます。 Apache httpdは他の応答ヘッダーを書き換えたり、デフォルトでHTMLページ内のURL参照を書き換えたりしません。つまり、プロキシされたコンテンツに絶対URL参照が含まれている場合、プロキシはバイパスされます。プロキシと一致するようにHTMLコンテンツを書き換えるには、mod_proxy_htmlをロードして有効にする必要があります。

pathはローカル仮想パスの名前です。 urlは、リモートサーバーの部分的なURLです。これらのパラメーターは、ProxyPassディレクティブと同じ方法で使用されます。

誰か私にそれがどのように機能するか説明してくれませんか？一般に、このディレクティブは何をしますか？

apache-2.4mod-proxy
8
SnowmanOnFire

実際にリクエストを処理するサーバーがそのサーバー上の別のURLにリダイレクトする場合、ProxyPassReverseディレクティブはリバースプロキシサーバーの観点からURLを書き換えます。たとえば、次の場合、Apache documentation に記載されています。

 http://reverseproxy.com/mirror/foo/bar

に送信されます（逆プロキシ）

 http://backend.example.com/bar

処理用ですが、バックエンドサーバーでは、正しいURLがquuxである必要があると判断されます。つまり、リクエストは

 http://backend.example.com/quux

ProxyPassReverseディレクティブは、URLを（リバースプロキシで）に書き換えます。

 http://reverseproxy.com/mirror/foo/quux

hTTPリダイレクト応答をクライアントに転送する前。このようにして、クライアントはリバースプロキシサーバーについてのみ認識しますが、それでもhttp://reverseproxy.com/mirror/foo/quuxの正しいURLに必要な要求を行うことができます。このURLは、バックエンドサーバーに逆プロキシされ、通常どおり処理されます。つまり、リバースプロキシがHTTPリダイレクト応答で正しいURIヘッダーを返すことを許可するだけです。

8
Colt

Apache 2.4リバースプロキシガイド から：

バックエンドから生成されたLocation：ヘッダーが、それ自体に戻るのではなく、リバースプロキシを指すように変更されるようにするには、ProxyPassReverseディレクティブが最も必要になります。

ProxyPass "/" " http://www.example.com/ "

ProxyPassReverse "/" " http://www.example.com/ "

クライアントと2つのサーバー（プロキシとオリジン）があり、オリジンが実際の作業（応答の生成）を行い、プロキシがオリジンへのリクエストをプロキシするだけの場合、適切なサーバーアーキテクチャは次の場合です。

  1. Originはプロキシについて知りません
  2. andすべてのリクエストはプロキシを経由します。

Originがプロキシについて知らない場合可能性がありますOriginがクライアントにプロキシ経由のHTTPリダイレクト（HTTP 301または302）を返し、それがを直接指しますそれ自体、Origin。また、ブラウザが次のラウンドで直接Originに接続するため、これは問題です。これは、ポイント2に違反します。

HTTPリダイレクト応答がクライアントに向けてプロキシに戻ると、プロキシはそれらのリダイレクトを変更できるため、ロケーションが引き続きプロキシを指すようにする必要があります。このように、プロキシが適切に構成されている限り、プロキシを認識しないOriginで実行されているスタンドアロンアプリケーションは、リダイレクトURLを生成できます。

0
karatedog