From: Hiroaki Kawai Date: Mon, 31 Jan 2005 13:59:53 +0000 (+0000) Subject: New Japanese translation. X-Git-Tag: 2.1.3~93 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=e67a5502d75ac0e8b98ef8e83fc52dc2c504237d;p=apache New Japanese translation. Submitted by: yoshiki Reviewed by: kawai git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@149259 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_proxy.xml.ja b/docs/manual/mod/mod_proxy.xml.ja new file mode 100644 index 0000000000..d88dfb82f7 --- /dev/null +++ b/docs/manual/mod/mod_proxy.xml.ja @@ -0,0 +1,1183 @@ + + + + + + + + + +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_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 ディレクティブを使って) + リバースプロキシを使っている場合には、クライアントはあなたが明示的に + 設定したホストにしかアクセスできないため、フォワードプロキシのとき + ほどアクセス制御に力を注がなくても大丈夫です。

+ +
+ +
FTP プロキシ + + +
どうしてファイルタイプが <var>xxx</var> + のファイルを FTP でダウンロードできないの? +

おそらく、プロキシの mime.types 設定ファイルでそのファイルタイプが + application/octet-stream であると定義されていないのでしょう。 + 以下のようなものが役に立つかもしれません:

+ + +
application/octet-stream   bin dms lha lzh exe class tgz taz
+ +

別の方法として、すべてのデフォルトをバイナリにすることもできます:

+ +
DefaultType application/octet-stream
+ +
+ +
ファイル <var>xxx</var> を FTP の ASCII ダウンロード + にさせるのはどうすればよいの? +

まれに、(デフォルトの転送は binary モードで) 特定の + ファイルのみ FTP の ASCII 転送方法を使わなければならない + 場合には、リクエストの最後に ;type=a を付けることで + mod_proxy に ASCII 転送をさせることができます。 + (ただし、FTP のディレクトリ一覧は常に ASCII モードで行なわれます。)

+
+ +
FTP のアップロードはどうすればよいの? +

現時点では、mod_proxy の FTP サポートは GET のみです。もちろん + Apache の プロキシを使って HTTP のアップロード (POST や PUT) を + することはできます。

+
+ +
ホームディレクトリの外の FTP ファイルに + アクセスするにはどうすればよいの? +

FTP URI はログインしているユーザのホームディレクトリからの + 相対パスとして扱われます。残念なことに、/../ はブラウザにより解釈され、 + 実際に FTP サーバには送られないため、/../ を使って上位のディレクトリに + 到達することはできません。この問題を解決するために、いわゆる + Squid %2f ハック を Apache の FTP プロキシは実装しています。 + これは Squid Proxy キャッシュ のような + 他のよく使われているプロキシサーバでも取られている方法です。 + リクエストのパスの先頭に /%2f を付けることで、プロキシに + FTP の開始ディレクトリを (ホームディレクトリの代わりに) / + に変えることができます。例えば、/etc/motd を取得するためには + 次の URL を使います:

+ + + ftp://user@host/%2f/etc/motd + +
+ +
ブラウザの URL 表示で FTP の平文パスワードを + 隠すにはどうすればよいの? +

FTP サーバにユーザ名とパスワードを使ってログインするために、 + Apache は異なる方法を使います。URL にユーザ名とパスワードがまったく + ない場合は、Apache は FTP サーバに anonymous ログインを送ります。 + つまり、

+ + + user: anonymous
+ password: apache_proxy@ + + +

これは anonymous アクセスが設定された + すべての FTP サーバに対して動作します。

+ +

ユーザ名を使った個人別のログインには、URL にユーザ名を入れることが + できます:

+ + + ftp://username@host/myfile + + +

このユーザ名が与えられたときに、FTP サーバがパスワードを要求すれば + (もちろんそうすべきなのですが)、Apache は 401 + (Authorization required) を返します。これにより、ブラウザはユーザ名 + パスワードの入力ダイアログを表示します。パスワードが入力された後、 + 再び接続を試み、成功すればリクエストしたリソースが表示されます。 + この方法の利点はブラウザがパスワードを平文を表示しないことです。 + (もし最初から

+ + + ftp://username:password@host/myfile + + +

と入力した場合には表示されてしまいます。)

+ + 注 +

送信されるパスワードは、暗号化されて送られるわけではありません。 + ブラウザと Apache プロキシサーバは base64 で符号化された + 文字列として、Apache プロキシと FTP サーバの間は平文として送られます。 + ですから、HTTP を使って HTTP をアクセスする前 (もしくは、そもそも + 個人的なファイルを FTP でアクセスする前) によく考える必要があります。 + 安全でない通信路を使った場合は、盗聴者に途中でパスワードを盗まれる + 可能性があります。

+ +
+
+
遅い起動 +

ProxyBlock ディレクティブを使っている場合、 + 後のテストのために起動時にホストの + IP アドレスが調べられてキャッシュされます。ホスト名のルックアップの + 速さによっては、数秒 (かそれ以上) かかるかもしれません。

+
+ +
イントラネットプロキシ +

イントラネットにある Apache プロキシサーバは外部へのリクエストを + 会社のファイアウォールを通して送らなければなりません。(このためには + 個々の scheme についてそれぞれ、ファイアウォールの + プロキシにフォワードされるように + ProxyRemote ディレクティブを + 設定してください)。しかしイントラネット内のリソースにアクセスするときは、 + ファイアウォールを通さないでもアクセスできます。 + どのホストがイントラネットに属し、直接アクセスすべきかを指定するには、 + NoProxy ディレクティブが + 役に立ちます。

+ +

イントラネット内のユーザは WWW のリクエストでローカルドメインを + 省略することがよくあります。http://somehost.example.com/ + というリクエストの代わりに "http://somehost/" をリクエストしたりします。 + このようなリクエストを受け付け、サーバに設定されているローカルドメインが + 暗黙のうちに使われていると解釈して、単純にリクエストを処理するものも + 商用プロキシサーバの中にはあります。 + サーバが プロキシのサービス用に設定されていて + ProxyDomain ディレクティブが + 使用された場合には、Apache はクライアントにリダイレクト応答を送って、 + 正しい、完全な (fully qualified) + サーバのアドレスに送ることができます。このように + リダイレクトすると、ユーザのブックマークが正しい完全なホスト名を含む + ことにもなるため、より好ましい方法と言えるでしょう。

+
+ +
プロトコルの調整 +

Keepalive や HTTP/1.1 を適切に実装していないアプリケーションサーバが + ある状況で、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> + +
+ + +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> + + +

2.1 の新機能で、バックエンドサーバとの接続に様々な + コネクションパラメータを設定できるようになりました。 + コネクションパラメータは key=value の形式になります。 +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
パラメータデフォルト値説明
min0バックエンドサーバとの接続で + 常に開いているコネクション数の最小値
max1...nバックエンドサーバとの接続数の Hard Maximum + ハードリミット。 + デフォルト値は、使用している MPM のプロセスあたりのスレッド数になっています。 + Prefork MPM では常に 1 で、Worker MPM では ThreadsPerChild + で調節できます。Hard Maximum 以上にバックエンドサーバとのコネクションを + 生成することはありません。
smaxmax接続数の Soft Maximum ソフトリミットまで、 + コネクションは必要に応じて生成されます。 + smax を超えた数のコネクションは生存時間 ttl + で切断されます。 +
ttl-smax 数を超えた非活動状態のコネクションの生存時間を、 + 秒で指定します。この期間内に使用されなかったコネクションは、 + 全て閉じられます。 +
timeoutTimeoutコネクションタイムアウトを秒で指定します。特に指定されなければ、 + フリーなコネクションを取得できるまで待ちます。このディレクティブは + max パラメータと合わせて使うことで、バックエンドサーバとの + 接続数を制御するのに使います。 +
acquire-設定すると、コネクションプールからフリーのコネクションを取得するために + 待機する待ち時間の最大値になります。フリーのコネクションがプールになかった場合は、 + SERVER_BUSY ステータスがクライアントに返されます。 +
keepaliveOffバックエンドサーバと Apache の間にファイアーウォールがある場合には、 + このパラメータを使ってください。ファイアウォールは往々にして、 + 非活動状態のコネクションを落とそうとします。 + このフラグは OS に指示して、KEEP_ALIVE メッセージを非活動状態の + コネクションでも送るようにします (間隔は OS のグローバル設定に依存し、 + 通常は 120ms 間隔) 。これによってファイアウォールによってコネクションが + 落とされることを防げます。keepalive を有効にするには、このプロパティを + On にしてください。 +
retry60コネクションをプーリングするための、リトライのタイムアウトを秒で + 指定します。バックエンドサーバへのコネクションプーリングが失敗した場合は、 + タイムアウトの期間が過ぎるまで、そのサーバにリクエストをフォワードしません。 + この機能を使うと、バックエンドサーバをメンテナンスのためにシャットダウンし、 + 後でオンラインに復帰させるといったことができます。 +
loadfactor1ワーカーあたりの負荷係数です。BalancerMember で使います。 + 1 から 100 までの数字でそのワーカーに対する負荷を指定します。 +
route-ロードバランサで使った場合、ワーカーのルーティングをします。 + ルートはセッション ID に付加された値になります。 +
redirect-ワーカーのリダイレクション経路です。この値は通常は、 + 安全にクラスタからノードを取り去る設定を動的に入れるために使います。 + セッション ID の無いリクエスト全てを指定した場合は、 + この値と同じルーティングパラメータを持つ + BalancerMember にリダイレクトされます。 +
+ +

Proxy ディレクティブのスキームが balancer:// になっている場合は、 + バックエンドサーバと実際には通信しない仮想ワーカーが生成されます。 + このワーカーは幾つかの "本物の" ワーカーの管理をつかさどります。 + この場合パラメータは、この仮想ワーカーに対して設定されます。 +

+ + + + + + + + + + + + + + + + + +
パラメータデフォルト値説明
stickysession-バランサーのスティッキーセッション名です。通常はこの値は JSESSIONID + や PHPSESSIONID といったものになりますが、この値は + バックエンドアプリケーションのサポートするセッションに依存します。 +
nofailoverOffOn になっていると、ワーカーがエラーを起こしたり + 無効になっている場合にセッションが切れます。 + バックエンドサーバがセッションレプリケーションをサポートしていない場合は、 + On にしてください。 +
timeout0バランサーのタイムアウトを秒で指定します。 + この値を設定すると、フリーのワーカーを取得するまでの最大待機時間になります。 + デフォルトでは待機しません。 +
maxattempts1フェイルオーバーを試みる最大の回数を指定します。 +
+ + <Proxy balancer://mycluster stickysession=jsessionid nofailover=On>
+ + BalancerMember http://1.2.3.4:8009
+ BalancerMember http://1.2.3.5:8009
+ BalancerMember http://1.2.3.6:8009
+ + </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 に設定してください。 + ほとんどの場合、これは大量の名前ベースのバーチャルホスティングを行なっていて、 + 元々の Header ヘッダをバックエンドサーバが解釈する必要のあるときのような、 + 特別な設定が必要な場合にのみ有用です。

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

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

+ +

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

+ +

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

+ + 警告 +

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

+ + + + + +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 ディレクティブと同じです。

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

このディレクティブはリモートサーバをローカルサーバの名前空間に + マップできるようにします。ローカルサーバは通常の意味でのプロキシと + しては動作せず、リモートサーバのミラーとして振る舞います。 + path はローカルの仮想パスの名前です。url は + リモートサーバの部分 URL になり、クエリー文字列を含むことはできません。

+ +

ローカルサーバのアドレスが 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 + + +

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

+ + ProxyPass ディレクティブを + 使っているときは ProxyRequests ディレクティブは通常は + off に設定されているべきです。 + +

より柔軟なリバースプロキシの設定が必要な場合は、[P] + フラグ付きの RewriteRule + ディレクティブを参照してください。

+ + + + +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 +プロキシ接続を禁止する語句、ホスト名、ドメインを指定する +ProxyBlock *|word|host|domain +[word|host|domain] ... +server configvirtual host + + + +

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 ドメインサービスにより一つもしくは + 複数の IPAddrs に解決可能な + 完全な 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 のエラー + メッセージを表示します)。

+ + + +