From: Takashi Sato Date: Mon, 9 Jan 2012 08:11:13 +0000 (+0000) Subject: Update Japanese translation. X-Git-Tag: 2.2.22~34 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=db3af389e0dc66292f64949c8efb8e5834f0a251;p=thirdparty%2Fapache%2Fhttpd.git Update Japanese translation. English Revesion: r1212598 Submitted by: INOUE Seiichiro Reviewed by: KIKUCHI Tokio git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@1229053 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_proxy.xml.ja b/docs/manual/mod/mod_proxy.xml.ja index bfdc2feb4d0..cbf8e205754 100644 --- a/docs/manual/mod/mod_proxy.xml.ja +++ b/docs/manual/mod/mod_proxy.xml.ja @@ -1,7 +1,7 @@ - + +
ワーカー +

プロキシは ワーカー と呼ばれるオブジェクトで + オリジンサーバとの通信パラメータの設定を管理します。 + ふたつの組み込みワーカーが存在します。デフォルトのフォワードプロキシワーカーと + デフォルトのリバースプロキシワーカーです。 + 追加のワーカーを明示的に設定可能です。

+ +

ふたつのデフォルトワーカーは固定の設定を持ちます。 + リクエストが他のワーカーにマッチしない場合に使われます。 + これらは HTTP のキープアライブもコネクションプーリングも使いません。 + オリジンサーバへの TCP 接続はリクエストのたびに接続と切断をします。

+ +

明示的に設定するワーカーは、URL で識別されます。 + 通常、ProxyPass + または ProxyPassMatch + をリバースプロキシ設定に使うことで、これらのワーカーを生成および設定します:

+ + + ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30 + + +

上記はオリジンサーバの http://backend.example.com + の URL に関連するワーカーを生成します。ワーカーは指定したタイムアウト値を持ちます。 + フォワードプロキシで使われる時、ワーカーは一般に + ProxySet ディレクティブで + 定義します:

+ + + ProxySet http://backend.example.com connectiontimeout=5 timeout=30 + + +

または、別の方法として Proxy + と ProxySetでも定義できます:

+ + + <Proxy http://backend.example.com>
+ + ProxySet connectiontimeout=5 timeout=30 + + </Proxy> + + +

フォワードモードで明示的に設定したワーカーを使うのは、あまり一般的ではありません。 + なぜなら、通常フォワードプロキシは多くの異なるオリジンサーバと通信するからです。 + もし一部のオリジンサーバを頻繁に利用するなら、それらに対して + 明示的にワーカーを生成するのは有用です。明示的に設定したワーカーは、 + それ自体はフォワードプロキシかリバースプロキシかのコンセプトを持ちません。 + それらはオリジンサーバと通信する共通のコンセプトを抱えています。 + リバースプロキシで使うために ProxyPass + で生成したワーカーは、オリジンサーバへの URL がワーカーの URL にマッチすれば + いつでもフォワードプロキシとして使えます。これは、逆も成り立ちます。

+ +

ワーカーを識別する URL はそのオリジンサーバの URL です。 + URL は指定したパス部分も含みます:

+ + + ProxyPass /examples http://backend.example.com/examples
+ ProxyPass /docs http://backend.example.com/docs + + +

この例はふたつの異なるワーカーを定義しています。 + それぞれ別のコネクションプールと設定を使います。

+ + ワーカーの共有 +

もしワーカーの URL に重なりがあれば、ワーカーの共有が起きます。 + 重なりとは、ワーカーの URL が、設定ファイル内で後から定義した + 別のワーカーの URL の先頭文字列と部分一致することです。 + 次の例で

+ + + ProxyPass /apps http://backend.example.com/ timeout=60
+ ProxyPass /examples http://backend.example.com/examples timeout=10 + + +

ふたつめのワーカーは実際には生成されません。 + その代わり、ひとつめのワーカーを使います。この利点は、ただひとつの + コネクションプールで済む点です。このため、コネクションをより頻繁に再利用できます。 + 後ろのワーカーに明示的に書いた設定のすべてのパラメータと一部の設定のデフォルト値は、 + 最初のワーカーに書いた設定を上書きするのを注意してください。 + これは警告としてログに残ります。上記の例で言えば、/apps + の URL に対するタイムアウト値は、結果として 60 ではなく + 10になるのです。

+ +

もしワーカーの共有を避けたければ、ワーカーの定義を URL の長さでソートしてください。 + そして、長い URL から並べてください。もしワーカーの共有を最大限にしたいなら、 + 逆順に並べます。ProxyPass + ディレクティブの並びについて、関連する警告も見てください。

+ + + +

明示的に設定するワーカーにはふたつの種類があります: + 直接のワーカー と バランサー (負荷分散) ワーカー です。 + これらは後ほど ProxyPass + ディレクティブの中で説明する重要な設定パラメータを数多くサポートします。 + 同じパラメータは ProxySet + を使っても設定可能です。

+ +

直接のワーカーで利用できるパラメータはプロトコルに依存します。 + プロトコルはオリジンサーバの URL で指定されます。 + 利用可能なプロトコルは ajp, + ftp, http, scgi です。

+ +

バランサーワーカーは仮想ワーカーです。直接のワーカーを + リクエストを実際に処理するメンバーとして使います。 + それぞれのバランサーは複数のメンバーを持ちえます。 + リクエストを処理する時、設定した負荷分散のアルゴリズムにもとづき + メンバーのひとつを選択します。

+ +

ワーカーの URL のプロトコルスキームに balancer + を使うと、バランサワーカーが生成されます。 + バランサーの URL が、バランサワーカーを一意に識別します。 + BalancerMember + を使って、バランサーにメンバーを追加します。

+ +
+
プロキシへのアクセス制御 -

プロキシのアクセスは以下のように プロキシへのアクセスは以下のように Proxy コンテナの中に ディレクティブを書くことで制御できます:

@@ -178,7 +287,7 @@ module="mod_proxy">ProxyRequests ディレクティブを 使って) フォワードプロキシを設定している場合は、厳しくアクセス 制限を行なうことが非常に大切です。そうしないと、任意のクライアントが - 身元を明かすことなく任意のホストにアクセスするためにサーバを使うことが + 身元を明かすことなく任意のホストにアクセスするためにプロキシサーバを使うことが できてしまいます。これはあなた自身のネットワークにとっても、インターネット 全体にとっても危険なことです。(ProxyRequests Off にして 遅い起動

ProxyBlock ディレクティブを使っている場合、 - 後のテストのために起動時にホストの - IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの + 後に行うマッチ判定のため、起動時にホストの名前解決をして + IP アドレスをキャッシュします。ホスト名の名前解決の 速さによっては、数秒 (かそれ以上) かかるかもしれません。

@@ -210,7 +319,7 @@ 役に立ちます。

イントラネット内のユーザは WWW のリクエストでローカルドメインを - 省略することがよくあります。http://somehost.example.com/ + 省略することがよくあります。http://somehost.example.com/ というリクエストの代わりに "http://somehost/" をリクエストしたりします。 このようなリクエストを受け付け、サーバに設定されているローカルドメインが 暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも @@ -219,17 +328,17 @@ href="#proxyrequests">プロキシのサービス用に設定されていて ProxyDomain ディレクティブが 使用された場合には、Apache はクライアントにリダイレクト応答を送って、 - 正しい、完全な (fully qualified) + 正しい、完全な fully qualified サーバのアドレスに送ることができます。このように リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む ことにもなるため、より好ましい方法と言えるでしょう。

プロトコルの調整 -

Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバに対して +

Keepalive や HTTP/1.1 を適切に実装していないオリジンサーバに対して mod_proxy がリクエストを送信する場合、 - HTTP/1.0 を使って keepalive を無しにしてリクエストを送るようにする - 環境変数が二つあります。これらは 環境変数が二つあります。これらは SetEnv ディレクティブで設定します。

force-proxy-request-1.0 と proxy-nokeepalive @@ -250,23 +359,54 @@

リクエストボディ

POST メソッドなどのリクエストには、リクエストボディがあります。 - HTTP プロトコル仕様によると、ボディのあるリクエストは chunked + HTTP プロトコル仕様によると、ボディのあるリクエストは chunked 転送を使うか、Content-Length ヘッダを送信しなければなりません。 このようなリクエストをオリジンサーバに送信する場合、 mod_proxy_http は常に Content-Length - を送ろうと試みます。しかし。ボディが大きく、オリジナルのリクエストで + を送ろうと試みます。しかし、ボディが大きく、オリジナルのリクエストで chunked 転送が使われている場合、上流へのリクエストに chunked 転送も使われます。 この挙動は 環境変数で制御できます。 - proxy-sendcl を設定すると、可能な限り常に - Content-Length を付与して、 - 上流サーバに送信するようになります。 - 逆に proxy-sendchunked を設定すると、リソース消費を抑え、 - chnked エンコードを使って送信するようになります。

+ proxy-sendcl を設定すると、 + 常に Content-Length を送り、最大限の互換性を確保します。 + 逆に proxy-sendchunked を設定すると、 + chunked エンコードを使ってリソース消費を抑えます。

+
リバースプロキシのリクエストヘッダ + +

リバースプロキシとして振る舞う時 (例えば、ProxyPass ディレクティブを使う時) 、 + mod_proxy_http は、オリジンサーバに情報を渡すために + いくつかのリクエストヘッダを追加します。これらのヘッダは以下になります。

+ +
+
X-Forwarded-For
+
クライアントの IP アドレス。
+
X-Forwarded-Host
+
オリジナルのホスト名。クライアントが Host + リクエストヘッダで渡す。
+
X-Forwarded-Server
+
プロキシサーバのホスト名。
+
+ +

オリジンサーバ上でこれらのヘッダを扱う時は注意してください。 + と言うのも、オリジナルのリクエストが既に同じヘッダを持っていると、 + ヘッダが一つ以上の値 (コンマで区切られます) を持つ可能性があるからです。 + 例えば、 オリジンサーバ上でオリジナルのクライアントのIPアドレスをログに + 記録するため、ログフォーマットに %{X-Forwarded-For}i を + 指定したとします。この時、リクエストが複数のプロキシを経由していると、 + 複数のアドレスがログに載る可能性があります。

+ +

ProxyPreserveHost と + ProxyVia ディレクティブ + も参照してください。これらは他のリクエストヘッダに影響を与えます。

+ +
+ + Proxy プロキシされるリソースに適用されるコンテナ @@ -304,8 +444,8 @@ </Proxy> - +ProxyMatch @@ -315,11 +455,11 @@ ProxyBadHeader IsError server configvirtual host -2.0.44 以降 +Apache 2.0.44 以降で使用可能

ProxyBadHeader ディレクティブは構文的に - 間違ったヘッダ (つまり コロンを含まないもの) を受け取ったときに + 間違ったレスポンスヘッダ (つまり コロンを含まないもの) を受け取ったときに mod_proxy がどう振る舞うかを決めます。以下の引数を 取ることができます:

@@ -340,6 +480,22 @@ + +ProxyFtpDirCharset +プロキシされた FTP (の一覧表示) のキャラクタセットを定義 +ProxyFtpDirCharset character set +ProxyFtpDirCharset ISO-8859-1 +server configvirtual host +directory +Apache 2.2.7 以降で使用可能 + + +

ProxyFtpDirCharset ディレクティブは、 + mod_proxy_ftp が HTML 形式で生成する FTP のディレクトリ一覧 + 画面のキャラクタセットを定義します。

+ + + ProxyMatch 正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ @@ -349,9 +505,10 @@

ProxyMatch は URL のマッチに - 正規表現 を用いることを除いて + 正規表現 を用いることを除けば Proxy ディレクティブと同じです。

 +Proxy @@ -386,10 +543,10 @@

これは Apache のフォワードプロキシサーバとしての動作を 有効もしくは無効にします。(ProxyRequests を Off に - 設定しても、ProxyPass + 設定しても、ProxyPass の設定は無効になりません。)

-

通常のリバースプロキシの設定では、このオプションは Off +

通常のリバースプロキシ/ゲートウェイの設定では、このオプションは Off に設定してください。

HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、 @@ -404,6 +561,7 @@ インターネット全体にとっても危険です。

 +フォワードプロキシとリバースプロキシ/ゲートウェイ @@ -415,10 +573,10 @@

このディレクティブはこのプロキシに対するリモートプロキシを定義します。 - match はリモートサーバがサポートする URL スキーム、 - リモートサーバが使うはずの URL の一部分、サーバがすべての - リクエストに使われることを示す * のどれかになります。 - remote-server はリモートサーバの部分 URL です。構文:

+ match はリモートプロキシがサポートする URL スキーム、 + あるいはリモートプロキシを使うべき URL の一部分、あるいはすべての + リクエストにリモートプロキシが使われることを示す * のどれかになります。 + remote-server はリモートプロキシの部分 URL です。構文:

remote-server = @@ -426,20 +584,22 @@

scheme は実際上リモートサーバとの通信に使われるプロトコルを - 決定します。このモジュールでは http だけがサポートされて - います。

+ 決定します。このモジュールでは http と https + だけがサポートされています。 + https が使われると、HTTP CONNECT メソッドを使って + リクエストはリモートプロキシに転送されます。

例 - ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
- ProxyRemote * http://cleversite.com
- ProxyRemote ftp http://ftpproxy.mydomain.com:8080 + ProxyRemote http://goodguys.example.com/ http://mirrorguys.example.com:8000
+ ProxyRemote * http://cleverproxy.localdomain
+ ProxyRemote ftp http://ftpproxy.mydomain:8080 -

この例では、プロキシは FTP リクエストを別の HTTP リクエストで包んで +

最後の例では、プロキシは FTP リクエストを別の HTTP リクエストで包んで そのようなリクエストを扱える別のプロキシに転送します。

このオプションはリバースプロキシの設定もサポートします。 - サーバが別のフォワードプロキシの後ろに隠されている場合でも + バックエンドウェブサーバが別のフォワードプロキシの後ろに隠されている場合でも バックエンドウェブサーバをバーチャルホストの URL 空間に入れることが できます。

 @@ -459,10 +619,83 @@ + +BalancerMember +ロードバランサのグループにメンバーを追加 +BalancerMember [balancerurl] url [key=value [key=value ...]] +directory + +BalancerMember は Apache 2.2 以降でのみ使用可能 + +

このディレクティブでロードバランサのグループにメンバを追加します。 + <Proxy balancer://...> ディレクティブのコンテナ + 内で使われることが多く、ProxyPass + ディレクティブと共通のキーバリューペアのパラメータを取ります。

+

<Proxy balancer://...> ディレクティブの + コンテナ内に書かない場合のみ、 balancerurl 引数が必要です。 これは + ProxyPass ディレクティブで + バランサを定義した時の URL と同じ働きをします。

+ + + + +ProxySet +プロキシのバランサやメンバのパラメータをセット +ProxySet url key=value [key=value ...] +directory + +ProxySet は Apache 2.2 以降でのみ使用可能 + +

このディレクティブは、通常は ProxyPass + ディレクティブで行うプロキシのバランサやワーカーに対するパラメータを + 別の方法で設定できるようにします。 + <Proxy balancer url|worker url> + ディレクティブのコンテナ内で使う場合、url 引数は必要ありません。 + 副次的に、それぞれのバランサやワーカーが生成されます。 + ProxyPass ディレクティブではなく、 + RewriteRule でリバースプロキシ + 設定をする時にこのディレクティブは有用です。

+ + + <Proxy balancer://hotcluster>
+ + BalancerMember http://www2.example.com:8009 loadfactor=1
+ BalancerMember http://www3.example.com:8009 loadfactor=2
+ ProxySet lbmethod=bytraffic
+ + </Proxy> + + + + <Proxy http://backend>
+ + ProxySet keepalive=On
+ + </Proxy> + + + + ProxySet balancer://foo lbmethod=bytraffic timeout=15 + + + + ProxySet ajp://backend:7001 timeout=15 + + + 警告 +

設定対象がバランサかワーカーかで、パラメータ名が同じでも意味が異なる可能性 + に注意してください。例えば、タイムアウトに関連する上記ふたつの例がそうです。

+ + + + + ProxyPass リモートサーバをローカルサーバの URL 空間にマップする -ProxyPass [path] !|url [key=value key=value ...]] +ProxyPass [path] !|url [key=value +key=value ...]] [nocanon] [interpolate] server configvirtual host directory @@ -471,6 +704,8 @@

このディレクティブはリモートサーバをローカルサーバの名前空間に マップできるようにします。ローカルサーバは通常の意味でのプロキシと しては動作せず、リモートサーバのミラーとして振る舞います。 + ローカルサーバはしばしば リバースプロキシ や ゲートウェイ + と呼ばれます。 path はローカルの仮想パスの名前です。url は リモートサーバの部分 URL になり、クエリー文字列を含むことはできません。

@@ -490,6 +725,15 @@ リクエストが内部的に http://backend.example.com/bar への プロキシリクエストに変換されることになります。

+ +

もし第一引数が / で終端するならば、第二引数も + / で終端すべきです。逆もまた然りで、第一引数が終端しないならば、 + 第二引数も終端すべきではありません。 + これに反すると、バックエンドサーバ向けに変換されたリクエストは + 必要なスラッシュを欠く可能性があり、バックエンドサーバは期待する結果を返しません。 +

+ +

サブディレクトリをリバースプロキシしたくないときに ! は 役に立ちます。例えば、

@@ -498,32 +742,48 @@ ProxyPass /mirror/foo http://backend.example.com -

は /mirror/foo/i を除く +

は /mirror/foo/i を 除く /mirror/foo へのすべてのリクエストを backend.example.com にプロキシします。

- 注 -

順番は重要です。一般的な ProxyPass - ディレクティブの前に - 除外ディレクティブを置く必要があります。

- - -

2.1 の機能で、バックエンドサーバとの接続にプールされたコネクションを - 使えるようになりました。key=value 形式のパラメータで - このコネクションプーリングの調整ができます。Hard Maximum - のデフォルト値は、有効になっている MPM でのプロセス当たりのスレッド数と - 同じ数のコネクション数です。prefork MPM では通常は 1 で、worker MPM では - ThreadsPerChild で調整されます。

+ ProxyPass ディレクティブの順序 +

ProxyPass と + ProxyPassMatch のルールの + 設定は設定ファイル中の順序どおりにチェックされます。 + 最初にマッチしたルールが勝ちます。このため通常は、 + マッチが重なる ProxyPass + ルールは、長い URL が先になるように並べるべきです。 + そうしないと、後に書かれた長い URL にマッチするルールが、 + 先に書かれた短い URL の先頭の部分にマッチしたルールで隠される可能性があります。 + ワーカーの共有とも多少の関係があることにも注意してください。

+ +

同じ理由で、否定処理も一般的な ProxyPass + ディレクティブの 前に 書くべきです。

+ + + +

Apache HTTP サーバ 2.1 以降、バックエンドサーバとの接続に + プールされたコネクションを使えるようになりました。 + 要求に応じて生成されたコネクションは将来の使用のためにプール内に維持されます。 + プールサイズとその他の設定の制限は ProxyPass + ディレクティブに key=value パラメータで設定します。 + パラメータは後述する表に示します。

+ +

デフォルトで、mod_proxy は Web サーバの子プロセスが同時に使いうる + 最大数のコネクションを許し維持するようにします。 + この数をデフォルトから減らすには max パラメータを使ってください。 + 生存期間を設定するには ttl パラメータを使ってください。 + ttl 秒を越えて使われていないコネクションは切断されます。 + バックエンドサーバのキープアライブがタイムアウトして、切断されようとしている + コネクションが使われることを防ぐために ttl を使えます。

+ +

コネクションプールは Web サーバの子プロセスごとに維持されます。 + max やその他の設定は、すべての子プロセスの間で調整はされません。 + ただし、設定により、ただひとつの子プロセスに設定を委ねた場合や + MPM 設計によってはこの限りではありません。

-

min の設定で、バックエンドサーバとの間に何本のコネクションを - 常時開くかが決まります。Soft Maximum smax の数に - 達するまで必要に応じてコネクションは生成されます。smax - を超えた数のコネクションは、生存時間 ttl で切断されます。 - バックエンドサーバと Hard Maximum max の数以上のコネクションを - 生成することはありません。

- - - ProxyPass /example http://backend.example.com smax=5 max=20 ttl=120 retry=300 + 例 + ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300 @@ -532,52 +792,105 @@ - + - + Prefork MPM では常に 1 で、他の MPM では ThreadsPerChild + ディレクティブで調節できます。 - - - - - - - + + + + + + + + + + + + + - + + + + + + + + + + + + @@ -586,50 +899,63 @@ タイムアウトの期間が過ぎるまで、そのサーバにリクエストをフォワードしません。 この機能を使うと、バックエンドサーバをメンテナンスのためにシャットダウンし、 後でオンラインに復帰させるといったことができます。 - - - - - - + - + + + + + +
説明
min 0バックエンドサーバとの接続で - 常に開いているコネクション数の最小値
コネクションプール内で実際の接続に関連していないエントリの最小数です。 + デフォルト値から変更する必要があるのは、バックエンドとの接続に必要な + ヒープメモリを事前に割り当てるか維持しなければいけない特別な状況のみです。
max 1...nバックエンドサーバとの接続数の Hard Maximum - ハードリミット。 + バックエンドサーバとの接続数の最大値です。 デフォルト値は、使用している MPM のプロセスあたりのスレッド数になっています。 - Prefork MPM では常に 1 で、Worker MPM では ThreadsPerChild - で調節できます。Hard Maximum 以上にバックエンドサーバとのコネクションを - 生成することはありません。
smax max接続数の Soft Maximum ソフトリミットまで、 - コネクションは必要に応じて生成されます。 - smax を超えた数のコネクションは生存時間 ttl - で切断されます。 -
ttl-smax 数を超えた非活動状態のコネクションの生存時間を、 - 秒で指定します。この期間内に使用されなかったコネクションは、 - 全て閉じられます。 -
timeoutTimeoutコネクションタイムアウトを秒で指定します。特に指定されなければ、 - フリーなコネクションを取得できるまで待ちます。このディレクティブは - max パラメータと合わせて使うことで、バックエンドサーバとの - 接続数を制御するのに使います。 -
もしコネクションプール内の接続中エントリが ttl パラメータ + で設定した生存期間より長く未使用のままであれば、 + この指定値を越える分のエントリを解放します。 + もしエントリが関連するコネクションを持てば、接続を閉じます。 + デフォルト値から変更する必要があるとすれば、 + コネクションが生存期間を越えてしまった時に、 + コネクションプール内の該当エントリの解放とコネクションの切断を + より積極的に必要とする特別な場合のみです。
acquire - 設定すると、コネクションプールからフリーのコネクションを取得するために - 待機する待ち時間の最大値になります。フリーのコネクションがプールになかった場合は、 - SERVER_BUSY ステータスがクライアントに返されます。 + 待機する待ち時間 (ミリ秒単位) の最大値になります。フリーのコネクションがプールになかった場合は、 + SERVER_BUSY ステータスをクライアントに返します。 +
connectiontimeouttimeout接続タイムアウトを秒で指定します。 + バックエンドに接続を完了するまでの Apache の待ち時間です。 + 値の最後に ms を書くと、タイムアウトの単位をミリ秒にできます。 +
disablereuseOff使用後すぐに mod_proxy がバックエンドとの接続を切断してほしい時は、 + このパラメータを有効にすべきです。そうすることで、バックエンドとの + 永続的な接続とプーリングを無効にできます。 + これはいくつかの状況下で役に立ちます。例えば、Apache とバックエンドサーバ + の間にファイアウォールが存在し (プロトコルは問わないとします)、黙って + 接続を切られる場合や、あるいは、バックエンドサーバ自体が DNS で + ラウンドロビンされている場合などです。コネクションプーリングによる再利用を + 無効にするには、このパラメータ値を On にしてください。 +
flushpacketsoffプロキシモジュールが "chunk" ごとに出力データを自動的に強制送信(フラッシュ) + するかを指定します。 'off' は必要な時だけ強制送信します。 + 'on' はそれぞれの "chunk" データごとに強制送信します。 'auto' は、一定時間待機し、 + 'flushwait' で指定したミリ秒の間、入力データが無ければ強制送信します。 + 現在、このパラメータは AJP でのみ意味があります。 +
flushwait10'flushpackets' パラメータの値が 'auto' の場合、出力データを強制送信する前に、 + 次の入力をどのぐらい待つかをミリ秒単位で指定します。
keepalive Offバックエンドサーバと Apache の間にファイアーウォールがある場合には、 +

バックエンドサーバと Apache の間にファイアーウォールがある場合には、 このパラメータを使ってください。ファイアウォールは往々にして、 非活動状態のコネクションを落とそうとします。 このフラグは OS に指示して、KEEP_ALIVE メッセージを非活動状態の - コネクションでも送るようにします (間隔は OS のグローバル設定に依存し、 - 通常は 120ms 間隔) 。これによってファイアウォールによってコネクションが + コネクションでも送るようにします。これによってファイアウォールによってコネクションが 落とされることを防げます。keepalive を有効にするには、このプロパティを - On にしてください。 + On にしてください。

+

初期およびその後の TCP キープアライブの間隔は OS のグローバル設定に依存しますが、 + 2 時間以上にしたほうがよいでしょう。有効性を考えると、 + OS で設定した間隔はファイアウォールで使われる閾値より小さくあるべきです。

+
lbset0ワーカーが属するロードバランサのクラスタセットを設定します。 + ロードバランサは、より小さい lbset 値を持つメンバーから使おうとします。 +
ping0この設定により、Web サーバは ajp13 通信でリクエストを送信する前に + CPING を送るようになります。 + パラメータ値は、CPONG リプライを待つ時間を秒単位で指定します。 + この機能は、ハングしたり高負荷状態の Tomcat に起因する問題を回避するために + 追加されました。 また、ajp13 側に ping/pong 機能のサポートが必要です。 + Tomcat は 3.3.2 以降, 4.1.28 以降, 5.0.13 以降が ping/pong 機能を実装しています。 + この機能は、通常利用でのネットワークトラフィックを増やす可能性があり、 + 問題になるかもしれません。しかし、クラスタを形成するノードの一部が + ダウンしたり高負荷になった時にはトラフィックを抑制できる可能性があります。 + 現在、この設定は AJP でのみ意味があります。 + 値の最後に ms を書くと、単位をミリ秒にできます。 +
loadfactor1ワーカーあたりの負荷係数です。BalancerMember で使います。 + 1 から 100 までの数字でそのワーカーに対する正規化された負荷率を指定します。 +
redirect-ワーカーのリダイレクション経路です。この値は通常は、 + クラスタから安全にノードを取り除けるように動的にセットされます。 + もし設定すると、セッション ID 無しの全てのリクエストは、 + この値と同じルーティングパラメータを持つ + BalancerMember にリダイレクトされます。
retry 60
loadfactor1ワーカーあたりの負荷係数です。BalancerMember で使います。 - 1 から 100 までの数字でそのワーカーに対する正規化された負荷率を指定します。 + 0 を指定すると、失敗したワーカーへ、タイムアウト無しで常にリトライします。
route -ロードバランサで使った場合、ワーカーのルーティングをします。 - ルートはセッション ID に付加された値になります。 + ロードバランサで使われた場合のワーカーのルート値。 + ルート値はセッション ID に付加される値です。
redirect
status -ワーカーのリダイレクション経路です。この値は通常は、 - 安全にクラスタからノードを取り去る設定を動的に入れるために使います。 - セッション ID の無いリクエスト全てを指定した場合は、 - この値と同じルーティングパラメータを持つ - BalancerMember にリダイレクトされます。 + 一文字でワーカーの初期状態を定義します: 'D' は無効 (disabled)、 + 'S' は停止 (stopped)、 'I' はエラー無視 (ignore-errors)、 + 'H' はホットスタンバイ (hot-standby)、 'E' はエラー状態 (error) です。 + '+' を文字の前に書いて有効にするか (これがデフォルト動作です)、 あるいは + '-' を書いて無効にできます。つまり、 'S-E' の指定は、ワーカーを停止状態 + かつ、エラー状態フラグのクリアを意味します。 +
timeoutProxyTimeoutコネクションタイムアウトを秒で指定します。 + バックエンドからのデータ受信およびバックエンドへのデータ送信の + Apache の待ち時間です。 +
ttl-非活動状態のコネクションと、関連するコネクションプール内のエントリの + 生存時間を秒で指定します。いったんこの制限に達すると、 + コネクションはふたたび使われることはありません。 + つまり、コネクションは一定時間後に閉じられます。
-

Proxy ディレクティブのスキームが balancer:// になっている場合は、 - バックエンドサーバと実際には通信しない仮想ワーカーが生成されます。 - このワーカーは幾つかの "本物の" ワーカーの管理をつかさどります。 - この場合パラメータは、この仮想ワーカーに対して設定されます。 +

もし ProxyPass ディレクティブのスキームが + balancer:// で始まる場合 (例えば balancer://cluster/、 + パス情報は無視されます)、バックエンドのサーバと実際には通信しない + 仮想ワーカーが生成されます。通信しない代わりに、このワーカーは幾つかの + "本物の" ワーカーの管理をつかさどります。 + この場合、いくつかの特殊パラメータを、この仮想ワーカーに対して設定できます。 + ロードバランス動作のより詳しい情報は、mod_proxy_balancer + を参照してください。

- + - - - + + @@ -638,47 +964,173 @@ バックエンドサーバがセッションレプリケーションをサポートしていない場合は、 On にしてください。 + + + + + + - - - + + - +
パラメータ デフォルト値 説明
lbmethod-byrequests Balancer のロードバランス方法。使用するロードバランスの スケジューリング方法を選びます。処理したリクエストの数で重み付けする byrequests か、転送量のバイト数で重み付けする - bytraffic を設定できます。デフォルトは - byrequests です。 + bytraffic か、待機中のリクエスト数で振り分ける + bybusyness を設定できます (Apache HTTP サーバ 2.2.10 以降)。 + デフォルトはbyrequests です。
stickysession-バランサーのスティッキーセッション名です。通常はこの値は JSESSIONID - や PHPSESSIONID といったものになりますが、この値は - バックエンドアプリケーションのサポートするセッションに依存します。 +
maxattemptsワーカーの数よりひとつ少ない数。あるいはワーカーがひとつであれば1フェイルオーバーを試みる最大の回数を指定します。
nofailover Off
stickysession-バランサーのスティッキーセッション名です。通常はこの値は JSESSIONID + や PHPSESSIONID といったものになりますが、この値は + セッションをサポートするバックエンドのアプリケーションサーバに依存します。 + バックエンドのアプリケーションサーバが、クッキーやURLエンコードID + に異なるセッション名を使う場合(サーブレットコンテナのように)、 + | 文字でふたつの名前を区切ってください。 + 最初の名前がクッキー用で、二番目がURLパス用です。 +
scolonpathdelimOffOn にセットすると、セミコロン文字 ';' をスティッキーセッション + の別の区切り文字として使えるようになります。 + これは主に mod_jk の動作に合わせるために使います。例えば、 + JSESSIONID=6736bcf34;foo=aabfa のような指定です。 +
timeout 0 バランサーのタイムアウトを秒で指定します。 この値を設定すると、フリーのワーカーを取得するまでの最大待機時間になります。 デフォルトでは待機しません。
maxattempts1フェイルオーバーを試みる最大の回数を指定します。 +
failonstatus-ひとつ、あるいはコンマ区切りの複数の HTTP ステータスコードです。 + この値を設定すると、列挙したステータスコードのどれかをバックエンドが返した時、 + そのワーカーをエラー状態にします。ワーカーのエラーからの回復は + 他のワーカーエラーと同じように動作します。 + Apache HTTP サーバ 2.2.17 以降で使用可能です。
+

バランサーの設定例

- ProxyPass /special-area http://special.example.com/ smax=5 max=10
- ProxyPass / balancer://mycluster stickysession=jsessionid nofailover=On
+ ProxyPass /special-area http://special.example.com smax=5 max=10
+ ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
<Proxy balancer://mycluster>
- BalancerMember http://1.2.3.4:8009
- BalancerMember http://1.2.3.5:8009 smax=10
- # Less powerful server, don't send as many requests there
- BalancerMember http://1.2.3.6:8009 smax=1 loadfactor=20
+ BalancerMember ajp://1.2.3.4:8009
+ BalancerMember ajp://1.2.3.5:8009 loadfactor=20
+ # Less powerful server, don't send as many requests there,
+ BalancerMember ajp://1.2.3.6:8009 loadfactor=5
 </Proxy> +

ホットスタンバイの設定例です。他のメンバーが利用できない場合のみ + 使われます。

+ + ProxyPass / balancer://hotcluster/
+ <Proxy balancer://hotcluster>
+ + BalancerMember ajp://1.2.3.4:8009 loadfactor=1
+ BalancerMember ajp://1.2.3.5:8009 loadfactor=2
+ # The below is the hot standby
+ BalancerMember ajp://1.2.3.6:8009 status=+H
+ ProxySet lbmethod=bytraffic + + </Proxy> + + +

通常、mod_proxy は ProxyPass した URL を正規化します。 + しかし、これによりバックエンドの互換性に問題が生じることがあります。 + 特に、PATH_INFO を使っている場合に起きがちです。 + nocanon オプションは正規化を抑制し、URL のパスをそのまま ("raw") + バックエンドに伝えます。これがバックエンドのセキュリティに影響を与える可能性に + 注意してください。と言うのも、プロキシによって提供されていた、 + URL ベースの攻撃への通常の一定の防御を無くすことになるからです。

+ +

オプショナルな interpolate キーワード (httpd 2.2.9 以降で利用可能) + を ProxyPassInterpolateEnv ディレクティブと + 一緒に使うと、${VARNAME} 形式で、 ProxyPass 設定に環境変数を + 使えるようになります。この時、標準的な CGI 由来の環境変数の多くは + 置換に使えないことに注意してください。そのため、複雑なルールの記述のためには、 + mod_rewrite に頼ることになるでしょう。

+

Location セクションの中で使われた場合、最初の引数は 省略され、ローカルディレクトリは Location から取得されます。

+ >Location から取得されます。 + 同じことは LocationMatch + セクション内でも起きます。しかし、ProxyPass は正規表現を解釈しないので、 + この状況では代わりに ProxyPassMatch を使う必要があります。

+ +

このディレクティブは Directory や Files セクション内では使えません。

+ +

より柔軟なリバースプロキシの設定が必要な場合は、[P] + フラグ付きの RewriteRule + ディレクティブを参照してください。

+ + + + + +ProxyPassMatch +正規表現を使ってリモートサーバをローカルサーバの URL 空間にマップする +ProxyPassMatch [regex] !|url [key=value + [key=value ...]] +server configvirtual host +directory + +Apache 2.2.5 以降で使用可能 + + +

単純な文字列前方一致ではなく正規表現を用いることを除いて、このディレクティブは + ProxyPass と同じです。 + 指定した正規表現で url に対してマッチを試みます。 + マッチすると、サーバはマッチした丸括弧部分を前方参照の置換に使い、新しい url + にします。

+ +

ローカルサーバのアドレスが http://example.com/ だとします; + すると

+ + + ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com$1 + + +

は、ローカルの http://example.com/foo/bar.gif へのリクエストを + 内部的に http://backend.example.com/foo/bar.gif へのプロキシリクエスト + に変換します。

+ 注意 +

URL 引数は正規表現による置換の 前 でも (当然、置換後でも)、 + URL として解釈できなければいけません。これは使えるマッチに制約をもたらします。 + 例えば、上記の例で

+ + ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com:8000$1 + +

と書いたとします。これはサーバ起動時にシンタックスエラーを起こすでしょう。 + これはバグです (ASF bugzilla の PR 46665)。 + 回避策としてマッチ判定を書き換える必要があります:

+ + ProxyPassMatch ^/(.*\.gif)$ http://backend.example.com:8000/$1 + + + +

サブディレクトリをリバースプロキシしたくないときに ! は + 役に立ちます。

+ +

LocationMatch セクションの中で使われた場合は、 + 最初の引数は省略され、正規表現は LocationMatch から取得されます。

より柔軟なリバースプロキシの設定が必要な場合は、[P] フラグ付きの RewriteRule ディレクティブを参照してください。

+ + + セキュリティの警告 +

ルールの対象 URL の生成には注意してください。あなたのサーバがプロキシ + として振る舞う可能性のある URL に対して、クライアントへの影響があります。 + これによるセキュリティインパクトを考慮してください。URL のうち、スキームとホスト名 + の部分をそれぞれ確実に固定してください。そうでないと、クライアントに不当な影響を + 与えかねません。

+ ProxyPassReverse -リバースプロキシされたサーバから送られた HTTP 応答ヘッダの +リバースプロキシされたサーバから送られた HTTP レスポンスヘッダの URL を調整する -ProxyPassReverse [path] url +ProxyPassReverse [path] url +[interpolate] server configvirtual host directory @@ -686,15 +1138,16 @@ URL を調整する

このディレクティブは Apache に HTTP リダイレクト応答の Location, Content-Location, URI - ヘッダの調整をさせます。これは、Apache がリバースプロキシとして使われている - ときに、リバースプロキシを通さないでアクセスすることを防ぐために - 重要です。これによりバックエンドサーバの HTTP リダイレクトが - リバースプロキシとバックエンドの間で扱われるようになります。

- -

ディレクティブで明示されている HTTP 応答ヘッダのみが書き換えられます。 - Apache は他の応答ヘッダを書き換えたり、HTML ページの中の URL 参照を - 書き換えたりすることはありません。HTML の中を見て、URL 参照を書き換える - モジュールに Nick Kew さんの + +

上記の特別なリダイレクト用の HTTP レスポンスヘッダのみが書き換えられます。 + Apache は他のレスポンスヘッダを書き換えたり、HTML ページの中の URL 参照を + 書き換えたりすることはありません。つまり、リバースプロキシされた HTML ページ内に + 絶対 URL 参照が存在すると、プロキシを通さずにアクセスする可能性があります。 + HTML の中を見て、URL 参照を書き換えるモジュールに Nick Kew さんの mod_proxy_html があります。

@@ -714,11 +1167,11 @@ URL を調整する

という設定をすると、http://example.com/mirror/foo/bar へのローカルリクエストが http://backend.example.com/bar - へのプロキシリクエストに内部でリダイレクトされるだけではありません + へのプロキシリクエストに内部で変換されるだけではありません (これは ProxyPass の機能です)。backend.example.com - が送るリダイレクトの面倒もみます。http://backend.example.com/bar + サーバが送るリダイレクトの面倒もみます。http://backend.example.com/bar が http://backend.example.com/quux にリダイレクトされたとき、 - Apache は HTTP リダイレクト応答をクライアントに送る前に、 + Apache は HTTP リダイレクト応答をクライアントに送る前に、リダイレクト先を http://example.com/mirror/foo/quux に変更します。 URL を構成するのに使われるホスト名は UseCanonicalName の設定に応じて選択されることに @@ -726,14 +1179,30 @@ URL を調整する

ProxyPassReverse ディレクティブは 対応する ProxyPass ディレクティブには依存しないため、 + >ProxyPass ディレクティブと独立して利用できるので、 mod_rewrite のプロキシ通過機能 - (RewriteRule ... [P]) と併せて使用することができます。

+ (RewriteRule ... [P]) と併せて使用することもできます。

+ +

オプショナルな interpolate キーワード (httpd 2.2.9 以降で利用可能) + を ProxyPassInterpolateEnv ディレクティブと + 一緒に使うと、${VARNAME} 形式で、 ProxyPassReverse 設定に環境変数を + 使えるようになります。

Location セクションの中で使われた場合は、 最初の引数は省略され、ローカルディレクトリは Location から取得されます。

+ type="section" module="core">Location から取得されます。 + 同じことは LocationMatch セクション内でも起きますが、 + おそらく意図どおりに動きません。と言うのも、ProxyPassReverse + が正規表現をそのまま文字列でパスとして解釈しようとするからです。 + もしこのような状況で必要なら、セクションの外で ProxyPassReverse + を指定するか、あるいは別の Location セクション内で指定してください。

+ +

このディレクティブは Directory や Files セクション内では使えません。

 @@ -741,31 +1210,47 @@ URL を調整する ProxyPassReverseCookieDomain リバースプロキシサーバからの Set-Cookie ヘッダの Domain 文字列を 調整する -ProxyPassReverseCookieDomain internal-domain public-domain +ProxyPassReverseCookieDomain internal-domain +public-domain [interpolate] server configvirtual host directory

使用法は基本的に ProxyPassReverse と同じですが、 -ヘッダの URL の代わりに Set-Cookie ヘッダの +ヘッダの URL の代わりに Set-Cookie ヘッダ内の domain 文字列を書き換えます。

 + ProxyPassReverseCookiePath -Reverse プロキシサーバからの Set-Cookie ヘッダの Path 文字列を +リバースプロキシサーバからの Set-Cookie ヘッダの Path 文字列を 調整する -ProxyPassReverseCookiePath internal-path public-path +ProxyPassReverseCookiePath internal-path +public-path [interpolate] server configvirtual host directory -

使用法は基本的に -ProxyPassReverse と同じですが、 -ヘッダの URL の代わりに Set-Cookie ヘッダの -path 文字列を書き換えます。

+

+バックエンドの URL パスがリバースプロキシ上の公開パスにマップされる状況で、 +ProxyPassReverse といっしょに +役立ちます。このディレクティブは Set-Cookie ヘッダ内の +path 文字列を書き換えます。もしクッキーのパスが +internal-path に先頭マッチすれば、クッキーのパスは +public-path に置換されます。 +

+ProxyPassReverse +での例を使うと、ディレクティブ: + + ProxyPassReverseCookiePath / /mirror/foo/ + +は、バックエンドのパスが / (あるいは /example +あるいは実際のところなんでも) のクッキーを /mirror/foo/ +に書き換えます。 +

 @@ -791,7 +1276,7 @@ URL を調整する このデフォルトを上書きして、リストに記載したポートにのみ接続を許可したい場合、 AllowCONNECT ディレクティブを使用します。

-

CONNECT を使用するには、mod_proxy_connect +

CONNECT を使用するには、mod_proxy_connect がサーバに組み込まれていなければならないことに注意してください。

@@ -808,7 +1293,7 @@ URL を調整する

ProxyBlock ディレクティブは空白で区切られた 語句、ホスト名、ドメインのリストを指定します。サイト名にその語句、ホスト名、 ドメインを含むサイトへの HTTP、HTTPS、FTP によるドキュメントのリクエストは - プロキシサーバによりブロックされます。プロキシモジュールは + プロキシサーバにより ブロックされます。プロキシモジュールは 起動時にホスト名と思しき項目の IP アドレスを調べ、後のテストのために キャッシュします。これにより、サーバの起動が少し遅くなるかもしれません。

@@ -871,20 +1356,28 @@ URL を調整する ProxyMaxForwards リクエストがフォワードされるプロキシの最大数 ProxyMaxForwards number -ProxyMaxForwards 10 +ProxyMaxForwards -1 server configvirtual host -Apache 2.0 以降で使用可能 +Apache 2.0 以降で使用可能; Apache 2.2.7でデフォルト動作が変わりました

ProxyMaxForwards ディレクティブは リクエストに Max-Forwards ヘッダが指定されていない場合に リクエストが通過可能なプロキシの最大数を設定します。これは - プロキシの無限ループや DoS 攻撃を防ぐために設定されています。

+ プロキシの無限ループや DoS 攻撃を防ぐために設定されるかもしれません。

例 ProxyMaxForwards 15 + +

ProxyMaxForwards の設定は、HTTP/1.1 (RFC2616) + に違反します。と言うのも、RFC2616 は、クライアントが Max-Forwards + ヘッダをセットしない時、プロキシが Max-Forwards ヘッダを + セットすることを禁じているからです。 + Apache の初期バージョンは常にセットする可能性がありました。 + ProxyMaxForwards に負数 (デフォルト値の -1 も含む) + を指定すると、HTTP/1.1 準拠の動作になります。しかし、これは無限ループの危険性を残します。

 @@ -904,8 +1397,8 @@ URL を調整する フォワードされず、直接処理されます。

例 - ProxyRemote * http://firewall.mycompany.com:81
- NoProxy .mycompany.com 192.168.112.0/21 + ProxyRemote * http://firewall.example.com:81
+ NoProxy .example.com 192.168.112.0/21

NoProxy ディレクティブの host 引数は @@ -915,7 +1408,7 @@ URL を調整する

Domain
-

Domain は先頭にピリオドの着いた部分 DNS ドメイン名です。 +

Domain は先頭にピリオドを書いた部分 DNS ドメイン名です。 同一 DNS ドメイン及びゾーン (すなわち、ホスト名の末尾がすべて Domain で終わっているということ) に属するホストのリストを 表します)。

@@ -928,12 +1421,12 @@ URL を調整する >Hostname と区別するために (意味的にも構文的にも。DNS ドメインも DNS の A レコードを持つことができるのです!)、Domain は 常にピリオドで始まります。

- + 注

ドメイン名の比較は大文字小文字を区別せずに行なわれ、Domain は常に DNS ツリーのルートから始まるものとみなされます。ですから、 - 次の二つのドメイン .MyDomain.com と - .mydomain.com. (最後のピリオドに注目) は同一であると + 次の二つのドメイン .ExAmple.com と + .example.com. (最後のピリオドに注目) は同一であると みなされます。ドメインの比較は DNS ルックアップなしで行なわれるため、 サブネットの比較よりもずっと効率的です。

@@ -978,7 +1471,7 @@ URL を調整する 例 192.168.123.7 - + 注

IPAddr は DNS システムにより解決される必要がないので、 apache の性能が向上するかもしれません。

@@ -996,7 +1489,7 @@ URL を調整する されなければなりません)。

例 - prep.ai.mit.edu
+ prep.ai.example.com
www.apache.org @@ -1008,8 +1501,8 @@ URL を調整する ことがあります。

Hostname の比較は大文字小文字を区別せずに行なわれ、 Hostname は常に DNS ツリーのルートから始まるものとみなされます。 - ですから、二つのドメイン WWW.MyDomain.com と - www.mydomain.com. (最後のピリオドに注目) は同一であると + ですから、二つのドメイン WWW.ExAmple.com と + www.example.com. (最後のピリオドに注目) は同一であると みなされます。

 @@ -1021,14 +1514,14 @@ URL を調整する ProxyTimeout プロキシされたリクエストのネットワークタイムアウト ProxyTimeout seconds -ProxyTimeout 300 +Timeout の値 server configvirtual host Apache 2.0.31 以降で使用可能

このディレクティブはユーザがプロキシリクエストのタイムアウトを - 指定できるようにします。これはハングしてしまう遅い、もしくは挙動の + 指定できるようにします。これはハングしてしまうほど遅い、もしくは挙動の 怪しいサーバがあり、サーバがデータを返すまでひたすら待ち続けるよりも タイムアウトを返してより緩やかにgraceful に 失敗させたい場合に役に立ちます。

@@ -1050,16 +1543,16 @@ URL を調整する が追加された同じホストへのリダイレクト応答が返されます。

例 - ProxyRemote * http://firewall.mycompany.com:81
- NoProxy .mycompany.com 192.168.112.0/21
- ProxyDomain .mycompany.com + ProxyRemote * http://firewall.example.com:81
+ NoProxy .example.com 192.168.112.0/21
+ ProxyDomain .example.com ProxyVia -プロキシされたリクエストの Via HTTP 応答ヘッダ +プロキシされたリクエストの Via HTTP レスポンスヘッダ により提供される情報 ProxyVia On|Off|Full|Block ProxyVia Off @@ -1099,7 +1592,7 @@ URL を調整する ProxyErrorOverride Off server configvirtual host -バージョン 2.0 以降で使用可能 +Apache 2.0 以降で使用可能

このディレクティブはリバースプロキシを使用していて、 @@ -1109,6 +1602,59 @@ URL を調整する するようにもします (デフォルトの動作は、プロキシされたサーバの エラーページの表示で、このディレクティブを有効にすると SSI のエラー メッセージを表示します)。

+ +

このディレクティブは informational (1xx), 成功 (2xx), + リダイレクト (3xx) ステータスのレスポンス処理には影響しません。

+ + + + +ProxyPassInterpolateEnv +リバースプロキシ設定内での環境変数の使用を有効にする +ProxyPassInterpolateEnv On|Off +ProxyPassInterpolateEnv Off +server config +virtual host +directory + +Apache 2.2.9 以降で使用可能 + + +

ProxyPass, ProxyPassReverse, + ProxyPassReverseCookieDomain, + ProxyPassReverseCookiePath の + interpolate 引数と一緒にこのディレクティブを使うと、 + 環境変数を使ってリバースプロキシを動的に設定できます。 + mod_rewrite など他のモジュールで環境変数を設定する想定です。 + ProxyPass ディレクティブ, + ProxyPassReverse ディレクティブ, + ProxyPassReverseCookieDomain ディレクティブ, + ProxyPassReverseCookiePath ディレクティブ + の動作に影響を与え、これらの設定ディレクティブ内の ${varname} の文字列を + 環境変数 varname の値で置き換えます。 + (interpolate オプションがセットされていれば)

+

必要にならない限り、このディレクティブは無効にしてください。 + (サーバのパフォーマンスのため)

+ + + + +ProxyStatus +mod_status でプロキシのロードバランサの状態を表示 +ProxyStatus Off|On|Full +ProxyStatus Off +server config +virtual host + +Apache 2.2 以降で使用可能 + + +

このディレクティブは mod_status によるサーバステータスのページ + にプロキシのロードバランサの状態を表示するか否かを決めます。

+ 注意 +

Full は On の別名です。

+ +