Apache HTTP サーバ バージョン 2.4

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

### トピック

- フォワードプロキシとリバースプロキシ
- 基本の例
- プロキシへのアクセス制御
- 遅い起動
- イントラネットプロキシ
- プロトコルの調整
- リクエストボディ

### ディレクティブ

### Bugfix checklist

- httpd changelog
- Known issues
- Report a bug

### 参照

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

## 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.

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

## BalancerMember ディレクティブ

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

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

## 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 * 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 に関する問題

## <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.com` の `foo` ディレクトリの すべてのファイルに対して、プロキシサーバを通して送られたときには `INCLUDES` フィルタを通して送るように設定します:

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

## Proxy100Continue ディレクティブ

説明: | Forward 100-continue expectation to the origin server
構文: | `Proxy100Continue Off|On`
デフォルト: | `Proxy100Continue On`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Extension
モジュール: | mod_proxy
互換性: | Available in version 2.4.39 and later

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

## ProxyAddHeaders ディレクティブ

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

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

## ProxyBadHeader ディレクティブ

説明: | 応答におかしなヘッダがある場合の扱い方を決める
構文: | `ProxyBadHeader IsError|Ignore|StartBody`
デフォルト: | `ProxyBadHeader IsError`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy
互換性: | 2.0.44 以降

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

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

## 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 *`

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

## 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` の SSI によって) インクルードされたファイルがエラーコードを取得して、正しく動作を するようにもします (デフォルトの動作は、プロキシされたサーバの エラーページの表示で、このディレクティブを有効にすると SSI のエラー メッセージを表示します)。

## ProxyIOBufferSize ディレクティブ

説明: | 内部データスループットバッファのサイズを決定する
構文: | `ProxyIOBufferSize bytes`
デフォルト: | `ProxyIOBufferSize 8192`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy

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

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

## <ProxyMatch> ディレクティブ

説明: | 正規表現でのマッチによるプロキシリソース用のディレクティブコンテナ
構文: | `<ProxyMatch regex> ...</ProxyMatch>`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy

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

## ProxyMaxForwards ディレクティブ

説明: | リクエストがフォワードされるプロキシの最大数
構文: | `ProxyMaxForwards number`
デフォルト: | `ProxyMaxForwards 10`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy
互換性: | Apache 2.0 以降で使用可能

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

### 例

`ProxyMaxForwards 15`

## 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 | - | バランサーのスティッキーセッション名です。通常はこの値は `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` ディレクティブを参照してください。

## 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.

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

## ProxyPassInterpolateEnv ディレクティブ

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

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

## 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` ディレクティブと同様です。

例えば、ローカルサーバのアドレスが `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`
コンテキスト: | サーバ設定ファイル, バーチャルホスト, ディレクトリ
ステータス: | Extension
モジュール: | mod_proxy

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

## ProxyPassReverseCookiePath ディレクティブ

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

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

## 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 空間に入れることが できます。

## ProxyRemoteMatch ディレクティブ

説明: | 正規表現でのマッチによるリクエストを扱うリモートプロキシの指定
構文: | `ProxyRemoteMatch regex remote-server`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy

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

## ProxyRequests ディレクティブ

説明: | フォワード (標準の) プロキシリクエストを有効にする
構文: | `ProxyRequests On|Off`
デフォルト: | `ProxyRequests Off`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy

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

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

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

### 警告

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

## ProxySet ディレクティブ

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

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

## ProxySourceAddress ディレクティブ

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

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

## ProxyStatus ディレクティブ

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

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

## ProxyTimeout ディレクティブ

説明: | プロキシされたリクエストのネットワークタイムアウト
構文: | `ProxyTimeout seconds`
デフォルト: | `ProxyTimeout 300`
コンテキスト: | サーバ設定ファイル, バーチャルホスト
ステータス: | Extension
モジュール: | mod_proxy
互換性: | Apache 2.0.31 以降で使用可能

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

## ProxyVia ディレクティブ

説明: | プロキシされたリクエストの `Via` HTTP 応答ヘッダ により提供される情報
構文: | `ProxyVia On|Off|Full|Block`
デフォルト: | `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:` が 生成されることはありません。

翻訳済み言語: en | fr | ja

## コメント

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 again 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 Freenode, or sent to our mailing lists.