Apache HTTP サーバ バージョン 2.2
説明: | 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*
ディレクティブで
提供されています。これらの機能を利用するためには、該当するモジュールを
組み込んで設定しなければなりません。
Apache は フォワード プロキシとしても、 リバース プロキシ (別名 ゲートウェイ) としても設定できます。
通常の フォワードプロキシ はクライアントと オリジンサーバ (訳注: コンテンツ生成元のサーバ) の間に位置する中間サーバです。 オリジンサーバからコンテンツを取得するために、クライアントは 行き先をオリジンサーバに指定したリクエストをプロキシに送ります。 プロキシはオリジンサーバからコンテンツを受け取り、 取得したコンテンツをクライアントに返します。 クライアントがフォワードプロキシ経由で他のサイトにアクセスするには、 特別にそのための設定をしなければなりません。
フォワードプロキシの一般的な使用方法は、ファイアウォールによって
制限されている内部のクライアントに、インターネットへのアクセスを
提供するものです。フォワードプロキシはネットワークの使用量を
減らすために (mod_cache
で提供されている)
キャッシュ機能を用いることもできます。
フォワードプロキシは ProxyRequests
ディレクティブで
有効になります。フォワードプロキシを使うと、クライアントは本当の身元を
隠して任意のサイトにアクセスできるようになります。このため、フォワードプロキシを
有効にする前に、承認されたクライアントのみがプロキシにアクセスできるように
サーバを安全にすることが重要です。
一方 リバースプロキシ (ゲートウェイ) は、 クライアントから普通のウェブサーバのように見えます。 クライアント側に特別な設定は必要ありません。 クライアントはリバースプロキシの名前空間内のコンテンツに対して通常どおりの リクエストを行ないます。リバースプロキシはリクエストをどこに送れば良いかを判定し、 あたかも自分自身がオリジンサーバであったかのようにクライアントに コンテンツを返します。
リバースプロキシのよくある利用方法は、インターネットユーザに ファイアウォールの中にあるサーバにアクセスさせる場合です。 リバースプロキシは複数のバックエンドサーバへ負荷分散をするために 使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり するためにも使えます。また、リバースプロキシは複数のサーバを 同じ URL 空間にまとめるために使うこともできます。
リバースプロキシは ProxyPass
ディレクティブや
RewriteRule
ディレクティブの
[P]
フラグを使うことで有効になります。リバースプロキシの
設定のために ProxyRequests
を設定する必要は
ありません。
以下の例は手始めの簡単な例です。個々のディレクティブの意味は それぞれの説明をお読みください。
またキャッシュ機能を有効にしたい場合は、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>
プロキシは ワーカー と呼ばれるオブジェクトで オリジンサーバとの通信パラメータの設定を管理します。 ふたつの組み込みワーカーが存在します。デフォルトのフォワードプロキシワーカーと デフォルトのリバースプロキシワーカーです。 追加のワーカーを明示的に設定可能です。
ふたつのデフォルトワーカーは固定の設定を持ちます。 リクエストが他のワーカーにマッチしない場合に使われます。 これらは 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>
コンテナの中に
ディレクティブを書くことで制御できます:
<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Proxy>
アクセス制御のためのディレクティブのより詳しい情報は
mod_authz_host
をお読みください。
(ProxyRequests
ディレクティブを
使って) フォワードプロキシを設定している場合は、厳しくアクセス
制限を行なうことが非常に大切です。そうしないと、任意のクライアントが
身元を明かすことなく任意のホストにアクセスするためにプロキシサーバを使うことが
できてしまいます。これはあなた自身のネットワークにとっても、インターネット
全体にとっても危険なことです。(ProxyRequests Off
にして
ProxyPass
ディレクティブを使って)
リバースプロキシを使っている場合には、クライアントはあなたが明示的に
設定したホストにしかアクセスできないため、フォワードプロキシのとき
ほどアクセス制御に力を注がなくても大丈夫です。
ProxyBlock
ディレクティブを使っている場合、
後に行うマッチ判定のため、起動時にホストの名前解決をして
IP アドレスをキャッシュします。ホスト名の名前解決の
速さによっては、数秒 (かそれ以上) かかるかもしれません。
イントラネットにある Apache プロキシサーバは外部へのリクエストを
会社のファイアウォールを通して送らなければなりません。(このためには
個々の scheme についてそれぞれ、ファイアウォールの
プロキシにフォワードされるように
ProxyRemote
ディレクティブを
設定してください)。しかしイントラネット内のリソースにアクセスするときは、
ファイアウォールを通さないでもアクセスできます。
どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、
NoProxy
ディレクティブが
役に立ちます。
イントラネット内のユーザは WWW のリクエストでローカルドメインを
省略することがよくあります。http://somehost.example.com/
というリクエストの代わりに "http://somehost/" をリクエストしたりします。
このようなリクエストを受け付け、サーバに設定されているローカルドメインが
暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも
商用プロキシサーバの中にはあります。
サーバが プロキシのサービス用に設定されていて
ProxyDomain
ディレクティブが
使用された場合には、Apache はクライアントにリダイレクト応答を送って、
正しい、完全な (訳注: fully qualified)
サーバのアドレスに送ることができます。このように
リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む
ことにもなるため、より好ましい方法と言えるでしょう。
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>
POST メソッドなどのリクエストには、リクエストボディがあります。
HTTP プロトコル仕様によると、ボディのあるリクエストは chunked
転送を使うか、Content-Length
ヘッダを送信しなければなりません。
このようなリクエストをオリジンサーバに送信する場合、
mod_proxy_http
は常に Content-Length
を送ろうと試みます。しかし、ボディが大きく、オリジナルのリクエストで
chunked 転送が使われている場合、上流へのリクエストに
chunked 転送も使われます。
この挙動は 環境変数で制御できます。
proxy-sendcl
を設定すると、
常に Content-Length
を送り、最大限の互換性を確保します。
逆に proxy-sendchunked
を設定すると、
chunked エンコードを使ってリソース消費を抑えます。
リバースプロキシとして振る舞う時 (例えば、ProxyPass
ディレクティブを使う時) 、
mod_proxy_http
は、オリジンサーバに情報を渡すために
いくつかのリクエストヘッダを追加します。これらのヘッダは以下になります。
X-Forwarded-For
X-Forwarded-Host
Host
リクエストヘッダで渡す。X-Forwarded-Server
オリジンサーバ上でこれらのヘッダを扱う時は注意してください。
と言うのも、オリジナルのリクエストが既に同じヘッダを持っていると、
ヘッダが一つ以上の値 (コンマで区切られます) を持つ可能性があるからです。
例えば、 オリジンサーバ上でオリジナルのクライアントのIPアドレスをログに
記録するため、ログフォーマットに %{X-Forwarded-For}i
を
指定したとします。この時、リクエストが複数のプロキシを経由していると、
複数のアドレスがログに載る可能性があります。
ProxyPreserveHost
と
ProxyVia
ディレクティブ
も参照してください。これらは他のリクエストヘッダに影響を与えます。
説明: | プロキシを経由して、どのポートに CONNECT
できるかを指定する |
---|---|
構文: | AllowCONNECT port [port] ... |
デフォルト: | AllowCONNECT 443 563 |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
AllowCONNECT
はプロキシの CONNECT
メソッドが接続を許可するポート番号のリストを指定します。
今日のブラウザは、https
コネクションが要求されていて、
HTTP 上でのプロキシによるトンネリングができるときに、
このメソッドを使います。
デフォルトの設定では、https のデフォルトポート (443
) と
デフォルトの snews ポート (563
) が有効になっています。
このデフォルトを上書きして、リストに記載したポートにのみ接続を許可したい場合、
AllowCONNECT
ディレクティブを使用します。
CONNECT
を使用するには、mod_proxy_connect
がサーバに組み込まれていなければならないことに注意してください。
説明: | ロードバランサのグループにメンバーを追加 |
---|---|
構文: | BalancerMember [balancerurl] url [key=value [key=value ...]] |
コンテキスト: | ディレクトリ |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | BalancerMember は Apache 2.2 以降でのみ使用可能 |
このディレクティブでロードバランサのグループにメンバを追加します。
<Proxy balancer://...>
ディレクティブのコンテナ
内で使われることが多く、ProxyPass
ディレクティブと共通のキーバリューペアのパラメータを取ります。
<Proxy balancer://...>
ディレクティブの
コンテナ内に書かない場合のみ、 balancerurl 引数が必要です。 これは
ProxyPass
ディレクティブで
バランサを定義した時の URL と同じ働きをします。
説明: | 直接接続する ホスト、ドメイン、ネットワーク |
---|---|
構文: | 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 は先頭にピリオドを書いた部分 DNS ドメイン名です。 同一 DNS ドメイン及びゾーン (すなわち、ホスト名の末尾がすべて Domain で終わっているということ) に属するホストのリストを 表します)。
.com .apache.org.
Domain を Hostname と区別するために (意味的にも構文的にも。DNS ドメインも DNS の A レコードを持つことができるのです!)、Domain は 常にピリオドで始まります。
ドメイン名の比較は大文字小文字を区別せずに行なわれ、Domain
は常に DNS ツリーのルートから始まるものとみなされます。ですから、
次の二つのドメイン .ExAmple.com
と
.example.com.
(最後のピリオドに注目) は同一であると
みなされます。ドメインの比較は DNS ルックアップなしで行なわれるため、
サブネットの比較よりもずっと効率的です。
SubNet は数値形式 (ドットで区切られた四つの数字) の 部分インターネットアドレスです。後にスラッシュと Subnet の意味のあるビット数を指定するネットマスクとを続けることができます。 共通のネットワークインタフェースを使って到達することのできるサブネットを 表すために使われます。明示的にネットマスクを指定しない場合は 最後の省略された (もしくは値が 0 の) 数字がマスクを指定します。 (この場合は、ネットマスクは 8 ビット単位でしか指定できません。) 例:
192.168
もしくは 192.168.0.0
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 は数値形式 (ドットで区切られた四つの数字) の 完全インターネットアドレスです。通常はこのアドレスはホストを 表しますが、必ずしもアドレスに対応する DNS ドメイン名があるわけでは ありません。
192.168.123.7
IPAddr は DNS システムにより解決される必要がないので、 apache の性能が向上するかもしれません。
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.
(最後のピリオドに注目) は同一であると
みなされます。
説明: | プロキシされるリソースに適用されるコンテナ |
---|---|
構文: | <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>
説明: | 応答におかしなヘッダがある場合の扱い方を決める |
---|---|
構文: | ProxyBadHeader IsError|Ignore|StartBody |
デフォルト: | ProxyBadHeader IsError |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.0.44 以降で使用可能 |
ProxyBadHeader
ディレクティブは構文的に
間違ったレスポンスヘッダ (つまり コロンを含まないもの) を受け取ったときに
mod_proxy
がどう振る舞うかを決めます。以下の引数を
取ることができます:
IsError
Ignore
StartBody
説明: | プロキシ接続を禁止する語句、ホスト名、ドメインを指定する |
---|---|
構文: | ProxyBlock *|word|host|domain
[word|host|domain] ... |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
ProxyBlock
ディレクティブは空白で区切られた
語句、ホスト名、ドメインのリストを指定します。サイト名にその語句、ホスト名、
ドメインを含むサイトへの HTTP、HTTPS、FTP によるドキュメントのリクエストは
プロキシサーバにより ブロックされます。プロキシモジュールは
起動時にホスト名と思しき項目の IP アドレスを調べ、後のテストのために
キャッシュします。これにより、サーバの起動が少し遅くなるかもしれません。
ProxyBlock joes-garage.com some-host.co.uk rocky.wotsamattau.edu
rocky.wotsamattau.edu
が IP アドレスで参照されたときでも
マッチします。
wotsamattau.edu
のマッチには wotsamattau
だけでも十分です。
ProxyBlock *
はすべてのサイトへの接続をブロックすることに注意してください。
説明: | プロキシされたリクエストのデフォルトのドメイン名 |
---|---|
構文: | 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
説明: | プロキシされたコンテンツのエラーページを上書きする |
---|---|
構文: | ProxyErrorOverride On|Off |
デフォルト: | ProxyErrorOverride Off |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.0 以降で使用可能 |
このディレクティブはリバースプロキシを使用していて、
エンドユーザに送られるエラーページの外見を共通のものにしたいときに
有用です。このディレクティブは (mod_include
の SSI によって)
インクルードされたファイルがエラーコードを取得して、正しく動作を
するようにもします (デフォルトの動作は、プロキシされたサーバの
エラーページの表示で、このディレクティブを有効にすると SSI のエラー
メッセージを表示します)。
このディレクティブは informational (1xx), 成功 (2xx), リダイレクト (3xx) ステータスのレスポンス処理には影響しません。
説明: | プロキシされた FTP (の一覧表示) のキャラクタセットを定義 |
---|---|
構文: | ProxyFtpDirCharset character set |
デフォルト: | ProxyFtpDirCharset ISO-8859-1 |
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.2.7 以降で使用可能 |
ProxyFtpDirCharset
ディレクティブは、
mod_proxy_ftp
が HTML 形式で生成する FTP のディレクトリ一覧
画面のキャラクタセットを定義します。
説明: | 内部データスループットバッファのサイズを決定する |
---|---|
構文: | ProxyIOBufferSize bytes |
デフォルト: | ProxyIOBufferSize 8192 |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
ProxyIOBufferSize
ディレクティブは入力と
出力用の一時メモリとして使われる内部バッファのサイズを調整します。
サイズは 8192
以下でなければなりません。
ほとんどすべての場合、この値を変更する理由はありません。
説明: | 正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ |
---|---|
構文: | <ProxyMatch regex> ...</ProxyMatch> |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
<ProxyMatch>
は URL のマッチに
正規表現 を用いることを除けば
<Proxy>
ディレクティブと同じです。
説明: | リクエストがフォワードされるプロキシの最大数 |
---|---|
構文: | 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 準拠の動作になります。しかし、これは無限ループの危険性を残します。
説明: | リモートサーバをローカルサーバの 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
と
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 に指示して、 初期およびその後の 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
ディレクティブを参照してください。
説明: | リバースプロキシ設定内での環境変数の使用を有効にする |
---|---|
構文: | 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 オプションがセットされていれば)
必要にならない限り、このディレクティブは無効にしてください。 (サーバのパフォーマンスのため)
説明: | 正規表現を使ってリモートサーバをローカルサーバの 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 のうち、スキームとホスト名 の部分をそれぞれ確実に固定してください。そうでないと、クライアントに不当な影響を 与えかねません。
説明: | リバースプロキシされたサーバから送られた 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>
セクション内では使えません。
説明: | リバースプロキシサーバからの Set-Cookie ヘッダの Domain 文字列を 調整する |
---|---|
構文: | ProxyPassReverseCookieDomain internal-domain
public-domain [interpolate] |
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
ステータス: | Extension |
モジュール: | mod_proxy |
使用法は基本的に
ProxyPassReverse
と同じですが、
ヘッダの URL の代わりに Set-Cookie
ヘッダ内の
domain
文字列を書き換えます。
説明: | リバースプロキシサーバからの 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/
に書き換えます。
説明: | プロキシリクエストに、受け付けた Host HTTP ヘッダを使う |
---|---|
構文: | ProxyPreserveHost On|Off |
デフォルト: | ProxyPreserveHost Off |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.0.31 以降で使用可能 |
このオプションが有効になっている場合、ProxyPass
で指定したホスト名の代わりに、受け付けたリクエストの Host: 行を
プロキシ先のホストに送ります。
このオプションは通常は Off
に設定してください。
ほとんどの場合、これは大量の名前ベースのバーチャルホスティングを行なっていて、
元々の Host ヘッダをバックエンドサーバが解釈する必要のあるときのような、
特別な設定が必要な場合にのみ有用です。
説明: | プロキシされる HTTP と FTP 接続のためのネットワークバッファサイズ |
---|---|
構文: | ProxyReceiveBufferSize bytes |
デフォルト: | ProxyReceiveBufferSize 0 |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
ProxyReceiveBufferSize
ディレクティブは
スループットを上げるために明示的に (TCP/IP) ネットワークバッファのサイズを
設定します。値は 512
以上か、システムのデフォルトのバッファ
サイズを意味する 0
でなければなりません。
ProxyReceiveBufferSize 2048
説明: | 特定のリクエストを扱う時に使われるリモートプロキシを指定する |
---|---|
構文: | 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 空間に入れることが できます。
説明: | 正規表現でのマッチによるリクエストを扱うリモートプロキシの指定 |
---|---|
構文: | ProxyRemoteMatch regex remote-server |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
ProxyRemoteMatch
は最初の引数がリクエストされた
URL にマッチする正規表現であることを除けば ProxyRemote
ディレクティブと同じです。
説明: | フォワード (標準の) プロキシリクエストを有効にする |
---|---|
構文: | ProxyRequests On|Off |
デフォルト: | ProxyRequests Off |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
これは Apache のフォワードプロキシサーバとしての動作を
有効もしくは無効にします。(ProxyRequests を Off
に
設定しても、ProxyPass
の設定は無効になりません。)
通常のリバースプロキシ/ゲートウェイの設定では、このオプションは Off
に設定してください。
HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、
mod_proxy_http
や mod_proxy_ftp
が
サーバに組み込まれていなければなりません。
サーバを安全にするまで ProxyRequests
は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。
説明: | プロキシのバランサやメンバのパラメータをセット |
---|---|
構文: | 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
設定対象がバランサかワーカーかで、パラメータ名が同じでも意味が異なる可能性 に注意してください。例えば、タイムアウトに関連する上記ふたつの例がそうです。
説明: | mod_status でプロキシのロードバランサの状態を表示 |
---|---|
構文: | ProxyStatus Off|On|Full |
デフォルト: | ProxyStatus Off |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.2 以降で使用可能 |
このディレクティブは mod_status
によるサーバステータスのページ
にプロキシのロードバランサの状態を表示するか否かを決めます。
Full は On の別名です。
説明: | プロキシされたリクエストのネットワークタイムアウト |
---|---|
構文: | ProxyTimeout seconds |
デフォルト: |
|
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.0.31 以降で使用可能 |
このディレクティブはユーザがプロキシリクエストのタイムアウトを 指定できるようにします。これはハングしてしまうほど遅い、もしくは挙動の 怪しいサーバがあり、サーバがデータを返すまでひたすら待ち続けるよりも タイムアウトを返してより緩やかに(訳注: graceful に) 失敗させたい場合に役に立ちます。
説明: | プロキシされたリクエストの Via HTTP レスポンスヘッダ
により提供される情報 |
---|---|
構文: | ProxyVia On|Off|Full|Block |
デフォルト: | ProxyVia Off |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
このディレクティブはプロキシの Via:
HTTP ヘッダの使用を
制御します。想定されている使い方は、プロキシサーバがいくつも繋がっているときに
プロキシリクエストの流れを制御することです。Via:
ヘッダ行の
説明は RFC 2616 (HTTP/1.1)
の 14.45 節を読んでください。
Off
に設定されていると、特別な処理は
行なわれません。リクエストやリプライに Via:
ヘッダがあれば、
変更されずにそのまま渡します。On
に設定されていれば、各リクエストとリプライに
Via:
行が追加されます。Full
に設定されていれば、Via:
ヘッダは
コメント部分に Apache サーバのバージョンも含むようになります。Block
に設定されていれば、すべてのプロキシリクエストから
Via:
ヘッダが取り除かれます。新たに Via:
が
生成されることはありません。