使ったり、遅いバックエンドエンドサーバのためにキャッシュ機能を提供したり
するために使えます。また、リバースプロキシは複数のサーバを
同じ URL 空間にまとめるために使うこともできます。</
p>
module="mod_proxy">ProxyPass</
directive> ディレクティブや
module="mod_rewrite">RewriteRule</
directive> ディレクティブの
<
code>[P]</
code> フラグを使うことで有効になります。リバースプロキシの
module="mod_proxy">ProxyRequests</
directive> を設定する必要は
</
section>
<!-- /forwardreverse --> <
section id="examples"><
title>基本の例</
title>
<
p>以下の例は手始めの簡単な例です。個々のディレクティブの意味は
<
p>またキャッシュ機能を有効にしたい場合は、<
module>mod_cache</
module>
<
example><
title>フォワードプロキシ</
title>
<
example><
title>リバースプロキシ</
title>
</
section>
<!-- /examples --> <
section id="access"><
title>プロキシへのアクセス制御</
title>
<
p>プロキシのアクセスは以下のように <
directive module="mod_proxy" type="section">Proxy</
directive> コンテナの中に
Allow from 192.168.0<
br />
<
p>アクセス制御のためのディレクティブのより詳しい情報は
<
module>mod_authz_host</
module> をお読みください。</
p>
module="mod_proxy">ProxyRequests</
directive> ディレクティブを
使って) フォワードプロキシを設定している場合は、厳しくアクセス
制限を行なうことが非常に大切です。そうしないと、任意のクライアントが
身元を明かすことなく任意のホストにアクセスするためにサーバを使うことが
できてしまいます。これはあなた自身のネットワークにとっても、インターネット
全体にとっても危険なことです。(<
code>ProxyRequests Off</
code> にして
module="mod_proxy">ProxyPass</
directive> ディレクティブを使って)
リバースプロキシを使っている場合には、クライアントはあなたが明示的に
設定したホストにしかアクセスできないため、フォワードプロキシのとき
ほどアクセス制御に力を注がなくても大丈夫です。</
p>
</
section>
<!-- /access --> <
section id="startup"><
title>遅い起動</
title>
<
p><
directive module="mod_proxy" >ProxyBlock</
directive> ディレクティブを使っている場合、
IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの
速さによっては、数秒 (かそれ以上) かかるかもしれません。</
p>
</
section>
<!-- /startup --> <
section id="intranet"><
title>イントラネットプロキシ</
title>
<
p>イントラネットにある Apache プロキシサーバは外部へのリクエストを
会社のファイアウォールを通して送らなければなりません。(このためには
個々の <
var>scheme</
var> についてそれぞれ、ファイアウォールの
<
directive module="mod_proxy">ProxyRemote</
directive> ディレクティブを
設定してください)。しかしイントラネット内のリソースにアクセスするときは、
どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、
<
directive module="mod_proxy">NoProxy</
directive> ディレクティブが
<
p>イントラネット内のユーザは WWW のリクエストでローカルドメインを
このようなリクエストを受け付け、サーバに設定されているローカルドメインが
暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも
href="#proxyrequests">プロキシのサービス用に設定されていて</
a>
<
directive module="mod_proxy">ProxyDomain</
directive> ディレクティブが
使用された場合には、Apache はクライアントにリダイレクト応答を送って、
正しい、完全な (<
transnote>fully qualified</
transnote>)
リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む
ことにもなるため、より好ましい方法と言えるでしょう。</
p>
</
section>
<!-- /intranet --> <
section id="envsettings"><
title>プロトコルの調整</
title>
<
p>Keepalive や
HTTP/
1.1 を適切に実装していないアプリケーションサーバに対して
<
module>mod_proxy</
module> がリクエストを送信する場合、
HTTP/
1.0 を使って keepalive を無しにしてリクエストを送るようにする
環境変数が二つあります。これらは <
directive module="mod_env" >SetEnv</
directive> ディレクティブで設定します。</
p>
<
p><
code>force-proxy-request-1.0</
code> と <
code>proxy-nokeepalive</
code>
<Location /buggyappserver/><
br />
SetEnv force-proxy-request-1.0 1<
br />
SetEnv proxy-nokeepalive 1<
br />
</
section>
<!-- /envsettings --> <
section id="request-bodies"><
title>リクエストボディ</
title>
<
p>POST メソッドなどのリクエストには、リクエストボディがあります。
HTTP プロトコル仕様によると、ボディのあるリクエストは chunked
転送を使うか、<
code>Content-Length</
code>
このようなリクエストをオリジンサーバに送信する場合、
<
module>mod_proxy_http</
module> は常に <
code>Content-Length</
code>
を送ろうと試みます。しかし。ボディが大きく、オリジナルのリクエストで
chunked 転送が使われている場合、上流へのリクエストに
この挙動は <
a href="/env.html">環境変数</
a>で制御できます。
<
code>proxy-sendcl</
code> を設定すると、可能な限り常に
<
code>Content-Length</
code> を付与して、
逆に <
code>proxy-sendchunked</
code> を設定すると、リソース消費を抑え、
chnked エンコードを使って送信するようになります。</
p>
</
section>
<!-- /request-bodies --><
directivesynopsis type="section">
<
description>プロキシされるリソースに適用されるコンテナ</
description>
<
syntax><Proxy <
var>wildcard-url</
var>> ...</Proxy></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive type="section">Proxy</
directive> セクション中の
ディレクティブはマッチするプロキシされるコンテンツにのみ適用されます。
ホストにのみプロキシサーバを経由したアクセスを許可します:</
p>
<
p>次の例は <
code>
example.com</
code> の <
code>foo</
code> ディレクトリの
すべてのファイルに対して、プロキシサーバを通して送られたときには
<
code>INCLUDES</
code> フィルタを通して送るように設定します:</
p>
SetOutputFilter INCLUDES<
br />
<
name>ProxyBadHeader</
name>
<
description>応答におかしなヘッダがある場合の扱い方を決める</
description>
<
syntax>ProxyBadHeader IsError|Ignore|StartBody</
syntax>
<
default>ProxyBadHeader IsError</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>2.0.44 以降</
compatibility>
<
p><
directive>ProxyBadHeader</
directive> ディレクティブは構文的に
間違ったヘッダ (<
em>つまり</
em> コロンを含まないもの) を受け取ったときに
<
module>mod_proxy</
module> がどう振る舞うかを決めます。以下の引数を
<
dt><
code>IsError</
code></
dt>
<
dd>リクエストを中止して 502 (Bad Gateway) 応答を返す。
<
dt><
code>Ignore</
code></
dt>
<
dd>間違ったヘッダ行をそもそも存在しなかったものとして扱う。</
dd>
<
dt><
code>StartBody</
code></
dt>
<
dd>間違ったヘッダ行を受け取ったら、ヘッダの読み込みを終了して、
それ以降の残りをボディとして扱う。これはヘッダとボディの間に空行を入れ忘れて
しまっているような、きちんと動作していないバックエンドサーバがあるときに、
<
directivesynopsis type="section">
<
description>正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ</
description>
<
syntax><ProxyMatch <
var>regex</
var>> ...</ProxyMatch></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive type="section">ProxyMatch</
directive> は URL のマッチに
<
glossary ref="regex">正規表現</
glossary> を用いることを除いて
<
directive type="section">Proxy</
directive> ディレクティブと同じです。</
p>
<
name>ProxyPreserveHost</
name>
<
description>プロキシリクエストに、受け付けた Host HTTP ヘッダを使う</
description>
<
syntax>ProxyPreserveHost On|Off</
syntax>
<
default>ProxyPreserveHost Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>Apache 2.0.31 以降で使用可能</
compatibility>
<
p>このオプションが有効になっている場合、<
directive>ProxyPass</
directive>
で指定したホスト名の代わりに、受け付けたリクエストの Host: 行を
<
p>このオプションは通常は <
code>Off</
code> に設定してください。
ほとんどの場合、これは大量の名前ベースのバーチャルホスティングを行なっていて、
元々の Host ヘッダをバックエンドサーバが解釈する必要のあるときのような、
<
name>ProxyRequests</
name>
<
description>フォワード (標準の) プロキシリクエストを有効にする</
description>
<
syntax>ProxyRequests On|Off</
syntax>
<
default>ProxyRequests Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>これは Apache のフォワードプロキシサーバとしての動作を
有効もしくは無効にします。(ProxyRequests を <
code>Off</
code> に
設定しても、<
directive module="mod_proxy">ProxyPass</
directive>
<
p>通常のリバースプロキシの設定では、このオプションは <
code>Off</
code>
<
p>HTTP や FTP サイトへのプロキシの機能を有効にしたい場合は、
<
module>mod_proxy_http</
module> や <
module>mod_proxy_ftp</
module> が
サーバに組み込まれていなければなりません。</
p>
<
note type="warning"><
title>警告</
title>
>サーバを安全にする</
a>まで <
directive module="mod_proxy" >ProxyRequests</
directive> は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
<
description>特定のリクエストを扱う時に使われるリモートプロキシを指定する</
description>
<
syntax>ProxyRemote <
var>match</
var> <
var>remote-server</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>このディレクティブはこのプロキシに対するリモートプロキシを定義します。
<
var>match</
var> はリモートサーバがサポートする URL スキーム、
リモートサーバが使うはずの URL の一部分、サーバがすべての
リクエストに使われることを示す <
code>*</
code> のどれかになります。
<
var>remote-server</
var> はリモートサーバの部分 URL です。構文:</
p>
<
dfn>remote-server</
dfn> =
<
var>scheme</
var>://<
var>hostname</
var>[:<
var>port</
var>]
<
p><
var>scheme</
var> は実際上リモートサーバとの通信に使われるプロトコルを
決定します。このモジュールでは <
code>http</
code> だけがサポートされて
<
example><
title>例</
title>
<
p>この例では、プロキシは FTP リクエストを別の HTTP リクエストで包んで
そのようなリクエストを扱える別のプロキシに転送します。</
p>
<
p>このオプションはリバースプロキシの設定もサポートします。
サーバが別のフォワードプロキシの後ろに隠されている場合でも
バックエンドウェブサーバをバーチャルホストの URL 空間に入れることが
<
name>ProxyRemoteMatch</
name>
<
description>正規表現でのマッチによるリクエストを扱うリモートプロキシの指定</
description>
<
syntax>ProxyRemoteMatch <
var>regex</
var> <
var>remote-server</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>ProxyRemoteMatch</
directive> は最初の引数がリクエストされた
URL にマッチする<
glossary ref="regex">正規表現</
glossary>であることを除けば <
directive module="mod_proxy">ProxyRemote</
directive> ディレクティブと同じです。</
p>
<
description>リモートサーバをローカルサーバの URL 空間にマップする</
description>
<
syntax>ProxyPass [<
var>path</
var>] !|<
var>url</
var> [<
var>key=value</
var> <
var>key=value</
var> ...]]</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context>
<
p>このディレクティブはリモートサーバをローカルサーバの名前空間に
マップできるようにします。ローカルサーバは通常の意味でのプロキシと
しては動作せず、リモートサーバのミラーとして振る舞います。
<
var>path</
var> はローカルの仮想パスの名前です。<
var>url</
var> は
リモートサーバの部分 URL になり、クエリー文字列を含むことはできません。</
p>
<
note type="warning"><
directive>ProxyPass</
directive> ディレクティブを
module="mod_proxy">ProxyRequests</
directive> ディレクティブは通常は
<
strong>off</
strong> に設定されているべきです。</
note>
プロキシリクエストに変換されることになります。</
p>
<
p>サブディレクトリをリバースプロキシしたくないときに <
code>!</
code> は
<
p>順番は重要です。一般的な <
directive>ProxyPass</
directive>
<
p>2.1 の機能で、バックエンドサーバとの接続にプールされたコネクションを
使えるようになりました。<
code>key=value</
code> 形式のパラメータで
このコネクションプーリングの調整ができます。<
code>Hard Maximum</
code>
のデフォルト値は、有効になっている MPM でのプロセス当たりのスレッド数と
同じ数のコネクション数です。prefork MPM では通常は 1 で、worker MPM では
<
directive>ThreadsPerChild</
directive> で調整されます。</
p>
<
p><
code>min</
code> の設定で、バックエンドサーバとの間に何本のコネクションを
常時開くかが決まります。Soft Maximum <
code>smax</
code> の数に
達するまで必要に応じてコネクションは生成されます。<
code>smax</
code>
を超えた数のコネクションは、生存時間 <
code>ttl</
code> で切断されます。
バックエンドサーバと Hard Maximum <
code>max</
code> の数以上のコネクションを
常に開いているコネクション数の最小値</
td></
tr>
<
td>バックエンドサーバとの接続数の Hard Maximum
<
transnote>ハードリミット</
transnote>。
デフォルト値は、使用している MPM のプロセスあたりのスレッド数になっています。
Prefork MPM では常に 1 で、Worker MPM では <
directive>ThreadsPerChild</
directive>
で調節できます。Hard Maximum 以上にバックエンドサーバとのコネクションを
<
td>接続数の Soft Maximum <
transnote>ソフトリミット</
transnote>まで、
<
code>smax</
code> を超えた数のコネクションは生存時間 <
code>ttl</
code>
<
td><
code>smax</
code> 数を超えた非活動状態のコネクションの生存時間を、
秒で指定します。この期間内に使用されなかったコネクションは、
<
td><
directive>Timeout</
directive></
td>
<
td>コネクションタイムアウトを秒で指定します。特に指定されなければ、
フリーなコネクションを取得できるまで待ちます。このディレクティブは
<
code>max</
code> パラメータと合わせて使うことで、バックエンドサーバとの
<
td>設定すると、コネクションプールからフリーのコネクションを取得するために
待機する待ち時間の最大値になります。フリーのコネクションがプールになかった場合は、
<
code>SERVER_BUSY</
code> ステータスがクライアントに返されます。
<
td>バックエンドサーバと Apache の間にファイアーウォールがある場合には、
このパラメータを使ってください。ファイアウォールは往々にして、
このフラグは OS に指示して、<
code>KEEP_ALIVE</
code> メッセージを非活動状態の
コネクションでも送るようにします (間隔は OS のグローバル設定に依存し、
通常は 120ms 間隔) 。これによってファイアウォールによってコネクションが
落とされることを防げます。keepalive を有効にするには、このプロパティを
<
td>コネクションをプーリングするための、リトライのタイムアウトを秒で
指定します。バックエンドサーバへのコネクションプーリングが失敗した場合は、
タイムアウトの期間が過ぎるまで、そのサーバにリクエストをフォワードしません。
この機能を使うと、バックエンドサーバをメンテナンスのためにシャットダウンし、
後でオンラインに復帰させるといったことができます。
<
td>ワーカーあたりの負荷係数です。BalancerMember で使います。
1 から 100 までの数字でそのワーカーに対する正規化された負荷率を指定します。
<
td>ロードバランサで使った場合、ワーカーのルーティングをします。
ルートはセッション ID に付加された値になります。
<
td>ワーカーのリダイレクション経路です。この値は通常は、
安全にクラスタからノードを取り去る設定を動的に入れるために使います。
セッション ID の無いリクエスト全てを指定した場合は、
BalancerMember にリダイレクトされます。
<
p>Proxy ディレクティブのスキームが <
code>balancer://</
code> になっている場合は、
バックエンドサーバと実際には通信しない仮想ワーカーが生成されます。
このワーカーは幾つかの "本物の" ワーカーの管理をつかさどります。
この場合パラメータは、この仮想ワーカーに対して設定されます。
<
td>Balancer のロードバランス方法。使用するロードバランスの
スケジューリング方法を選びます。処理したリクエストの数で重み付けする
<
code>byrequests</
code> か、転送量のバイト数で重み付けする
<
code>bytraffic</
code> を設定できます。デフォルトは
<
code>byrequests</
code> です。
<
tr><
td>stickysession</
td>
<
td>バランサーのスティッキーセッション名です。通常はこの値は <
code>JSESSIONID</
code>
や <
code>PHPSESSIONID</
code> といったものになりますが、この値は
バックエンドアプリケーションのサポートするセッションに依存します。
<
td><
code>On</
code> になっていると、ワーカーがエラーを起こしたり
バックエンドサーバがセッションレプリケーションをサポートしていない場合は、
<
td>バランサーのタイムアウトを秒で指定します。
この値を設定すると、フリーのワーカーを取得するまでの最大待機時間になります。
<
td>フェイルオーバーを試みる最大の回数を指定します。
ProxyPass / balancer://mycluster stickysession=jsessionid nofailover=On<
br />
<Proxy balancer://mycluster><
br />
# Less powerful server, don't send as many requests there<
br />
<
p><
directive type="section" module="core" >Location</
directive> セクションの中で使われた場合、最初の引数は
省略され、ローカルディレクトリは <
directive type="section" module="core" >Location</
directive> から取得されます。</
p>
<
p>より柔軟なリバースプロキシの設定が必要な場合は、<
code>[P]</
code>
フラグ付きの <
directive module="mod_rewrite">RewriteRule</
directive>
<
name>ProxyPassReverse</
name>
<
description>リバースプロキシされたサーバから送られた HTTP 応答ヘッダの
<
syntax>ProxyPassReverse [<
var>path</
var>] <
var>url</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context>
<
p>このディレクティブは Apache に HTTP リダイレクト応答の
<
code>Location</
code>, <
code>Content-Location</
code>, <
code>URI</
code>
ヘッダの調整をさせます。これは、Apache がリバースプロキシとして使われている
ときに、リバースプロキシを通さないでアクセスすることを防ぐために
重要です。これによりバックエンドサーバの HTTP リダイレクトが
リバースプロキシとバックエンドの間で扱われるようになります。</
p>
<
p>ディレクティブで明示されている HTTP 応答ヘッダのみが書き換えられます。
Apache は他の応答ヘッダを書き換えたり、HTML ページの中の URL 参照を
書き換えたりすることはありません。HTML の中を見て、URL 参照を書き換える
>mod_proxy_html</
a> があります。</
p>
<
p><
var>path</
var> はローカル仮想パスの名前です。<
var>url</
var> は
リモートサーバの部分 URL です。これらは <
directive module="mod_proxy" >ProxyPass</
directive> ディレクティブと同様です。</
p>
へのプロキシリクエストに内部でリダイレクトされるだけではありません
Apache は HTTP リダイレクト応答をクライアントに送る前に、
URL を構成するのに使われるホスト名は <
directive module="core">UseCanonicalName</
directive> の設定に応じて選択されることに
<
p><
directive>ProxyPassReverse</
directive> ディレクティブは
対応する <
directive module="mod_proxy" >ProxyPass</
directive> ディレクティブには依存しないため、
<
module>mod_rewrite</
module> のプロキシ通過機能
(<
code>RewriteRule ... [P]</
code>) と併せて使用することができます。</
p>
<
p><
directive type="section" module="core" >Location</
directive> セクションの中で使われた場合は、
最初の引数は省略され、ローカルディレクトリは <
directive type="section" module="core">Location</
directive> から取得されます。</
p>
<
name>ProxyPassReverseCookieDomain</
name>
<
description>リバースプロキシサーバからの Set-Cookie ヘッダの Domain 文字列を
<
syntax>ProxyPassReverseCookieDomain <
var>internal-domain</
var> <
var>public-domain</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context>
<
directive module="mod_proxy">ProxyPassReverse</
directive> と同じですが、
ヘッダの URL の代わりに <
code>Set-Cookie</
code> ヘッダの
<
code>domain</
code> 文字列を書き換えます。</
p>
<
name>ProxyPassReverseCookiePath</
name>
<
description>Reverse プロキシサーバからの Set-Cookie ヘッダの Path 文字列を
<
syntax>ProxyPassReverseCookiePath <
var>internal-path</
var> <
var>public-path</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
context>directory</
context>
<
directive module="mod_proxy">ProxyPassReverse</
directive> と同じですが、
ヘッダの URL の代わりに <
code>Set-Cookie</
code> ヘッダの
<
code>path</
code> 文字列を書き換えます。</
p>
<
name>AllowCONNECT</
name>
<
description>プロキシを経由して、どのポートに <
code>CONNECT</
code>
<
syntax>AllowCONNECT <
var>port</
var> [<
var>port</
var>] ...</
syntax>
<
default>AllowCONNECT 443 563</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>AllowCONNECT</
directive> はプロキシの <
code>CONNECT</
code>
メソッドが接続を許可するポート番号のリストを指定します。
今日のブラウザは、<
code>https</
code> コネクションが要求されていて、
HTTP 上でのプロキシによるトンネリングができるときに、
<
p>デフォルトの設定では、https のデフォルトポート (<
code>443</
code>) と
デフォルトの snews ポート (<
code>563</
code>) が有効になっています。
このデフォルトを上書きして、リストに記載したポートにのみ接続を許可したい場合、
<
directive>AllowCONNECT</
directive> ディレクティブを使用します。</
p>
<
p><
code>CONNECT</
code> を使用するには、<
module>mod_proxy_connect</
module>
がサーバに組み込まれていなければならないことに注意してください。</
p>
<
description>プロキシ接続を禁止する語句、ホスト名、ドメインを指定する</
description>
<
syntax>ProxyBlock *|<
var>word</
var>|<
var>host</
var>|<
var>domain</
var>
[<
var>word</
var>|<
var>host</
var>|<
var>domain</
var>] ...</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>ProxyBlock</
directive> ディレクティブは空白で区切られた
語句、ホスト名、ドメインのリストを指定します。サイト名にその語句、ホスト名、
ドメインを含むサイトへの HTTP、HTTPS、FTP によるドキュメントのリクエストは
プロキシサーバにより<
em>ブロックされます</
em>。プロキシモジュールは
起動時にホスト名と思しき項目の IP アドレスを調べ、後のテストのために
キャッシュします。これにより、サーバの起動が少し遅くなるかもしれません。</
p>
<
example><
title>Example</
title>
<
p>はすべてのサイトへの接続をブロックすることに注意してください。</
p>
<
name>ProxyReceiveBufferSize</
name>
<
description>プロキシされる HTTP と FTP 接続のためのネットワークバッファサイズ</
description>
<
syntax>ProxyReceiveBufferSize <
var>bytes</
var></
syntax>
<
default>ProxyReceiveBufferSize 0</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>ProxyReceiveBufferSize</
directive> ディレクティブは
スループットを上げるために明示的に (
TCP/
IP) ネットワークバッファのサイズを
設定します。値は <
code>512</
code> 以上か、システムのデフォルトのバッファ
サイズを意味する <
code>0</
code> でなければなりません。</
p>
<
example><
title>例</
title>
ProxyReceiveBufferSize 2048
<
name>ProxyIOBufferSize</
name>
<
description>内部データスループットバッファのサイズを決定する</
description>
<
syntax>ProxyIOBufferSize <
var>bytes</
var></
syntax>
<
default>ProxyIOBufferSize 8192</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p><
directive>ProxyIOBufferSize</
directive> ディレクティブは入力と
出力用の一時メモリとして使われる内部バッファのサイズを調整します。
サイズは <
code>8192</
code> 以下でなければなりません。</
p>
<
p>ほとんどすべての場合、この値を変更する理由はありません。</
p>
<
name>ProxyMaxForwards</
name>
<
description>リクエストがフォワードされるプロキシの最大数</
description>
<
syntax>ProxyMaxForwards <
var>number</
var></
syntax>
<
default>ProxyMaxForwards 10</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>Apache 2.0 以降で使用可能</
compatibility>
<
p><
directive>ProxyMaxForwards</
directive> ディレクティブは
リクエストに <
code>Max-Forwards</
code> ヘッダが指定されていない場合に
リクエストが通過可能なプロキシの最大数を設定します。これは
プロキシの無限ループや DoS 攻撃を防ぐために設定されています。</
p>
<
example><
title>例</
title>
<
description>直接接続する ホスト、ドメイン、ネットワーク</
description>
<
syntax>NoProxy <
var>host</
var> [<
var>host</
var>] ...</
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>このディレクティブはイントラネット中の Apache プロキシサーバにのみ
有用です。<
directive>NoProxy</
directive> ディレクティブは空白区切りで、
サブネット、IP アドレス、ホスト、ドメインのリストを指定します。
これらのどれかにマッチするホストへのリクエストは <
directive module="mod_proxy">ProxyRemote</
directive> で設定されたプロキシサーバに
<
example><
title>例</
title>
<
p><
directive>NoProxy</
directive> ディレクティブの <
var>host</
var> 引数は
<!-- ===================== Domain ======================= --> <
dt><
var><
a name="domain" id="domain">Domain</
a></
var></
dt>
<
p><
dfn>Domain</
dfn> は先頭にピリオドの着いた部分 DNS ドメイン名です。
同一 DNS ドメイン及びゾーン (<
em>すなわち</
em>、ホスト名の末尾がすべて
<
var>Domain</
var> で終わっているということ) に属するホストのリストを
<
example><
title>例</
title>
<
p><
var>Domain</
var> を <
a href="#hostname" >Hostname</
a> と区別するために (意味的にも構文的にも。DNS ドメインも
DNS の A レコードを持つことができるのです!)、<
var>Domain</
var> は
<
p>ドメイン名の比較は大文字小文字を区別せずに行なわれ、<
var>Domain</
var>
は常に DNS ツリーのルートから始まるものとみなされます。ですから、
みなされます。ドメインの比較は DNS ルックアップなしで行なわれるため、
<!-- ===================== SubNet ======================= --> <
dt><
var><
a name="subnet" id="subnet">SubNet</
a></
var></
dt>
<
p><
dfn>SubNet</
dfn> は数値形式 (ドットで区切られた四つの数字) の
部分インターネットアドレスです。後にスラッシュと <
var>Subnet</
var>
の意味のあるビット数を指定するネットマスクとを続けることができます。
共通のネットワークインタフェースを使って到達することのできるサブネットを
表すために使われます。明示的にネットマスクを指定しない場合は
最後の省略された (もしくは値が 0 の) 数字がマスクを指定します。
(この場合は、ネットマスクは 8 ビット単位でしか指定できません。)
<
dt><
code>192.168</
code> もしくは <
code>192.168.0.0</
code></
dt>
<
dd>サブネット 192.168.0.0 と暗黙の 16 ビット有効なネットマスク
(<
code>255.255.0.0</
code> というネットマスクの形式で使われることも
ネットマスク (<
code>255.255.248.0</
code> という形式で使われることも
<
p>特別な場合に、32 ビット有効な <
em>SubNet</
em> は
<
var><
a href="#ipadr">IPAddr</
a></
var> と同等で、
0 ビット有効な <
var>SubNet</
var> (<
em>例えば</
em>、0.0.0.0/0) は
すべての IP アドレスにマッチする定数 <
var>_Default_</
var> と同じです。</
p>
<!-- ===================== IPAddr ======================= --> <
dt><
var><
a name="ipaddr" id="ipaddr">IPAddr</
a></
var></
dt>
<
p><
dfn>IPAddr</
dfn> は数値形式 (ドットで区切られた四つの数字) の
完全インターネットアドレスです。通常はこのアドレスはホストを
表しますが、必ずしもアドレスに対応する DNS ドメイン名があるわけでは
<
example><
title>例</
title>
<
p><
var>IPAddr</
var> は DNS システムにより解決される必要がないので、
apache の性能が向上するかもしれません。</
p>
<!-- ===================== Hostname ======================= --> <
dt><
var><
a name="hostname" id="hostname">Hostname</
a></
var></
dt>
<
p><
dfn>Hostname</
dfn> は DNS ドメインサービスにより一つもしくは
複数の <
var><
a href="#ipaddr">IPAddr</
a></
var> に解決可能な
完全な DNS ドメイン名です。これは (<
var><
a href="#domain">Domain</
a></
var>
と違って、説明は上記を参照) 論理的なホストを表し、少くとも一つの
<
var><
a href="#ipaddr">IPAddr</
a></
var> (もしくは違う
<
var><
a href="#ipaddr">IPAddr</
a></
var> のホストのリスト) に解決
<
example><
title>例</
title>
<
p>多くの場合、<
var>Hostname</
var> の代わりに <
var><
a href="#ipaddr">IPAddr</
a></
var> を指定した方が、DNS ルックアップを
避けることができるため、効率が良くなります。Apache の名前解決は
ネームサーバへの接続が遅い PPP 上の場合などにかなり時間を取られる
<
p><
var>Hostname</
var> の比較は大文字小文字を区別せずに行なわれ、
<
var>Hostname</
var> は常に DNS ツリーのルートから始まるものとみなされます。
<
name>ProxyTimeout</
name>
<
description>プロキシされたリクエストのネットワークタイムアウト</
description>
<
syntax>ProxyTimeout <
var>seconds</
var></
syntax>
<
default>ProxyTimeout 300</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>Apache 2.0.31 以降で使用可能</
compatibility>
<
p>このディレクティブはユーザがプロキシリクエストのタイムアウトを
指定できるようにします。これはハングしてしまう遅い、もしくは挙動の
怪しいサーバがあり、サーバがデータを返すまでひたすら待ち続けるよりも
タイムアウトを返してより緩やかに<
transnote>graceful に</
transnote>
<
description>プロキシされたリクエストのデフォルトのドメイン名</
description>
<
syntax>ProxyDomain <
var>Domain</
var></
syntax>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>このディレクティブはイントラネット内の Apache プロキシサーバにのみ
有用です。<
directive>ProxyDomain</
directive> ディレクティブは
apache プロキシサーバが属するデフォルトのドメインを指定します。
ドメイン名の無いリクエストを受けた場合、設定された <
var>Domain</
var>
が追加された同じホストへのリダイレクト応答が返されます。</
p>
<
example><
title>例</
title>
<
description>プロキシされたリクエストの <
code>Via</
code> HTTP 応答ヘッダ
<
syntax>ProxyVia On|Off|Full|Block</
syntax>
<
default>ProxyVia Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
p>このディレクティブはプロキシの <
code>Via:</
code> HTTP ヘッダの使用を
制御します。想定されている使い方は、プロキシサーバがいくつも繋がっているときに
プロキシリクエストの流れを制御することです。<
code>Via:</
code> ヘッダ行の
<
li>デフォルトの <
code>Off</
code> に設定されていると、特別な処理は
行なわれません。リクエストやリプライに <
code>Via:</
code> ヘッダがあれば、
<
li><
code>On</
code> に設定されていれば、各リクエストとリプライに
<
code>Via:</
code> 行が追加されます。</
li>
<
li><
code>Full</
code> に設定されていれば、<
code>Via:</
code> ヘッダは
コメント部分に Apache サーバのバージョンも含むようになります。</
li>
<
li><
code>Block</
code> に設定されていれば、すべてのプロキシリクエストから
<
code>Via:</
code> ヘッダが取り除かれます。新たに <
code>Via:</
code> が
<
name>ProxyErrorOverride</
name>
<
description>プロキシされたコンテンツのエラーページを上書きする</
description>
<
syntax>ProxyErrorOverride On|Off</
syntax>
<
default>ProxyErrorOverride Off</
default>
<
contextlist><
context>server config</
context><
context>virtual host</
context>
<
compatibility>バージョン 2.0 以降で使用可能</
compatibility>
<
p>このディレクティブはリバースプロキシを使用していて、
エンドユーザに送られるエラーページの外見を共通のものにしたいときに
有用です。このディレクティブは (<
module>mod_include</
module> の SSI によって)
インクルードされたファイルがエラーコードを取得して、正しく動作を
するようにもします (デフォルトの動作は、プロキシされたサーバの
エラーページの表示で、このディレクティブを有効にすると SSI のエラー