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

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_sslSSLProxy* ディレクティブで 提供されています。これらの機能を利用するためには、該当するモジュールを 組み込んで設定しなければなりません。

Support Apache!

トピック

ディレクティブ

Bugfix checklist

参照

top

フォワードプロキシとリバースプロキシ

Apache はフォワードプロキシとしても、 リバースプロキシとしても設定することができます。

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

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

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

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

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

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

top

基本の例

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

またキャッシュ機能を有効にしたい場合は、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

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.0proxy-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 を設定すると、リソース消費を抑え、 chnked エンコードを使って送信するようになります。

top

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.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

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.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

BalancerMember ディレクティブ

説明:Add a member to a load balancing group
構文:
コンテキスト:ディレクトリ
ステータス:Extension
モジュール:mod_proxy

Documentation not yet translated. Please see English version of document.

top

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.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

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 で終わっているということ) に属するホストのリストを 表します)。

.com .apache.org.

DomainHostname と区別するために (意味的にも構文的にも。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 ビット有効な SubNetIPAddr と同等で、 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.mit.edu
www.apache.org

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

Hostname の比較は大文字小文字を区別せずに行なわれ、 Hostname は常に DNS ツリーのルートから始まるものとみなされます。 ですから、二つのドメイン WWW.MyDomain.comwww.mydomain.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.comfoo ディレクトリの すべてのファイルに対して、プロキシサーバを通して送られたときには INCLUDES フィルタを通して送るように設定します:

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

top

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

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

ProxyAddHeaders ディレクティブ

説明:Add proxy information in X-Forwarded-* headers
構文:ProxyAddHeaders Off|On
デフォルト:ProxyAddHeaders On
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy
互換性:Available in version 2.3.10 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

ProxyBadHeader ディレクティブ

説明:応答におかしなヘッダがある場合の扱い方を決める
構文:ProxyBadHeader IsError|Ignore|StartBody
デフォルト:ProxyBadHeader IsError
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性: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.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
ProxyDomain .mycompany.com

top

ProxyErrorOverride ディレクティブ

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

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

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 10
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Apache 2.0 以降で使用可能

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

ProxyMaxForwards 15

top

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 - バランサーのスティッキーセッション名です。通常はこの値は JSESSIONIDPHPSESSIONID といったものになりますが、この値は バックエンドアプリケーションのサポートするセッションに依存します。
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 ディレクティブを参照してください。

top

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.

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

ProxyPassInterpolateEnv ディレクティブ

説明:Enable Environment Variable interpolation in Reverse Proxy configurations
構文:
コンテキスト:サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス:Extension
モジュール:mod_proxy

Documentation not yet translated. Please see English version of document.

top

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.

top

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/barhttp://backend.example.com/quux にリダイレクトされたとき、 Apache は HTTP リダイレクト応答をクライアントに送る前に、 http://example.com/mirror/foo/quux に変更します。 URL を構成するのに使われるホスト名は UseCanonicalName の設定に応じて選択されることに 注意してください。

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

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

top

ProxyPassReverseCookieDomain ディレクティブ

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

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

top

ProxyPassReverseCookiePath ディレクティブ

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

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

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 だけがサポートされて います。

ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
ProxyRemote * http://cleversite.com
ProxyRemote ftp http://ftpproxy.mydomain.com: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_httpmod_proxy_ftp が サーバに組み込まれていなければなりません。

警告

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

top

ProxySet ディレクティブ

説明:Set various Proxy balancer or member parameters
構文:
コンテキスト:ディレクトリ
ステータス:Extension
モジュール:mod_proxy

Documentation not yet translated. Please see English version of document.

top

ProxySourceAddress ディレクティブ

説明:Set local IP address for outgoing proxy connections
構文:ProxySourceAddress address
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy
互換性:Available in version 2.3.9 and later

このディレクティブの解説文書は まだ翻訳されていません。英語版をご覧ください。

top

ProxyStatus ディレクティブ

説明:Show Proxy LoadBalancer status in mod_status
構文:
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス:Extension
モジュール:mod_proxy

Documentation not yet translated. Please see English version of document.

top

ProxyTimeout ディレクティブ

説明:プロキシされたリクエストのネットワークタイムアウト
構文:ProxyTimeout seconds
デフォルト:ProxyTimeout 300
コンテキスト:サーバ設定ファイル, バーチャルホスト
ステータス: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 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 Libera.chat, or sent to our mailing lists.