Apache HTTP サーバ バージョン 2.4
Apache モジュール mod_proxy
この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。
| 説明: | 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
の説明を読んでください。
フォワードプロキシ
ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Deny from all
Allow from internal.example.com
</Proxy>
リバースプロキシ
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar
プロキシへのアクセス制御 ¶
プロキシのアクセスは以下のように <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 を設定すると、リソース消費を抑え、
chnked エンコードを使って送信するようになります。
BalancerGrowth ディレクティブ ¶
| 説明: | Number of additional Balancers that can be added Post-configuration |
|---|---|
| 構文: | BalancerGrowth # |
| デフォルト: | BalancerGrowth 5 |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | BalancerGrowth is only available in Apache HTTP Server 2.3.13 and later. |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
BalancerInherit ディレクティブ ¶
| 説明: | Inherit ProxyPassed Balancers/Workers from the main server |
|---|---|
| 構文: | BalancerInherit On|Off |
| デフォルト: | BalancerInherit On |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | BalancerInherit is only available in Apache HTTP Server 2.4.5 and later. |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
BalancerMember ディレクティブ ¶
| 説明: | Add a member to a load balancing group |
|---|---|
| 構文: | |
| コンテキスト: | ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
Documentation not yet translated. Please see English version of document.
BalancerPersist ディレクティブ ¶
| 説明: | Attempt to persist changes made by the Balancer Manager across restarts. |
|---|---|
| 構文: | BalancerPersist On|Off |
| デフォルト: | BalancerPersist Off |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | BalancerPersist is only available in Apache HTTP Server 2.4.4 and later. |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
NoProxy ディレクティブ ¶
| 説明: | 直接接続する ホスト、ドメイン、ネットワーク |
|---|---|
| 構文: | NoProxy host [host] ... |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
このディレクティブはイントラネット中の Apache プロキシサーバにのみ
有用です。NoProxy ディレクティブは空白区切りで、
サブネット、IP アドレス、ホスト、ドメインのリストを指定します。
これらのどれかにマッチするホストへのリクエストは ProxyRemote で設定されたプロキシサーバに
フォワードされず、直接処理されます。
例
ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
NoProxy ディレクティブの host 引数は
以下の種類のどれかです:
- Domain
-
Domain は先頭にピリオドの着いた部分 DNS ドメイン名です。 同一 DNS ドメイン及びゾーン (すなわち、ホスト名の末尾がすべて Domain で終わっているということ) に属するホストのリストを 表します)。
Domain を Hostname と区別するために (意味的にも構文的にも。DNS ドメインも DNS の A レコードを持つことができるのです!)、Domain は 常にピリオドで始まります。
注
ドメイン名の比較は大文字小文字を区別せずに行なわれ、Domain は常に DNS ツリーのルートから始まるものとみなされます。ですから、 次の二つのドメイン
.MyDomain.comと.mydomain.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 ドメイン名があるわけでは ありません。
注
IPAddr は DNS システムにより解決される必要がないので、 apache の性能が向上するかもしれません。
- Hostname
-
Hostname は DNS ドメインサービスにより一つもしくは 複数の IPAddr に解決可能な 完全な DNS ドメイン名です。これは (Domain と違って、説明は上記を参照) 論理的なホストを表し、少くとも一つの IPAddr (もしくは違う IPAddr のホストのリスト) に解決 されなければなりません)。
例
prep.ai.mit.edu
www.apache.org注
多くの場合、Hostname の代わりに IPAddr を指定した方が、DNS ルックアップを 避けることができるため、効率が良くなります。Apache の名前解決は ネームサーバへの接続が遅い PPP 上の場合などにかなり時間を取られる ことがあります。
Hostname の比較は大文字小文字を区別せずに行なわれ、 Hostname は常に DNS ツリーのルートから始まるものとみなされます。 ですから、二つのドメイン
WWW.MyDomain.comとwww.mydomain.com.(最後のピリオドに注目) は同一であると みなされます。
参照
<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>
Proxy100Continue ディレクティブ ¶
| 説明: | Forward 100-continue expectation to the origin server |
|---|---|
| 構文: | Proxy100Continue Off|On |
| デフォルト: | Proxy100Continue On |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | Available in version 2.4.40 and later |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
| 説明: | Add proxy information in X-Forwarded-* headers |
|---|---|
| 構文: | ProxyAddHeaders Off|On |
| デフォルト: | ProxyAddHeaders On |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | Available in version 2.3.10 and later |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
| 説明: | 応答におかしなヘッダがある場合の扱い方を決める |
|---|---|
| 構文: | ProxyBadHeader IsError|Ignore|StartBody |
| デフォルト: | ProxyBadHeader IsError |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | 2.0.44 以降 |
ProxyBadHeader ディレクティブは構文的に
間違ったヘッダ (つまり コロンを含まないもの) を受け取ったときに
mod_proxy がどう振る舞うかを決めます。以下の引数を
取ることができます:
IsError- リクエストを中止して 502 (Bad Gateway) 応答を返す。 これがデフォルトの動作です。
Ignore- 間違ったヘッダ行をそもそも存在しなかったものとして扱う。
StartBody- 間違ったヘッダ行を受け取ったら、ヘッダの読み込みを終了して、 それ以降の残りをボディとして扱う。これはヘッダとボディの間に空行を入れ忘れて しまっているような、きちんと動作していないバックエンドサーバがあるときに、 問題を回避するのに役に立ちます。
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 *
はすべてのサイトへの接続をブロックすることに注意してください。
ProxyDomain ディレクティブ ¶
| 説明: | プロキシされたリクエストのデフォルトのドメイン名 |
|---|---|
| 構文: | ProxyDomain Domain |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
このディレクティブはイントラネット内の Apache プロキシサーバにのみ
有用です。ProxyDomain ディレクティブは
apache プロキシサーバが属するデフォルトのドメインを指定します。
ドメイン名の無いリクエストを受けた場合、設定された Domain
が追加された同じホストへのリダイレクト応答が返されます。
例
ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
ProxyDomain .mycompany.com
ProxyErrorOverride ディレクティブ ¶
| 説明: | プロキシされたコンテンツのエラーページを上書きする |
|---|---|
| 構文: | ProxyErrorOverride On|Off |
| デフォルト: | ProxyErrorOverride Off |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | バージョン 2.0 以降で使用可能 |
このディレクティブはリバースプロキシを使用していて、
エンドユーザに送られるエラーページの外見を共通のものにしたいときに
有用です。このディレクティブは (mod_include の SSI によって)
インクルードされたファイルがエラーコードを取得して、正しく動作を
するようにもします (デフォルトの動作は、プロキシされたサーバの
エラーページの表示で、このディレクティブを有効にすると SSI のエラー
メッセージを表示します)。
ProxyIOBufferSize ディレクティブ ¶
| 説明: | 内部データスループットバッファのサイズを決定する |
|---|---|
| 構文: | ProxyIOBufferSize bytes |
| デフォルト: | ProxyIOBufferSize 8192 |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
ProxyIOBufferSize ディレクティブは入力と
出力用の一時メモリとして使われる内部バッファのサイズを調整します。
サイズは 8192 以下でなければなりません。
ほとんどすべての場合、この値を変更する理由はありません。
<ProxyMatch> ディレクティブ ¶
| 説明: | 正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ |
|---|---|
| 構文: | <ProxyMatch regex> ...</ProxyMatch> |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
<ProxyMatch> は URL のマッチに
正規表現 を用いることを除いて
<Proxy> ディレクティブと同じです。
ProxyMaxForwards ディレクティブ ¶
| 説明: | リクエストがフォワードされるプロキシの最大数 |
|---|---|
| 構文: | ProxyMaxForwards number |
| デフォルト: | ProxyMaxForwards 10 |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | Apache 2.0 以降で使用可能 |
ProxyMaxForwards ディレクティブは
リクエストに Max-Forwards ヘッダが指定されていない場合に
リクエストが通過可能なプロキシの最大数を設定します。これは
プロキシの無限ループや DoS 攻撃を防ぐために設定されています。
ProxyPass ディレクティブ ¶
| 説明: | リモートサーバをローカルサーバの URL 空間にマップする |
|---|---|
| 構文: | ProxyPass [path] !|url [key=value key=value ...]] |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | 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
ディレクティブの前に
除外ディレクティブを置く必要があります。
2.1 の機能で、バックエンドサーバとの接続にプールされたコネクションを
使えるようになりました。key=value 形式のパラメータで
このコネクションプーリングの調整ができます。Hard Maximum
のデフォルト値は、有効になっている MPM でのプロセス当たりのスレッド数と
同じ数のコネクション数です。prefork MPM では通常は 1 で、worker MPM では
ThreadsPerChild で調整されます。
min の設定で、バックエンドサーバとの間に何本のコネクションを
常時開くかが決まります。Soft Maximum smax の数に
達するまで必要に応じてコネクションは生成されます。smax
を超えた数のコネクションは、生存時間 ttl で切断されます。
バックエンドサーバと Hard Maximum max の数以上のコネクションを
生成することはありません。
ProxyPass /example http://backend.example.com smax=5 max=20 ttl=120 retry=300
| パラメータ | デフォルト値 | 説明 |
|---|---|---|
| min | 0 | バックエンドサーバとの接続で 常に開いているコネクション数の最小値 |
| max | 1...n | バックエンドサーバとの接続数の Hard Maximum
(訳注: ハードリミット)。
デフォルト値は、使用している MPM のプロセスあたりのスレッド数になっています。
Prefork MPM では常に 1 で、Worker MPM では ThreadsPerChild
で調節できます。Hard Maximum 以上にバックエンドサーバとのコネクションを
生成することはありません。 |
| smax | max | 接続数の Soft Maximum (訳注: ソフトリミット)まで、
コネクションは必要に応じて生成されます。
smax を超えた数のコネクションは生存時間 ttl
で切断されます。
|
| ttl | - | smax 数を超えた非活動状態のコネクションの生存時間を、
秒で指定します。この期間内に使用されなかったコネクションは、
全て閉じられます。
|
| timeout | Timeout |
コネクションタイムアウトを秒で指定します。特に指定されなければ、
フリーなコネクションを取得できるまで待ちます。このディレクティブは
max パラメータと合わせて使うことで、バックエンドサーバとの
接続数を制御するのに使います。
|
| acquire | - | 設定すると、コネクションプールからフリーのコネクションを取得するために
待機する待ち時間の最大値になります。フリーのコネクションがプールになかった場合は、
SERVER_BUSY ステータスがクライアントに返されます。
|
| keepalive | Off | バックエンドサーバと Apache の間にファイアーウォールがある場合には、
このパラメータを使ってください。ファイアウォールは往々にして、
非活動状態のコネクションを落とそうとします。
このフラグは OS に指示して、KEEP_ALIVE メッセージを非活動状態の
コネクションでも送るようにします (間隔は OS のグローバル設定に依存し、
通常は 120ms 間隔) 。これによってファイアウォールによってコネクションが
落とされることを防げます。keepalive を有効にするには、このプロパティを
On にしてください。
|
| retry | 60 | コネクションをプーリングするための、リトライのタイムアウトを秒で 指定します。バックエンドサーバへのコネクションプーリングが失敗した場合は、 タイムアウトの期間が過ぎるまで、そのサーバにリクエストをフォワードしません。 この機能を使うと、バックエンドサーバをメンテナンスのためにシャットダウンし、 後でオンラインに復帰させるといったことができます。 |
| loadfactor | 1 | ワーカーあたりの負荷係数です。BalancerMember で使います。 1 から 100 までの数字でそのワーカーに対する正規化された負荷率を指定します。 |
| route | - | ロードバランサで使った場合、ワーカーのルーティングをします。 ルートはセッション ID に付加された値になります。 |
| redirect | - | ワーカーのリダイレクション経路です。この値は通常は、 安全にクラスタからノードを取り去る設定を動的に入れるために使います。 セッション ID の無いリクエスト全てを指定した場合は、 この値と同じルーティングパラメータを持つ BalancerMember にリダイレクトされます。 |
Proxy ディレクティブのスキームが balancer:// になっている場合は、
バックエンドサーバと実際には通信しない仮想ワーカーが生成されます。
このワーカーは幾つかの "本物の" ワーカーの管理をつかさどります。
この場合パラメータは、この仮想ワーカーに対して設定されます。
| パラメータ | デフォルト値 | 説明 |
|---|---|---|
| lbmethod | - | Balancer のロードバランス方法。使用するロードバランスの
スケジューリング方法を選びます。処理したリクエストの数で重み付けする
byrequests か、転送量のバイト数で重み付けする
bytraffic を設定できます。デフォルトは
byrequests です。
|
| stickysession | - | バランサーのスティッキーセッション名です。通常はこの値は JSESSIONID
や PHPSESSIONID といったものになりますが、この値は
バックエンドアプリケーションのサポートするセッションに依存します。
|
| nofailover | Off | On になっていると、ワーカーがエラーを起こしたり
無効になっている場合にセッションが切れます。
バックエンドサーバがセッションレプリケーションをサポートしていない場合は、
On にしてください。
|
| timeout | 0 | バランサーのタイムアウトを秒で指定します。 この値を設定すると、フリーのワーカーを取得するまでの最大待機時間になります。 デフォルトでは待機しません。 |
| maxattempts | 1 | フェイルオーバーを試みる最大の回数を指定します。 |
ProxyPass /special-area http://special.example.com/ smax=5 max=10
ProxyPass / balancer://mycluster stickysession=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
</Proxy>
<Location> セクションの中で使われた場合、最初の引数は
省略され、ローカルディレクトリは <Location> から取得されます。
より柔軟なリバースプロキシの設定が必要な場合は、[P]
フラグ付きの RewriteRule
ディレクティブを参照してください。
ProxyPassInherit ディレクティブ ¶
| 説明: | Inherit ProxyPass directives defined from the main server |
|---|---|
| 構文: | ProxyPassInherit On|Off |
| デフォルト: | ProxyPassInherit On |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | ProxyPassInherit is only available in Apache HTTP Server 2.4.5 and later. |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
ProxyPassInterpolateEnv ディレクティブ ¶
| 説明: | Enable Environment Variable interpolation in Reverse Proxy configurations |
|---|---|
| 構文: | |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
Documentation not yet translated. Please see English version of document.
ProxyPassMatch ディレクティブ ¶
| 説明: | Maps remote servers into the local server URL-space using regular expressions |
|---|---|
| 構文: | |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
Documentation not yet translated. Please see English version of document.
ProxyPassReverse ディレクティブ ¶
| 説明: | リバースプロキシされたサーバから送られた HTTP 応答ヘッダの URL を調整する |
|---|---|
| 構文: | ProxyPassReverse [path] url |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
このディレクティブは Apache に HTTP リダイレクト応答の
Location, Content-Location, URI
ヘッダの調整をさせます。これは、Apache がリバースプロキシとして使われている
ときに、リバースプロキシを通さないでアクセスすることを防ぐために
重要です。これによりバックエンドサーバの HTTP リダイレクトが
リバースプロキシとバックエンドの間で扱われるようになります。
ディレクティブで明示されている HTTP 応答ヘッダのみが書き換えられます。 Apache は他の応答ヘッダを書き換えたり、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]) と併せて使用することができます。
<Location> セクションの中で使われた場合は、
最初の引数は省略され、ローカルディレクトリは <Location> から取得されます。
ProxyPassReverseCookieDomain ディレクティブ ¶
| 説明: | リバースプロキシサーバからの Set-Cookie ヘッダの Domain 文字列を 調整する |
|---|---|
| 構文: | ProxyPassReverseCookieDomain internal-domain public-domain |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
使用法は基本的に
ProxyPassReverse と同じですが、
ヘッダの URL の代わりに Set-Cookie ヘッダの
domain 文字列を書き換えます。
ProxyPassReverseCookiePath ディレクティブ ¶
| 説明: | Reverse プロキシサーバからの Set-Cookie ヘッダの Path 文字列を 調整する |
|---|---|
| 構文: | ProxyPassReverseCookiePath internal-path public-path |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
使用法は基本的に
ProxyPassReverse と同じですが、
ヘッダの URL の代わりに Set-Cookie ヘッダの
path 文字列を書き換えます。
ProxyPreserveHost ディレクティブ ¶
| 説明: | プロキシリクエストに、受け付けた Host HTTP ヘッダを使う |
|---|---|
| 構文: | ProxyPreserveHost On|Off |
| デフォルト: | ProxyPreserveHost Off |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | Apache 2.0.31 以降で使用可能 |
このオプションが有効になっている場合、ProxyPass
で指定したホスト名の代わりに、受け付けたリクエストの Host: 行を
プロキシ先のホストに送ります。
このオプションは通常は Off に設定してください。
ほとんどの場合、これは大量の名前ベースのバーチャルホスティングを行なっていて、
元々の Host ヘッダをバックエンドサーバが解釈する必要のあるときのような、
特別な設定が必要な場合にのみ有用です。
ProxyReceiveBufferSize ディレクティブ ¶
| 説明: | プロキシされる HTTP と FTP 接続のためのネットワークバッファサイズ |
|---|---|
| 構文: | ProxyReceiveBufferSize bytes |
| デフォルト: | ProxyReceiveBufferSize 0 |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
ProxyReceiveBufferSize ディレクティブは
スループットを上げるために明示的に (TCP/IP) ネットワークバッファのサイズを
設定します。値は 512 以上か、システムのデフォルトのバッファ
サイズを意味する 0 でなければなりません。
例
ProxyReceiveBufferSize 2048
ProxyRemote ディレクティブ ¶
| 説明: | 特定のリクエストを扱う時に使われるリモートプロキシを指定する |
|---|---|
| 構文: | ProxyRemote match remote-server |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
このディレクティブはこのプロキシに対するリモートプロキシを定義します。
match はリモートサーバがサポートする URL スキーム、
リモートサーバが使うはずの URL の一部分、サーバがすべての
リクエストに使われることを示す * のどれかになります。
remote-server はリモートサーバの部分 URL です。構文:
remote-server =
scheme://hostname[:port]
scheme は実際上リモートサーバとの通信に使われるプロトコルを
決定します。このモジュールでは http だけがサポートされて
います。
例
ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
ProxyRemote * http://cleversite.com
ProxyRemote ftp http://ftpproxy.mydomain.com:8080
この例では、プロキシは FTP リクエストを別の HTTP リクエストで包んで そのようなリクエストを扱える別のプロキシに転送します。
このオプションはリバースプロキシの設定もサポートします。 サーバが別のフォワードプロキシの後ろに隠されている場合でも バックエンドウェブサーバをバーチャルホストの URL 空間に入れることが できます。
ProxyRemoteMatch ディレクティブ ¶
| 説明: | 正規表現でのマッチによるリクエストを扱うリモートプロキシの指定 |
|---|---|
| 構文: | ProxyRemoteMatch regex remote-server |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
ProxyRemoteMatch は最初の引数がリクエストされた
URL にマッチする正規表現であることを除けば ProxyRemote ディレクティブと同じです。
ProxyRequests ディレクティブ ¶
| 説明: | フォワード (標準の) プロキシリクエストを有効にする |
|---|---|
| 構文: | ProxyRequests On|Off |
| デフォルト: | ProxyRequests Off |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
これは Apache のフォワードプロキシサーバとしての動作を
有効もしくは無効にします。(ProxyRequests を Off に
設定しても、ProxyPass
の設定は無効になりません。)
通常のリバースプロキシの設定では、このオプションは Off
に設定してください。
HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、
mod_proxy_http や mod_proxy_ftp が
サーバに組み込まれていなければなりません。
警告
サーバを安全にするまで ProxyRequests は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。
ProxySet ディレクティブ ¶
| 説明: | Set various Proxy balancer or member parameters |
|---|---|
| 構文: | |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ |
| ステータス: | Extension |
| モジュール: | mod_proxy |
Documentation not yet translated. Please see English version of document.
ProxySourceAddress ディレクティブ ¶
| 説明: | Set local IP address for outgoing proxy connections |
|---|---|
| 構文: | ProxySourceAddress address |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | Available in version 2.3.9 and later |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
ProxyStatus ディレクティブ ¶
| 説明: | Show Proxy LoadBalancer status in mod_status |
|---|---|
| 構文: | |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
Documentation not yet translated. Please see English version of document.
ProxyTimeout ディレクティブ ¶
| 説明: | プロキシされたリクエストのネットワークタイムアウト |
|---|---|
| 構文: | ProxyTimeout seconds |
| デフォルト: | ProxyTimeout 300 |
| コンテキスト: | サーバ設定ファイル, バーチャルホスト |
| ステータス: | Extension |
| モジュール: | mod_proxy |
| 互換性: | Apache 2.0.31 以降で使用可能 |
このディレクティブはユーザがプロキシリクエストのタイムアウトを 指定できるようにします。これはハングしてしまう遅い、もしくは挙動の 怪しいサーバがあり、サーバがデータを返すまでひたすら待ち続けるよりも タイムアウトを返してより緩やかに(訳注: graceful に) 失敗させたい場合に役に立ちます。
ProxyVia ディレクティブ ¶
| 説明: | プロキシされたリクエストの 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:が 生成されることはありません。