警告

mod_proxy HTTP/1.1 プロキシ/ゲートウェイサーバ Extension mod_proxy.c proxy_module

警告

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

mod_cache mod_proxy_http mod_proxy_ftp mod_proxy_connect mod_proxy_balancer mod_ssl

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

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 エンコードを使って送信するようになります。

BalancerMember Add a member to a load balancing group directory

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

Proxy プロキシされるリソースに適用されるコンテナ <Proxy wildcard-url> ...</Proxy> server configvirtual host

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|StartBody ProxyBadHeader IsError server configvirtual host 2.0.44 以降

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

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

ProxyMatch 正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ <ProxyMatch regex> ...</ProxyMatch> server configvirtual host

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

ProxyPreserveHost プロキシリクエストに、受け付けた Host HTTP ヘッダを使う ProxyPreserveHost On|Off ProxyPreserveHost Off server configvirtual host Apache 2.0.31 以降で使用可能

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

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

ProxyRequests フォワード (標準の) プロキシリクエストを有効にする ProxyRequests On|Off ProxyRequests Off server configvirtual host

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

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

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

警告

ProxyRemote 特定のリクエストを扱う時に使われるリモートプロキシを指定する ProxyRemote match remote-server server configvirtual host

このディレクティブはこのプロキシに対するリモートプロキシを定義します。 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 server configvirtual host

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

ProxySet Set various Proxy balancer or member parameters directory

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

ProxyStatus Show Proxy LoadBalancer status in mod_status server configvirtual host

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

ProxyPass リモートサーバをローカルサーバの URL 空間にマップする ProxyPass [path] !|url [key=value key=value ...]] server configvirtual host directory

このディレクティブはリモートサーバをローカルサーバの名前空間にマップできるようにします。ローカルサーバは通常の意味でのプロキシとしては動作せず、リモートサーバのミラーとして振る舞います。 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 ディレクティブを参照してください。

ProxyPassInterpolateEnv Enable Environment Variable interpolation in Reverse Proxy configurations server configvirtual hostdirectory

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

ProxyPassMatch Maps remote servers into the local server URL-space using regular expressions server configvirtual hostdirectory

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

ProxyPassReverse リバースプロキシされたサーバから送られた HTTP 応答ヘッダの URL を調整する ProxyPassReverse [path] url server configvirtual host directory

このディレクティブは 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 server configvirtual host directory

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

ProxyPassReverseCookiePath Reverse プロキシサーバからの Set-Cookie ヘッダの Path 文字列を調整する ProxyPassReverseCookiePath internal-path public-path server configvirtual host directory

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

AllowCONNECT プロキシを経由して、どのポートに CONNECT できるかを指定する AllowCONNECT port [port] ... AllowCONNECT 443 563 server configvirtual host

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

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

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

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 *

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

ProxyReceiveBufferSize プロキシされる HTTP と FTP 接続のためのネットワークバッファサイズ ProxyReceiveBufferSize bytes ProxyReceiveBufferSize 0 server configvirtual host

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

例 ProxyReceiveBufferSize 2048 ProxyIOBufferSize 内部データスループットバッファのサイズを決定する ProxyIOBufferSize bytes ProxyIOBufferSize 8192 server configvirtual host

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

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

ProxyMaxForwards リクエストがフォワードされるプロキシの最大数 ProxyMaxForwards number ProxyMaxForwards 10 server configvirtual host Apache 2.0 以降で使用可能

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

例 ProxyMaxForwards 15 NoProxy 直接接続するホスト、ドメイン、ネットワーク NoProxy host [host] ... server configvirtual host

このディレクティブはイントラネット中の 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.

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 ドメイン名があるわけではありません。

例 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.com と www.mydomain.com. (最後のピリオドに注目) は同一であるとみなされます。

DNS に関する問題 ProxyTimeout プロキシされたリクエストのネットワークタイムアウト ProxyTimeout seconds ProxyTimeout 300 server configvirtual host Apache 2.0.31 以降で使用可能

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

ProxyDomain プロキシされたリクエストのデフォルトのドメイン名 ProxyDomain Domain server configvirtual host

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

例 ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
ProxyDomain .mycompany.com ProxyVia プロキシされたリクエストの Via HTTP 応答ヘッダにより提供される情報 ProxyVia On|Off|Full|Block ProxyVia Off server configvirtual host

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

デフォルトの Off に設定されていると、特別な処理は行なわれません。リクエストやリプライに Via: ヘッダがあれば、変更されずにそのまま渡します。
On に設定されていれば、各リクエストとリプライに Via: 行が追加されます。
Full に設定されていれば、Via: ヘッダはコメント部分に Apache サーバのバージョンも含むようになります。
Block に設定されていれば、すべてのプロキシリクエストから Via: ヘッダが取り除かれます。新たに Via: が生成されることはありません。

ProxyErrorOverride プロキシされたコンテンツのエラーページを上書きする ProxyErrorOverride On|Off ProxyErrorOverride Off server configvirtual host バージョン 2.0 以降で使用可能

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