Apache HTTP サーバ バージョン 2.4 (original) (raw)
Apache モジュール mod_proxy
この日本語訳はすでに古くなっている 可能性があります。 最近更新された内容を見るには英語版をご覧下さい。
説明: | HTTP/1.1 プロキシ/ゲートウェイサーバ |
---|---|
ステータス: | Extension |
モジュール識別子: | proxy_module |
ソースファイル: | mod_proxy.c |
概要
警告
サーバを安全にするまで [ProxyRequests](#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/mod%5Fproxy.html)
の他に、 いくつかのモジュールに分割されています:[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html)
, [mod_proxy_ftp](../mod/mod%5Fproxy%5Fftp.html)
,[mod_proxy_ajp](../mod/mod%5Fproxy%5Fajp.html)
, [mod_proxy_balancer](../mod/mod%5Fproxy%5Fbalancer.html)
, [mod_proxy_connect](../mod/mod%5Fproxy%5Fconnect.html)
です。ですから、 特定のプロキシの機能を使いたい場合は、[mod_proxy](../mod/mod%5Fproxy.html)
と 該当するモジュールをサーバに (コンパイル時に静的に行なうか[LoadModule](../mod/mod%5Fso.html#loadmodule)
で動的に読み込むかして) 組み込む必要があります。
これに加えて、他のモジュールによって拡張機能が提供されています。 キャッシュは [mod_cache](../mod/mod%5Fcache.html)
と関連モジュールで 提供されています。SSL/TLS で遠隔サーバに接続する機能は[mod_ssl](../mod/mod%5Fssl.html)
の SSLProxy*
ディレクティブで 提供されています。これらの機能を利用するためには、該当するモジュールを 組み込んで設定しなければなりません。
フォワードプロキシとリバースプロキシ
Apache はフォワードプロキシとしても、リバースプロキシとしても設定することができます。
通常のフォワードプロキシはクライアントと_オリジンサーバ_ (訳注: コンテンツ生成元のサーバ) の間に位置する中間サーバです。 オリジンサーバからコンテンツを取得する過程では、クライアントは 行き先としてオリジンサーバを指定しつつプロキシにリクエストを送り、 プロキシはオリジンサーバからコンテンツ取得のリクエストを送り、 コンテンツが取得できればそれをクライアントに返します。 クライアントが他のサイトにフォワードプロクシ経由でアクセスするには、 特別にそれ用の設定をしなければなりません。
フォワードプロキシの一般的な使用方法は、ファイアウォールによって 制限されている内部のクライアントにインターネットへのアクセスを 提供するものです。フォワードプロキシはネットワークの使用量を 減らすために ([mod_cache](../mod/mod%5Fcache.html)
で提供されている) キャッシュ機能を用いることもできます。
フォワードプロキシは [ProxyRequests](#proxyrequests)
ディレクティブで 有効になります。フォワードプロキシでは、クライアントは本当の身元を 隠して任意のサイトにアクセスできるようになるため、フォワードプロキシを 有効にする前に、承認されたクライアントのみがプロキシにアクセスできるようにサーバを安全にすることが重要です。
一方リバースプロキシは、クライアントには普通の ウェブサーバのように見えます。クライアント側に特別な設定は必要ありません。 クライアントはリバースプロキシの名前空間に対して通常のコンテンツへの リクエストを行ないます。プロキシはリクエストをどこに送れば良いかを判定し、 あたかも自分自身がオリジンサーバであったかのようにクライアントに コンテンツを返します。
リバースプロキシのよくある利用方法は、インターネットユーザに ファイアウォールの中にあるサーバにアクセスを与えるというものです。 リバースプロキシは複数のバックエンドサーバへ負荷分散をするために 使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり するために使えます。また、リバースプロキシは複数のサーバを 同じ URL 空間にまとめるために使うこともできます。
リバースプロキシは [ProxyPass](#proxypass)
ディレクティブや[RewriteRule](../mod/mod%5Frewrite.html#rewriterule)
ディレクティブの[P]
フラグを使うことで有効になります。リバースプロキシの 設定のために [ProxyRequests](#proxyrequests)
を設定する必要は_ありません_。
基本の例
以下の例は手始めの簡単な例です。個々のディレクティブの意味は それぞれの説明をお読みください。
またキャッシュ機能を有効にしたい場合は、[mod_cache](../mod/mod%5Fcache.html)
の説明を読んでください。
フォワードプロキシ
` ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Deny from all
Allow from internal.example.com
`
リバースプロキシ
` ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar
`
プロキシへのアクセス制御
プロキシのアクセスは以下のように [<Proxy>](#proxy)
コンテナの中に ディレクティブを書くことで制御できます:
<Proxy *> Order Deny,Allow Deny from all Allow from 192.168.0 </Proxy>
アクセス制御のためのディレクティブのより詳しい情報は[mod_authz_host](../mod/mod%5Fauthz%5Fhost.html)
をお読みください。
([ProxyRequests](#proxyrequests)
ディレクティブを 使って) フォワードプロキシを設定している場合は、厳しくアクセス 制限を行なうことが非常に大切です。そうしないと、任意のクライアントが 身元を明かすことなく任意のホストにアクセスするためにサーバを使うことが できてしまいます。これはあなた自身のネットワークにとっても、インターネット 全体にとっても危険なことです。(ProxyRequests Off
にして[ProxyPass](#proxypass)
ディレクティブを使って) リバースプロキシを使っている場合には、クライアントはあなたが明示的に 設定したホストにしかアクセスできないため、フォワードプロキシのとき ほどアクセス制御に力を注がなくても大丈夫です。
遅い起動
[ProxyBlock](#proxyblock)
ディレクティブを使っている場合、 後のテストのために起動時にホストの IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの 速さによっては、数秒 (かそれ以上) かかるかもしれません。
イントラネットプロキシ
イントラネットにある Apache プロキシサーバは外部へのリクエストを 会社のファイアウォールを通して送らなければなりません。(このためには 個々の scheme についてそれぞれ、ファイアウォールの プロキシにフォワードされるように[ProxyRemote](#proxyremote)
ディレクティブを 設定してください)。しかしイントラネット内のリソースにアクセスするときは、 ファイアウォールを通さないでもアクセスできます。 どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、[NoProxy](#noproxy)
ディレクティブが 役に立ちます。
イントラネット内のユーザは WWW のリクエストでローカルドメインを 省略することがよくあります。http://somehost.example.com/
というリクエストの代わりに "http://somehost/" をリクエストしたりします。 このようなリクエストを受け付け、サーバに設定されているローカルドメインが 暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも 商用プロキシサーバの中にはあります。 サーバが プロキシのサービス用に設定されていて [ProxyDomain](#proxydomain)
ディレクティブが 使用された場合には、Apache はクライアントにリダイレクト応答を送って、 正しい、完全な ((訳注: fully qualified)) サーバのアドレスに送ることができます。このように リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む ことにもなるため、より好ましい方法と言えるでしょう。
プロトコルの調整
Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバに対して[mod_proxy](../mod/mod%5Fproxy.html)
がリクエストを送信する場合、 HTTP/1.0 を使って keepalive を無しにしてリクエストを送るようにする 環境変数が二つあります。これらは [SetEnv](../mod/mod%5Fenv.html#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](../mod/mod%5Fproxy%5Fhttp.html)
は常に 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. |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
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)
で設定されたプロキシサーバに フォワードされず、直接処理されます。
例
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 wildcard-url> ... |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | 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 ディレクティブ
説明: | 応答におかしなヘッダがある場合の扱い方を決める |
---|---|
構文: | ProxyBadHeader IsError|Ignore |
デフォルト: | ProxyBadHeader IsError |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | 2.0.44 以降 |
ProxyBadHeader
ディレクティブは構文的に 間違ったヘッダ (つまり コロンを含まないもの) を受け取ったときに[mod_proxy](../mod/mod%5Fproxy.html)
がどう振る舞うかを決めます。以下の引数を 取ることができます:
IsError
リクエストを中止して 502 (Bad Gateway) 応答を返す。 これがデフォルトの動作です。
Ignore
間違ったヘッダ行をそもそも存在しなかったものとして扱う。
StartBody
間違ったヘッダ行を受け取ったら、ヘッダの読み込みを終了して、 それ以降の残りをボディとして扱う。これはヘッダとボディの間に空行を入れ忘れて しまっているような、きちんと動作していないバックエンドサーバがあるときに、 問題を回避するのに役に立ちます。
ProxyBlock ディレクティブ
説明: | プロキシ接続を禁止する語句、ホスト名、ドメインを指定する |
---|---|
構文: | ProxyBlock *|word |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | 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](../mod/mod%5Finclude.html)
の SSI によって) インクルードされたファイルがエラーコードを取得して、正しく動作を するようにもします (デフォルトの動作は、プロキシされたサーバの エラーページの表示で、このディレクティブを有効にすると SSI のエラー メッセージを表示します)。
ProxyIOBufferSize ディレクティブ
説明: | 内部データスループットバッファのサイズを決定する |
---|---|
構文: | ProxyIOBufferSize bytes |
デフォルト: | ProxyIOBufferSize 8192 |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
ProxyIOBufferSize
ディレクティブは入力と 出力用の一時メモリとして使われる内部バッファのサイズを調整します。 サイズは 8192
以下でなければなりません。
ほとんどすべての場合、この値を変更する理由はありません。
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](#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
`
[<Location>](../mod/core.html#location)
セクションの中で使われた場合、最初の引数は 省略され、ローカルディレクトリは [<Location>](../mod/core.html#location)
から取得されます。
より柔軟なリバースプロキシの設定が必要な場合は、[P]
フラグ付きの [RewriteRule](../mod/mod%5Frewrite.html#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. |
このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。
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](#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](../mod/core.html#usecanonicalname)
の設定に応じて選択されることに 注意してください。
ProxyPassReverse
ディレクティブは 対応する [ProxyPass](#proxypass)
ディレクティブには依存しないため、[mod_rewrite](../mod/mod%5Frewrite.html)
のプロキシ通過機能 (RewriteRule ... [P]
) と併せて使用することができます。
[<Location>](../mod/core.html#location)
セクションの中で使われた場合は、 最初の引数は省略され、ローカルディレクトリは [<Location>](../mod/core.html#location)
から取得されます。
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 空間に入れることが できます。
ProxyRequests ディレクティブ
説明: | フォワード (標準の) プロキシリクエストを有効にする |
---|---|
構文: | ProxyRequests On|Off |
デフォルト: | ProxyRequests Off |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
これは Apache のフォワードプロキシサーバとしての動作を 有効もしくは無効にします。(ProxyRequests を Off
に 設定しても、[ProxyPass](#proxypass)
の設定は無効になりません。)
通常のリバースプロキシの設定では、このオプションは Off
に設定してください。
HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html)
や [mod_proxy_ftp](../mod/mod%5Fproxy%5Fftp.html)
が サーバに組み込まれていなければなりません。
警告
サーバを安全にするまで [ProxyRequests](#proxyrequests)
は有効にしないでください。 オープンプロキシサーバはあなた自身のネットワークにとっても、 インターネット全体にとっても危険です。
ProxyTimeout ディレクティブ
説明: | プロキシされたリクエストのネットワークタイムアウト |
---|---|
構文: | ProxyTimeout seconds |
デフォルト: | ProxyTimeout 300 |
コンテキスト: | サーバ設定ファイル, バーチャルホスト |
ステータス: | Extension |
モジュール: | mod_proxy |
互換性: | Apache 2.0.31 以降で使用可能 |
このディレクティブはユーザがプロキシリクエストのタイムアウトを 指定できるようにします。これはハングしてしまう遅い、もしくは挙動の 怪しいサーバがあり、サーバがデータを返すまでひたすら待ち続けるよりも タイムアウトを返してより緩やかに(訳注: graceful に) 失敗させたい場合に役に立ちます。
ProxyVia ディレクティブ
説明: | プロキシされたリクエストの Via HTTP 応答ヘッダ により提供される情報 |
---|---|
構文: | ProxyVia On|Off |
デフォルト: | 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:
が 生成されることはありません。