モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

Apache HTTP サーバ バージョン 2.2

<-
Apache > HTTP サーバ > ドキュメンテーション > バージョン 2.2 > モジュール

Apache モジュール mod_proxy

翻訳済み言語:  en  |  fr  |  ja 

この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。
説明:HTTP/1.1 プロキシ/ゲートウェイサーバ
ステータス:Extension
モジュール識別子:proxy_module
ソースファイル:mod_proxy.c

概要

警告

サーバを安全にするまで ProxyRequests は有効にしないでください。 オープンプロキシサーバはあなた自身のネットワークにとっても、 インターネット全体にとっても危険です。

このモジュールは Apache のプロキシ/ゲートウェイ機能を実装しています。 AJP13 (Apache JServe Protocol version 1.3), FTP, CONNECT (SSL 用), HTTP/0.9, HTTP/1.0, HTTP/1.1 のプロキシ機能を実装しています。これらのプロトコルやその他のプロトコル用の プロキシ機能を持った、他のモジュールに接続するようにも設定できます。

Apache のプロキシ機能は mod_proxy の他に、 いくつかのモジュールに分割されています: mod_proxy_http, mod_proxy_ftp, mod_proxy_ajp, mod_proxy_balancer, mod_proxy_connect です。ですから、 特定のプロキシの機能を使いたい場合は、mod_proxy と 該当するモジュールをサーバに (コンパイル時に静的に行なうか LoadModule で動的に読み込むかして) 組み込む必要があります。

これに加えて、他のモジュールによって拡張機能が提供されています。 キャッシュは mod_cache と関連モジュールで 提供されています。SSL/TLS で遠隔サーバに接続する機能は mod_ssl の SSLProxy* ディレクティブで 提供されています。これらの機能を利用するためには、該当するモジュールを 組み込んで設定しなければなりません。

ディレクティブ

トピック

参照

top

フォワードプロキシとリバースプロキシ/ゲートウェイ

Apache は フォワード プロキシとしても、 リバース プロキシ (別名 ゲートウェイ) としても設定できます。

通常の フォワードプロキシ はクライアントと オリジンサーバ (訳注: コンテンツ生成元のサーバ) の間に位置する中間サーバです。 オリジンサーバからコンテンツを取得するために、クライアントは 行き先をオリジンサーバに指定したリクエストをプロキシに送ります。 プロキシはオリジンサーバからコンテンツを受け取り、 取得したコンテンツをクライアントに返します。 クライアントがフォワードプロキシ経由で他のサイトにアクセスするには、 特別にそのための設定をしなければなりません。

フォワードプロキシの一般的な使用方法は、ファイアウォールによって 制限されている内部のクライアントに、インターネットへのアクセスを 提供するものです。フォワードプロキシはネットワークの使用量を 減らすために (mod_cache で提供されている) キャッシュ機能を用いることもできます。

フォワードプロキシは ProxyRequests ディレクティブで 有効になります。フォワードプロキシを使うと、クライアントは本当の身元を 隠して任意のサイトにアクセスできるようになります。このため、フォワードプロキシを 有効にする前に、承認されたクライアントのみがプロキシにアクセスできるように サーバを安全にすることが重要です。

一方 リバースプロキシ (ゲートウェイ) は、 クライアントから普通のウェブサーバのように見えます。 クライアント側に特別な設定は必要ありません。 クライアントはリバースプロキシの名前空間内のコンテンツに対して通常どおりの リクエストを行ないます。リバースプロキシはリクエストをどこに送れば良いかを判定し、 あたかも自分自身がオリジンサーバであったかのようにクライアントに コンテンツを返します。

リバースプロキシのよくある利用方法は、インターネットユーザに ファイアウォールの中にあるサーバにアクセスさせる場合です。 リバースプロキシは複数のバックエンドサーバへ負荷分散をするために 使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり するためにも使えます。また、リバースプロキシは複数のサーバを 同じ URL 空間にまとめるために使うこともできます。

リバースプロキシは ProxyPass ディレクティブや RewriteRule ディレクティブの [P] フラグを使うことで有効になります。リバースプロキシの 設定のために ProxyRequests を設定する必要は ありません。

top

基本の例

以下の例は手始めの簡単な例です。個々のディレクティブの意味は それぞれの説明をお読みください。

またキャッシュ機能を有効にしたい場合は、mod_cache の説明を読んでください。

リバースプロキシ

ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar

フォワードプロキシ

ProxyRequests On
ProxyVia On

<Proxy *>
Order deny,allow
Deny from all
Allow from internal.example.com
 </Proxy>

top

ワーカー

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

ふたつのデフォルトワーカーは固定の設定を持ちます。 リクエストが他のワーカーにマッチしない場合に使われます。 これらは 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 を使って、バランサーにメンバーを追加します。

top

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

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

<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
 </Proxy>

アクセス制御のためのディレクティブのより詳しい情報は mod_authz_host をお読みください。

(ProxyRequests ディレクティブを 使って) フォワードプロキシを設定している場合は、厳しくアクセス 制限を行なうことが非常に大切です。そうしないと、任意のクライアントが 身元を明かすことなく任意のホストにアクセスするためにプロキシサーバを使うことが できてしまいます。これはあなた自身のネットワークにとっても、インターネット 全体にとっても危険なことです。(ProxyRequests Off にして ProxyPass ディレクティブを使って) リバースプロキシを使っている場合には、クライアントはあなたが明示的に 設定したホストにしかアクセスできないため、フォワードプロキシのとき ほどアクセス制御に力を注がなくても大丈夫です。

top

遅い起動

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

top

イントラネットプロキシ

イントラネットにある Apache プロキシサーバは外部へのリクエストを 会社のファイアウォールを通して送らなければなりません。(このためには 個々の scheme についてそれぞれ、ファイアウォールの プロキシにフォワードされるように ProxyRemote ディレクティブを 設定してください)。しかしイントラネット内のリソースにアクセスするときは、 ファイアウォールを通さないでもアクセスできます。 どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、 NoProxy ディレクティブが 役に立ちます。

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

top

プロトコルの調整

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

force-proxy-request-1.0 と proxy-nokeepalive がその環境変数です。

<Location /buggyappserver/>
ProxyPass http://buggyappserver:7001/foo/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
 </Location>

top

リクエストボディ

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

top

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

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

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

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

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

top

AllowCONNECT ディレクティブ

説明:プロキシを経由して、どのポートに CONNECT できるかを指定する
構文:AllowCONNECT port [port] ...
デフォルト:AllowCONNECT 443 563
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

AllowCONNECT はプロキシの CONNECT メソッドが接続を許可するポート番号のリストを指定します。 今日のブラウザは、https コネクションが要求されていて、 HTTP 上でのプロキシによるトンネリングができるときに、 このメソッドを使います。

デフォルトの設定では、https のデフォルトポート (443) と デフォルトの snews ポート (563) が有効になっています。 このデフォルトを上書きして、リストに記載したポートにのみ接続を許可したい場合、 AllowCONNECT ディレクティブを使用します。

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

top

BalancerMember ディレクティブ

説明:ロードバランサのグループにメンバーを追加
構文:BalancerMember [balancerurl] url [key=value [key=value ...]]
コンテキスト:ディレクトリ
ステータス:Extension
モジュール:mod_proxy
互換性:BalancerMember は Apache 2.2 以降でのみ使用可能

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

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

top

NoProxy ディレクティブ

説明:直接接続する ホスト、ドメイン、ネットワーク
構文:NoProxy host [host] ...
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

このディレクティブはイントラネット中の Apache プロキシサーバにのみ 有用です。NoProxy ディレクティブは空白区切りで、 サブネット、IP アドレス、ホスト、ドメインのリストを指定します。 これらのどれかにマッチするホストへのリクエストは ProxyRemote で設定されたプロキシサーバに フォワードされず、直接処理されます。

例

ProxyRemote * http://firewall.example.com:81
NoProxy .example.com 192.168.112.0/21

NoProxy ディレクティブの host 引数は 以下の種類のどれかです:

Domain

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

例

.com .apache.org.

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

注

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

SubNet

SubNet は数値形式 (ドットで区切られた四つの数字) の 部分インターネットアドレスです。後にスラッシュと Subnet の意味のあるビット数を指定するネットマスクとを続けることができます。 共通のネットワークインタフェースを使って到達することのできるサブネットを 表すために使われます。明示的にネットマスクを指定しない場合は 最後の省略された (もしくは値が 0 の) 数字がマスクを指定します。 (この場合は、ネットマスクは 8 ビット単位でしか指定できません。) 例:

192.168 もしくは 192.168.0.0
サブネット 192.168.0.0 と暗黙の 16 ビット有効なネットマスク (255.255.0.0 というネットマスクの形式で使われることも あります)
192.168.112.0/21
サブネット192.168.112.0/21 と 21 ビット有効な ネットマスク (255.255.248.0 という形式で使われることも あります)

特別な場合に、32 ビット有効な SubNet は IPAddr と同等で、 0 ビット有効な SubNet (例えば、0.0.0.0/0) は すべての IP アドレスにマッチする定数 _Default_ と同じです。

IPAddr

IPAddr は数値形式 (ドットで区切られた四つの数字) の 完全インターネットアドレスです。通常はこのアドレスはホストを 表しますが、必ずしもアドレスに対応する DNS ドメイン名があるわけでは ありません。

例

192.168.123.7

注

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

Hostname

Hostname は DNS ドメインサービスにより一つもしくは 複数の IPAddr に解決可能な 完全な DNS ドメイン名です。これは (Domain と違って、説明は上記を参照) 論理的なホストを表し、少くとも一つの IPAddr (もしくは違う IPAddr のホストのリスト) に解決 されなければなりません)。

例

prep.ai.example.com
www.apache.org

注

多くの場合、Hostname の代わりに IPAddr を指定した方が、DNS ルックアップを 避けることができるため、効率が良くなります。Apache の名前解決は ネームサーバへの接続が遅い PPP 上の場合などにかなり時間を取られる ことがあります。

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

参照

top

<Proxy> ディレクティブ

説明:プロキシされるリソースに適用されるコンテナ
構文:<Proxy wildcard-url> ...</Proxy>
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

<Proxy> セクション中の ディレクティブはマッチするプロキシされるコンテンツにのみ適用されます。 シェル形式のワイルドカードが使えます。

例えば、次の設定は yournetwork.example.com の ホストにのみプロキシサーバを経由したアクセスを許可します:

<Proxy *>
Order Deny,Allow
Deny from all
Allow from yournetwork.example.com
 </Proxy>

次の例は example.com の foo ディレクトリの すべてのファイルに対して、プロキシサーバを通して送られたときには INCLUDES フィルタを通して送るように設定します:

<Proxy http://example.com/foo/*>
SetOutputFilter INCLUDES
 </Proxy>

参照

top

ProxyBadHeader ディレクティブ

説明:応答におかしなヘッダがある場合の扱い方を決める
構文:ProxyBadHeader IsError|Ignore|StartBody
デフォルト:ProxyBadHeader IsError
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.0.44 以降で使用可能

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

IsError
リクエストを中止して 502 (Bad Gateway) 応答を返す。 これがデフォルトの動作です。
Ignore
間違ったヘッダ行をそもそも存在しなかったものとして扱う。
StartBody
間違ったヘッダ行を受け取ったら、ヘッダの読み込みを終了して、 それ以降の残りをボディとして扱う。これはヘッダとボディの間に空行を入れ忘れて しまっているような、きちんと動作していないバックエンドサーバがあるときに、 問題を回避するのに役に立ちます。
top

ProxyBlock ディレクティブ

説明:プロキシ接続を禁止する語句、ホスト名、ドメインを指定する
構文:ProxyBlock *|word|host|domain [word|host|domain] ...
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

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

Example

ProxyBlock joes-garage.com some-host.co.uk rocky.wotsamattau.edu

rocky.wotsamattau.edu が IP アドレスで参照されたときでも マッチします。

wotsamattau.edu のマッチには wotsamattau だけでも十分です。

ProxyBlock *

はすべてのサイトへの接続をブロックすることに注意してください。

top

ProxyDomain ディレクティブ

説明:プロキシされたリクエストのデフォルトのドメイン名
構文:ProxyDomain Domain
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

このディレクティブはイントラネット内の Apache プロキシサーバにのみ 有用です。ProxyDomain ディレクティブは apache プロキシサーバが属するデフォルトのドメインを指定します。 ドメイン名の無いリクエストを受けた場合、設定された Domain が追加された同じホストへのリダイレクト応答が返されます。

例

ProxyRemote * http://firewall.example.com:81
NoProxy .example.com 192.168.112.0/21
ProxyDomain .example.com

top

ProxyErrorOverride ディレクティブ

説明:プロキシされたコンテンツのエラーページを上書きする
構文:ProxyErrorOverride On|Off
デフォルト:ProxyErrorOverride Off
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.0 以降で使用可能

このディレクティブはリバースプロキシを使用していて、 エンドユーザに送られるエラーページの外見を共通のものにしたいときに 有用です。このディレクティブは (mod_include の SSI によって) インクルードされたファイルがエラーコードを取得して、正しく動作を するようにもします (デフォルトの動作は、プロキシされたサーバの エラーページの表示で、このディレクティブを有効にすると SSI のエラー メッセージを表示します)。

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

top

ProxyFtpDirCharset ディレクティブ

説明:プロキシされた FTP (の一覧表示) のキャラクタセットを定義
構文:ProxyFtpDirCharset character set
デフォルト:ProxyFtpDirCharset ISO-8859-1
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.2.7 以降で使用可能

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

top

ProxyIOBufferSize ディレクティブ

説明:内部データスループットバッファのサイズを決定する
構文:ProxyIOBufferSize bytes
デフォルト:ProxyIOBufferSize 8192
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

ProxyIOBufferSize ディレクティブは入力と 出力用の一時メモリとして使われる内部バッファのサイズを調整します。 サイズは 8192 以下でなければなりません。

ほとんどすべての場合、この値を変更する理由はありません。

top

<ProxyMatch> ディレクティブ

説明:正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ
構文:<ProxyMatch regex> ...</ProxyMatch>
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

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

参照

top

ProxyMaxForwards ディレクティブ

説明:リクエストがフォワードされるプロキシの最大数
構文:ProxyMaxForwards number
デフォルト:ProxyMaxForwards -1
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.0 以降で使用可能; Apache 2.2.7でデフォルト動作が変わりました

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

例

ProxyMaxForwards 15

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

top

ProxyPass ディレクティブ

説明:リモートサーバをローカルサーバの URL 空間にマップする
構文:ProxyPass [path] !|url [key=value key=value ...]] [nocanon] [interpolate]
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy

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

ProxyPass ディレクティブを 使っているときは ProxyRequests ディレクティブは通常は off に設定されているべきです。

ローカルサーバのアドレスが http://example.com/ であると します。すると、

ProxyPass /mirror/foo/ http://backend.example.com/

と設定すると http://example.com/mirror/foo/bar への リクエストが内部的に http://backend.example.com/bar への プロキシリクエストに変換されることになります。

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

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

ProxyPass /mirror/foo/i !
ProxyPass /mirror/foo http://backend.example.com

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

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 設計によってはこの限りではありません。

例

ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300

パラメータ デフォルト値 説明
min 0 コネクションプール内で実際の接続に関連していないエントリの最小数です。 デフォルト値から変更する必要があるのは、バックエンドとの接続に必要な ヒープメモリを事前に割り当てるか維持しなければいけない特別な状況のみです。
max 1...n バックエンドサーバとの接続数の最大値です。 デフォルト値は、使用している MPM のプロセスあたりのスレッド数になっています。 Prefork MPM では常に 1 で、他の MPM では ThreadsPerChild ディレクティブで調節できます。
smax max もしコネクションプール内の接続中エントリが ttl パラメータ で設定した生存期間より長く未使用のままであれば、 この指定値を越える分のエントリを解放します。 もしエントリが関連するコネクションを持てば、接続を閉じます。 デフォルト値から変更する必要があるとすれば、 コネクションが生存期間を越えてしまった時に、 コネクションプール内の該当エントリの解放とコネクションの切断を より積極的に必要とする特別な場合のみです。
acquire - 設定すると、コネクションプールからフリーのコネクションを取得するために 待機する待ち時間 (ミリ秒単位) の最大値になります。フリーのコネクションがプールになかった場合は、 SERVER_BUSY ステータスをクライアントに返します。
connectiontimeout timeout 接続タイムアウトを秒で指定します。 バックエンドに接続を完了するまでの Apache の待ち時間です。 値の最後に ms を書くと、タイムアウトの単位をミリ秒にできます。
disablereuse Off 使用後すぐに mod_proxy がバックエンドとの接続を切断してほしい時は、 このパラメータを有効にすべきです。そうすることで、バックエンドとの 永続的な接続とプーリングを無効にできます。 これはいくつかの状況下で役に立ちます。例えば、Apache とバックエンドサーバ の間にファイアウォールが存在し (プロトコルは問わないとします)、黙って 接続を切られる場合や、あるいは、バックエンドサーバ自体が DNS で ラウンドロビンされている場合などです。コネクションプーリングによる再利用を 無効にするには、このパラメータ値を On にしてください。
flushpackets off プロキシモジュールが "chunk" ごとに出力データを自動的に強制送信(フラッシュ) するかを指定します。 'off' は必要な時だけ強制送信します。 'on' はそれぞれの "chunk" データごとに強制送信します。 'auto' は、一定時間待機し、 'flushwait' で指定したミリ秒の間、入力データが無ければ強制送信します。 現在、このパラメータは AJP でのみ意味があります。
flushwait 10 'flushpackets' パラメータの値が 'auto' の場合、出力データを強制送信する前に、 次の入力をどのぐらい待つかをミリ秒単位で指定します。
keepalive Off

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

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

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

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

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

バランサーの設定例

ProxyPass /special-area http://special.example.com smax=5 max=10
ProxyPass / balancer://mycluster/ stickysession=JSESSIONID|jsessionid nofailover=On
<Proxy balancer://mycluster>
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> から取得されます。 同じことは <LocationMatch> セクション内でも起きます。しかし、ProxyPass は正規表現を解釈しないので、 この状況では代わりに ProxyPassMatch を使う必要があります。

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

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

top

ProxyPassInterpolateEnv ディレクティブ

説明:リバースプロキシ設定内での環境変数の使用を有効にする
構文:ProxyPassInterpolateEnv On|Off
デフォルト:ProxyPassInterpolateEnv Off
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.2.9 以降で使用可能

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

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

top

ProxyPassMatch ディレクティブ

説明:正規表現を使ってリモートサーバをローカルサーバの URL 空間にマップする
構文:ProxyPassMatch [regex] !|url [key=value [key=value ...]]
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy
互換性: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 のうち、スキームとホスト名 の部分をそれぞれ確実に固定してください。そうでないと、クライアントに不当な影響を 与えかねません。

top

ProxyPassReverse ディレクティブ

説明:リバースプロキシされたサーバから送られた HTTP レスポンスヘッダの URL を調整する
構文:ProxyPassReverse [path] url [interpolate]
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy

このディレクティブは Apache に HTTP リダイレクト応答の Location, Content-Location, URI ヘッダの調整をさせます。これは、Apache がリバースプロキシ (ゲートウェイ) として使われているときに、リバースプロキシを通らないアクセスを防止するのに重要です。 このようなアクセスは、リバースプロキシの背後にいるバックエンドサーバへの HTTP リダイレクトが原因で起きます。

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

path はローカル仮想パスの名前です。url は リモートサーバの部分 URL です。これらは ProxyPass ディレクティブと同様です。

例えば、ローカルサーバのアドレスが http://example.com/ だとします。すると

ProxyPass /mirror/foo/ http://backend.example.com/
ProxyPassReverse /mirror/foo/ http://backend.example.com/
ProxyPassReverseCookieDomain backend.example.com public.example.com
ProxyPassReverseCookiePath / /mirror/foo/

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

ProxyPassReverse ディレクティブは 対応する ProxyPass ディレクティブと独立して利用できるので、 mod_rewrite のプロキシ通過機能 (RewriteRule ... [P]) と併せて使用することもできます。

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

<Location> セクションの中で使われた場合は、 最初の引数は省略され、ローカルディレクトリは <Location> から取得されます。 同じことは <LocationMatch> セクション内でも起きますが、 おそらく意図どおりに動きません。と言うのも、ProxyPassReverse が正規表現をそのまま文字列でパスとして解釈しようとするからです。 もしこのような状況で必要なら、セクションの外で ProxyPassReverse を指定するか、あるいは別の <Location> セクション内で指定してください。

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

top

ProxyPassReverseCookieDomain ディレクティブ

説明:リバースプロキシサーバからの Set-Cookie ヘッダの Domain 文字列を 調整する
構文:ProxyPassReverseCookieDomain internal-domain public-domain [interpolate]
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy

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

top

ProxyPassReverseCookiePath ディレクティブ

説明:リバースプロキシサーバからの Set-Cookie ヘッダの Path 文字列を 調整する
構文:ProxyPassReverseCookiePath internal-path public-path [interpolate]
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy

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

ProxyPassReverse での例を使うと、ディレクティブ:

ProxyPassReverseCookiePath / /mirror/foo/

は、バックエンドのパスが / (あるいは /example あるいは実際のところなんでも) のクッキーを /mirror/foo/ に書き換えます。

top

ProxyPreserveHost ディレクティブ

説明:プロキシリクエストに、受け付けた Host HTTP ヘッダを使う
構文:ProxyPreserveHost On|Off
デフォルト:ProxyPreserveHost Off
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.0.31 以降で使用可能

このオプションが有効になっている場合、ProxyPass で指定したホスト名の代わりに、受け付けたリクエストの Host: 行を プロキシ先のホストに送ります。

このオプションは通常は Off に設定してください。 ほとんどの場合、これは大量の名前ベースのバーチャルホスティングを行なっていて、 元々の Host ヘッダをバックエンドサーバが解釈する必要のあるときのような、 特別な設定が必要な場合にのみ有用です。

top

ProxyReceiveBufferSize ディレクティブ

説明:プロキシされる HTTP と FTP 接続のためのネットワークバッファサイズ
構文:ProxyReceiveBufferSize bytes
デフォルト:ProxyReceiveBufferSize 0
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

ProxyReceiveBufferSize ディレクティブは スループットを上げるために明示的に (TCP/IP) ネットワークバッファのサイズを 設定します。値は 512 以上か、システムのデフォルトのバッファ サイズを意味する 0 でなければなりません。

例

ProxyReceiveBufferSize 2048

top

ProxyRemote ディレクティブ

説明:特定のリクエストを扱う時に使われるリモートプロキシを指定する
構文:ProxyRemote match remote-server
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

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

remote-server = scheme://hostname[:port]

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

例

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

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

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

top

ProxyRemoteMatch ディレクティブ

説明:正規表現でのマッチによるリクエストを扱うリモートプロキシの指定
構文:ProxyRemoteMatch regex remote-server
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

ProxyRemoteMatch は最初の引数がリクエストされた URL にマッチする正規表現であることを除けば ProxyRemote ディレクティブと同じです。

top

ProxyRequests ディレクティブ

説明:フォワード (標準の) プロキシリクエストを有効にする
構文:ProxyRequests On|Off
デフォルト:ProxyRequests Off
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

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

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

HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、 mod_proxy_http や mod_proxy_ftp が サーバに組み込まれていなければなりません。

警告

サーバを安全にするまで ProxyRequests は有効にしないでください。 オープンプロキシサーバはあなた自身のネットワークにとっても、 インターネット全体にとっても危険です。

参照

top

ProxySet ディレクティブ

説明:プロキシのバランサやメンバのパラメータをセット
構文:ProxySet url key=value [key=value ...]
コンテキスト:ディレクトリ
ステータス:Extension
モジュール:mod_proxy
互換性: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

警告

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

top

ProxyStatus ディレクティブ

説明:mod_status でプロキシのロードバランサの状態を表示
構文:ProxyStatus Off|On|Full
デフォルト:ProxyStatus Off
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.2 以降で使用可能

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

注意

Full は On の別名です。

top

ProxyTimeout ディレクティブ

説明:プロキシされたリクエストのネットワークタイムアウト
構文:ProxyTimeout seconds
デフォルト:Timeout の値
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.0.31 以降で使用可能

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

top

ProxyVia ディレクティブ

説明:プロキシされたリクエストの Via HTTP レスポンスヘッダ により提供される情報
構文:ProxyVia On|Off|Full|Block
デフォルト:ProxyVia Off
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

このディレクティブはプロキシの Via: HTTP ヘッダの使用を 制御します。想定されている使い方は、プロキシサーバがいくつも繋がっているときに プロキシリクエストの流れを制御することです。Via: ヘッダ行の 説明は RFC 2616 (HTTP/1.1) の 14.45 節を読んでください。

翻訳済み言語:  en  |  fr  |  ja 

top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
Comments are disabled for this page at the moment.