mod_proxy BalancerInherit代替案：Apache設定の柔軟性を高める方法

2025-05-27

BalancerInherit は、Apache HTTP Server の mod_proxy モジュールにおける非常に便利なディレクティブです。これは、特定のコンテナ（例: VirtualHost や Location）内で定義されたプロキシバランサーの設定が、そのコンテナの親（例えば、VirtualHost の場合はサーバ全体の設定、Location の場合はその親の VirtualHost や他の Location）から継承されるかどうかを制御します。

目的

BalancerInherit の主な目的は、設定の重複を避け、管理を簡素化することです。複数の VirtualHost や Location で同じプロキシバランサー設定を使用する場合、それぞれで同じ設定を記述する代わりに、親コンテナで一度定義し、子コンテナでそれを継承させることができます。

構文

BalancerInherit On|Off

Off: 親コンテナで定義されたプロキシバランサーの設定を継承しません。子コンテナ内で独自のバランサー設定を定義した場合、親の設定は無視されます。
On: 親コンテナで定義されたプロキシバランサーの設定を継承します。これがデフォルトの動作です。

動作の詳細

- 子コンテナ（VirtualHost や Location など）で BalancerInherit On が設定されている場合、そのコンテナは親コンテナで定義されたすべてのプロキシバランサー（ProxySet で定義されたメンバーや、ProxyAddBalancerMember などで追加されたメンバー）を継承します。
- 子コンテナ内で同じバランサー名に対して異なる設定（例: ProxySet で異なるメンバーを設定するなど）がある場合、子コンテナの設定が親の設定を上書きします。つまり、継承された設定と子コンテナ独自の定義がマージされ、衝突する場合は子コンテナの定義が優先されます。
- これにより、基本となるバランサー設定を一度定義し、特定の場合にのみ子コンテナで調整を加えるといった柔軟な設定が可能になります。
BalancerInherit Off
- 子コンテナで BalancerInherit Off が設定されている場合、そのコンテナは親コンテナで定義されたプロキシバランサーの設定を一切継承しません。
- 子コンテナ内でプロキシバランサーを使用したい場合、そのコンテナ内で明示的に ProxySet や ProxyAddBalancerMember を使用してバランサーを定義する必要があります。
- これは、親の設定とは完全に独立したバランサー設定が必要な場合に特に役立ちます。

使用例

例1: BalancerInherit On (デフォルトの動作)

<VirtualHost *:80>
    ServerName www.example.com

    # 親（VirtualHost）でバランサーを定義
    <Proxy balancer://mycluster>
        BalancerMember http://backend1.example.com
        BalancerMember http://backend2.example.com
    </Proxy>
    ProxyPass /app/ balancer://mycluster/

    <Location /app/subdir/>
        # BalancerInherit On はデフォルトなので、省略可能
        # ここで定義がない場合、/app/ のバランサー設定が継承される
        # もしここで何か定義すると、親の設定を上書きまたはマージする
        # 例えば、特定のバックエンドだけ無効にする場合など
        # BalancerMember http://backend1.example.com status=+H # backend1をヘルスチェック対象外にする
    </Location>
</VirtualHost>

この例では、/app/subdir/ のリクエストは、親の VirtualHost で定義された mycluster バランサーを継承して使用します。

例2: BalancerInherit Off

<VirtualHost *:80>
    ServerName www.example.com

    # 親（VirtualHost）でバランサーを定義
    <Proxy balancer://mycluster_parent>
        BalancerMember http://parent_backend1.example.com
        BalancerMember http://parent_backend2.example.com
    </Proxy>
    ProxyPass /parent_app/ balancer://mycluster_parent/

    <Location /separate_app/>
        # 親のバランサー設定を継承しない
        BalancerInherit Off

        # この Location 専用のバランサーを定義
        <Proxy balancer://mycluster_child>
            BalancerMember http://child_backend1.example.com
            BalancerMember http://child_backend2.example.com
        </Proxy>
        ProxyPass /separate_app/ balancer://mycluster_child/
    </Location>
</VirtualHost>

この例では、/separate_app/ のリクエストは、親の mycluster_parent バランサーとは全く関係なく、mycluster_child バランサーを使用します。

BalancerInherit ディレクティブは、Apache の mod_proxy を利用した負荷分散環境において、設定の柔軟性と管理のしやすさを向上させます。

Off: 親のバランサー設定を完全に無視し、そのコンテナ内で独立したバランサー設定を定義する。
On (デフォルト): 親のバランサー設定を継承し、必要に応じて部分的に上書き・追加する。

BalancerInherit は設定の柔軟性を高める一方で、その動作を理解していないと予期せぬ問題を引き起こすことがあります。

期待通りのバランサーが使用されない（異なるバックエンドにルーティングされる）

原因

設定ファイルの読み込み順序やネストの深さによる影響。Apacheは設定を上から順に処理し、より具体的な（ネストされた）設定が優先される傾向があります。
BalancerInherit On (デフォルト) で継承されているが、子コンテナで意図せず別のバランサーが同じ名前で再定義されている、または既存のメンバーが上書きされている場合。
BalancerInherit Off が設定されているにもかかわらず、親のバランサー設定が使われると期待している場合。

トラブルシューティング

- 関係する VirtualHost や Location ブロックに BalancerInherit がどのように設定されているかを確認します。明示的に Off が設定されていないか、またデフォルトの On で期待通りの動作をしているかを確認します。
- 子コンテナで同じバランサー名 (balancer://mycluster) が再定義されていないか確認します。もし再定義されている場合、その定義が親の定義を上書きします。
- ProxyPass または ProxyPassMatch ディレクティブが、目的のバランサーURL (balancer://mycluster/) を正しく参照しているか確認します。
apachectl configtest の実行
- 構文エラーがないか確認します。
```
sudo apachectl configtest
```
これで、基本的な設定の誤りを検出できます。
Apache エラーログの確認
- Apache のエラーログ (error_log または apache2/error.log など) を確認します。バランサーに関する警告やエラーメッセージがないか探します。特に、バックエンドへの接続失敗やルーティングに関する情報が含まれている可能性があります。
- ログレベルを debug に設定すると、より詳細な情報が得られます（ただし、運用環境では推奨されません）。
```
LogLevel debug
```

バランサーメンバーの一部が機能しない、または常に特定のメンバーにルーティングされる

原因

スティッキーセッション（stickysession）の設定が原因で、セッションが特定のバックエンドに固定されている場合。
ProxySet や BalancerMember ディレクティブの構文ミスやタイプミス。
BalancerInherit On の状況で、子コンテナの設定が親の設定を部分的に上書きし、意図しないメンバーを無効にしているか、設定を破損させている場合。

トラブルシューティング

詳細な設定差分の確認
- 親と子のコンテナで、同じバランサー名に対してどのような ProxySet や BalancerMember の設定がされているか、行ごとに比較します。
- 特に BalancerMember の status 属性（例: status=+H でヘルスチェック無効化、status=-H でヘルスチェック有効化）や loadfactor 属性などが意図せず変更されていないか確認します。
balancer-manager の利用
- mod_proxy_balancer が提供する balancer-manager (通常 /balancer-manager でアクセス可能) を有効にしている場合、これを使って実行中のバランサーの状態を確認できます。どのメンバーが有効で、ロードファクターがどうなっているか、セッション数がどうなっているかなどを視覚的に確認でき、問題の特定に役立ちます。
- 設定方法の例:
```
<Location "/balancer-manager">
    SetHandler balancer-manager
    Require ip 127.0.0.1 # アクセスを制限する
</Location>
```
スティッキーセッションの確認
- スティッキーセッションが設定されている場合、それが期待通りに機能しているか確認します。例えば、クライアントのクッキーやURLに特定のバックエンドへの情報が含まれているはずです。
- 開発ツール（ブラウザのF12）で、リクエストヘッダやレスポンスヘッダに Set-Cookie や Cookie ヘッダが含まれているか、その値が期待通りかを確認します。

設定変更が反映されない

原因

変更した設定ファイルが、実際にApacheが読み込んでいるファイルではない場合。
Apache の再起動（restart）ではなく、設定のリロード（reload）を行った場合、モジュールの変更や一部の重要な設定変更が反映されないことがあります。

トラブルシューティング

Apache の完全な再起動
- 設定変更後は、必ず Apache を完全に再起動します。
```
sudo systemctl restart apache2 # Debian/Ubuntuの場合
sudo systemctl restart httpd   # CentOS/RHELの場合
```
または sudo apachectl restart。
読み込みファイルの確認
- httpd.conf や apache2.conf の中で、Include ディレクティブによって正しい設定ファイルが読み込まれているか確認します。
- 特に、異なる環境（開発、ステージング、本番）で設定ファイルが異なる場合、適切なファイルに変更を加えているか再確認します。

バランサーの名前衝突による問題

原因

異なるコンテナ（例えば、異なる VirtualHost 内）で、同じバランサー名 (balancer://mycluster) を持ち、かつ BalancerInherit Off が設定されていない場合、意図しないバランサーの共有や上書きが発生する可能性があります。

トラブルシューティング

バランサー名のユニーク化
- 各 VirtualHost や Location で独立したバランサーを使用したい場合は、バランサー名をユニークにします（例: balancer://vhost1_cluster, balancer://locationA_cluster）。
- または、BalancerInherit Off を使用して、明示的に親からの継承を停止させます。

一般的なトラブルシューティングのヒント

ネットワーク接続の確認
バックエンドサーバーへのネットワーク接続が確立されているか、ファイアウォール（iptables や firewalld など）によってブロックされていないか確認します。telnet や curl などを使って、Apacheサーバーから直接バックエンドサーバーへの接続を試みます。
システムログの確認
Apacheのエラーログだけでなく、システム全体のログ（journalctl -xe や /var/log/syslog など）も確認し、OSレベルでの問題（ネットワーク、リソース不足など）がないか確認します。
コメントアウトによる切り分け
疑わしいディレクティブや設定ブロックを一時的にコメントアウトして、問題の原因となっている箇所を特定します。
最小限の設定でテスト
複雑な設定になっている場合、問題を切り分けるために、BalancerInherit と関係する部分だけを抜き出した最小限の設定で動作を確認します。

BalancerInherit ディレクティブは、親コンテナで定義されたプロキシバランサーの設定を、子コンテナが継承するかどうかを制御します。これにより、設定の重複を減らし、管理を効率化できます。

前提条件

変更後に Apache を再起動できること。
Apache の設定ファイル（通常は httpd.conf や extra/httpd-vhosts.conf など）を編集できること。
mod_proxy および mod_proxy_balancer モジュールが Apache にロードされていること。（例: LoadModule proxy_module modules/mod_proxy.so や LoadModule proxy_balancer_module modules/mod_proxy_balancer.so が有効になっていること）

BalancerInherit On (デフォルトの動作) の例

この例では、VirtualHost 全体で共有されるデフォルトのバランサーを定義し、特定の Location ブロックではそのバランサー設定を継承しつつ、一部のメンバーの設定を上書きします。

# modules/mod_proxy.so と mod_proxy_balancer.so がロードされていることを確認

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html

    # --- 親（VirtualHost）レベルでのバランサー定義 ---
    # balancer://my_global_cluster という名前のバランサーを定義
    # デフォルトでは 'byrequests' (リクエスト数) でロードバランシング
    <Proxy balancer://my_global_cluster>
        # バックエンドサーバー1
        BalancerMember http://backend1.example.com:8080 loadfactor=10 route=node1
        # バックエンドサーバー2
        BalancerMember http://backend2.example.com:8080 loadfactor=10 route=node2
        ProxySet lbmethod=byrequests stickysession=JSESSIONID
    </Proxy>

    # /app/ のリクエストを my_global_cluster バランサーに転送
    ProxyPass /app/ balancer://my_global_cluster/
    ProxyPassReverse /app/ balancer://my_global_cluster/

    # --- 子（Location）レベルでの設定変更 ---
    # /app/admin/ のリクエストに対する設定
    <Location /app/admin/>
        # BalancerInherit はデフォルトで On なので、明示的に記述する必要はありません。
        # BalancerInherit On 

        # 親の 'my_global_cluster' バランサー設定を継承します。
        # ここで同じバランサー名に対して定義を行うと、親の設定を上書きまたはマージします。

        # 例: admin 向けのトラフィックは特定のバックエンドにのみルーティングしたい場合
        # または、特定のバックエンドを「ホットスタンバイ」にしたい場合
        <Proxy balancer://my_global_cluster>
            # backend1 のロードファクターを上げて、admin リクエストがそちらに行くように誘導
            # または、backend2 を一時的に無効にする（メンテナンスなど）
            BalancerMember http://backend1.example.com:8080 loadfactor=100 route=node1
            BalancerMember http://backend2.example.com:8080 status=+H # backend2をホットスタンバイにする
        </Proxy>
        
        # ProxyPass は親から継承されるため、通常は Location 内で再定義は不要ですが、
        # 必要に応じてパスを調整できます。
        # ProxyPass /app/admin/ balancer://my_global_cluster/admin/
        # ProxyPassReverse /app/admin/ balancer://my_global_cluster/admin/
    </Location>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

解説

Location ブロック内で再度 <Proxy balancer://my_global_cluster> を定義し、BalancerMember の設定を上書きしています。ここでは、backend1.example.com の loadfactor を高くすることで、admin トラフィックが優先的にそちらにルーティングされるようにしています。また、backend2.example.com を status=+H (Hot Standby) に設定することで、通常は使用されず、他のメンバーが利用できない場合にのみ使われるようにしています。
/app/admin/ の Location ブロックでは、BalancerInherit はデフォルトで On であるため、親で定義された my_global_cluster の設定が継承されます。
/app/ へのアクセスは、この my_global_cluster を使用します。
VirtualHost レベルで my_global_cluster というバランサーを定義し、2つのバックエンドサーバーを設定しています。

BalancerInherit Off の例

この例では、特定の Location ブロックで、親のバランサー設定とは完全に独立した独自のバランサー設定を使用します。

# modules/mod_proxy.so と mod_proxy_balancer.so がロードされていることを確認

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html

    # --- 親（VirtualHost）レベルでのバランサー定義 ---
    <Proxy balancer://main_app_cluster>
        BalancerMember http://appserver1.example.com:8080
        BalancerMember http://appserver2.example.com:8080
        ProxySet lbmethod=bybusyness # ロードファクターに基づいてロードバランシング
    </Proxy>
    ProxyPass /main_app/ balancer://main_app_cluster/
    ProxyPassReverse /main_app/ balancer://main_app_cluster/

    # --- 子（Location）レベルでの独立したバランサー定義 ---
    # /api/ のリクエストに対する設定
    <Location /api/>
        # 親のバランサー設定を継承しない
        BalancerInherit Off

        # この Location 専用の新しいバランサーを定義
        <Proxy balancer://api_cluster>
            BalancerMember http://api_backend1.example.com:9000
            BalancerMember http://api_backend2.example.com:9000
            ProxySet lbmethod=byrequests # リクエスト数に基づいてロードバランシング
            # 例えば、API特有のタイムアウト設定など
            ProxySet timeout=30 connectiontimeout=5
        </Proxy>

        # /api/ のリクエストを api_cluster バランサーに転送
        ProxyPass /api/ balancer://api_cluster/
        ProxyPassReverse /api/ balancer://api_cluster/
    </Location>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

/api/ へのアクセスは、完全に独立した api_cluster を使用します。
代わりに、この Location ブロック内で api_cluster という新しいバランサーを定義し、独自のバックエンドサーバーとロードバランシング方式（byrequests）を設定しています。
/api/ の Location ブロックでは、BalancerInherit Off を設定しています。これにより、このブロックは親の main_app_cluster の設定を一切継承しません。
VirtualHost レベルで main_app_cluster というバランサーを定義し、/main_app/ へのアクセスに使用しています。

各 VirtualHost や Location でバランサーを個別に定義する

これは最も直接的な代替方法であり、BalancerInherit Off と同じ結果になります。親からの継承を一切行わず、それぞれのコンテナで必要なバランサーをゼロから定義します。

利点

設定の依存関係が少なく、あるコンテナの設定変更が他のコンテナに影響を与えにくい。
設定が明確で、各コンテナがどのバランサーを使用しているかが一目でわかる。

欠点

後からバランサーメンバーの追加や変更があった場合に、複数の場所を更新する必要がある。
複数の場所で同じバランサー設定が必要な場合、記述が冗長になる。

コード例

# VirtualHost 1
<VirtualHost *:80>
    ServerName app1.example.com
    DocumentRoot /var/www/app1

    # app1 専用のバランサー
    <Proxy balancer://app1_cluster>
        BalancerMember http://app1-backend1.example.com:8080
        BalancerMember http://app1-backend2.example.com:8080
        ProxySet lbmethod=byrequests
    </Proxy>
    ProxyPass / balancer://app1_cluster/
    ProxyPassReverse / balancer://app1_cluster/

    ErrorLog ${APACHE_LOG_DIR}/app1_error.log
    CustomLog ${APACHE_LOG_DIR}/app1_access.log combined
</VirtualHost>

# VirtualHost 2
<VirtualHost *:80>
    ServerName app2.example.com
    DocumentRoot /var/www/app2

    # app2 専用のバランサー（app1_clusterとは独立）
    <Proxy balancer://app2_cluster>
        BalancerMember http://app2-backend1.example.com:8081
        BalancerMember http://app2-backend2.example.com:8081
        ProxySet lbmethod=bybusyness
    </Proxy>
    ProxyPass / balancer://app2_cluster/
    ProxyPassReverse / balancer://app2_cluster/

    ErrorLog ${APACHE_LOG_DIR}/app2_error.log
    CustomLog ${APACHE_LOG_DIR}/app2_access.log combined
</VirtualHost>

Include ディレクティブを使用して共通設定を管理する

これは、BalancerInherit を使わない場合に、設定の冗長性を避けるための一般的な方法です。共通のバランサー定義を別のファイルに書き出し、必要な場所で Include します。

利点

ファイルを分けることで設定の可読性が向上する。
共通バランサーの変更が一箇所で済む。
設定の重複を避けられる。

欠点

Location ブロック内など、コンテナの特定の場所で Include が機能しない場合がある（Apache のバージョンやモジュールによる）。
どのバランサーがどのファイルから読み込まれているかを把握する必要がある。

コード例

まず、共通のバランサー定義ファイル (conf/extra/common_balancers.conf など) を作成します。

# conf/extra/common_balancers.conf の内容
<Proxy balancer://shared_cluster>
    BalancerMember http://shared-backend1.example.com:8080
    BalancerMember http://shared-backend2.example.com:8080
    ProxySet lbmethod=byrequests stickysession=JSESSIONID
</Proxy>

<Proxy balancer://another_shared_cluster>
    BalancerMember http://another-backend1.example.com:9000
    BalancerMember http://another-backend2.example.com:9000
    ProxySet lbmethod=bybusyness
</Proxy>

次に、メインの Apache 設定ファイルや VirtualHost 設定ファイルでこのファイルを Include します。

# httpd.conf または virtualhost.conf の内容

# 共通バランサー定義を読み込む
Include conf/extra/common_balancers.conf

<VirtualHost *:80>
    ServerName app1.example.com
    DocumentRoot /var/www/app1

    # 読み込まれた shared_cluster を使用
    ProxyPass /common_path/ balancer://shared_cluster/
    ProxyPassReverse /common_path/ balancer://shared_cluster/

    ErrorLog ${APACHE_LOG_DIR}/app1_error.log
    CustomLog ${APACHE_LOG_DIR}/app1_access.log combined
</VirtualHost>

<VirtualHost *:80>
    ServerName app2.example.com
    DocumentRoot /var/www/app2

    # 読み込まれた another_shared_cluster を使用
    ProxyPass /api/ balancer://another_shared_cluster/
    ProxyPassReverse /api/ balancer://another_shared_cluster/

    ErrorLog ${APACHE_LOG_DIR}/app2_error.log
    CustomLog ${APACHE_LOG_DIR}/app2_access.log combined
</VirtualHost>

mod_rewrite と [P] フラグを使用する（より柔軟なパスマッピングが必要な場合）

mod_rewrite は非常に強力なモジュールで、正規表現を使った複雑なURL書き換えが可能です。[P] (proxy) フラグと組み合わせることで、動的なプロキシルーティングを実現できます。これは、バランサーへのルーティングだけでなく、パスの変換にも利用できます。

利点

特定の条件（リクエストヘッダ、IPアドレスなど）に基づいて異なるバランサーやバックエンドにルーティングできる。
非常に柔軟なURLマッピングとルーティングが可能。

欠点

ProxyPassReverse の機能の一部（リダイレクトヘッダの書き換えなど）を RewriteRule で再現する必要がある場合がある。
mod_rewrite の処理オーバーヘッドが発生する可能性がある（通常は小さい）。
設定が複雑になりがちで、デバッグが難しい。

コード例

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html

    RewriteEngine On

    # バランサーの定義は通常通り行います
    <Proxy balancer://my_cluster>
        BalancerMember http://backend1.example.com:8080 route=A
        BalancerMember http://backend2.example.com:8080 route=B
        ProxySet lbmethod=byrequests
    </Proxy>

    <Proxy balancer://special_cluster>
        BalancerMember http://special_backend1.example.com:9000 route=X
        BalancerMember http://special_backend2.example.com:9000 route=Y
        ProxySet lbmethod=bytraffic
    </Proxy>

    # 特定のパス（/api/）は special_cluster にルーティング
    RewriteRule ^/api/(.*)$ balancer://special_cluster/$1 [P,L]
    # ProxyPassReverse の代替（リダイレクトヘッダの書き換え）
    ProxyPassReverse /api/ balancer://special_cluster/

    # それ以外の /app/ のリクエストは my_cluster にルーティング
    RewriteRule ^/app/(.*)$ balancer://my_cluster/$1 [P,L]
    ProxyPassReverse /app/ balancer://my_cluster/

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

解説

ProxyPassReverse は、バックエンドからのリダイレクトヘッダを書き換えるために引き続き使用します。RewriteRule で動的にパスを渡す場合でも、ProxyPassReverse は静的なパスを指定する必要があります。
[L] フラグは、このルールが適用されたらそれ以上のルールは処理しないことを意味します。
RewriteRule の [P] フラグは ProxyPass と同様にプロキシをトリガーします。

mod_proxy_express を使用する（大規模な動的プロキシ）

もし非常に多数のホスト名を動的にバックエンドにマッピングする必要がある場合、mod_proxy_express が代替手段として考えられます。これは、DBMファイルに保存されたマップに基づいて、Host: ヘッダをバックエンドURLにマッピングします。BalancerInherit とは直接的な関係はありませんが、大規模なプロキシ設定における管理の選択肢として挙げられます。

利点

動的なマッピングにより、設定変更なしに多くのバックエンドに対応できる。
ホスト名とバックエンドの大量のマッピングを静的な設定ファイルに記述する必要がない。

欠点

DBM ファイルの管理が必要になる。
mod_proxy_balancer のような高度なロードバランシング機能は提供しない（ただし、バックエンドURLをバランサーURLに指定することは可能）。

コード例 (概念)

# httpd.conf または virtualhost.conf の内容

LoadModule proxy_express_module modules/mod_proxy_express.so

# ホスト名とバックエンドURLのマッピングを記述したDBMファイルを指定
ProxyExpressDBMFile /etc/apache2/express_map
ProxyExpressEnable on

# DBMファイルの内容例 (host:backend_url)
# api.example.com:balancer://api_cluster/
# app.example.com:balancer://main_cluster/

BalancerInherit は、設定の継承という形でバランサー定義の再利用を可能にしますが、その代替方法としては以下の選択肢があります。

mod_proxy_express
大規模な動的ホストベースのプロキシマッピングが必要な場合に検討します。
mod_rewrite と [P] フラグ
複雑な条件に基づいて動的にルーティングを制御したい場合に強力です。
Include ディレクティブ
複数のコンテナで全く同じバランサー定義を再利用したい場合に便利です。
個別定義
シンプルな構成や独立したバランサーが必要な場合に適しています。

Apache HTTP Serverでリバースプロキシを構築：mod_proxyとの設定例

mod_proxy は Apache HTTP Server のモジュールで、HTTP リクエストを別のサーバー（バックエンドサーバー）に転送する、つまり「プロキシ」として機能するための機能を提供します。このプロキシ機能の設定において、<Proxy> ディレクティブはプロキシの対象となる URL パスを定義し、そのパスに対するプロキシの挙動を制御するために使用されます。

Apacheの「Expect: 100-continue」問題を解決！Proxy100Continue設定とトラブルシューティング

Proxy100Continueは、Apache HTTP Serverのmod_proxyモジュールで使用されるディレクティブです。これは、クライアントが送信する「Expect: 100-continue」HTTPヘッダーの扱いを制御します。

Apache mod_proxy: ProxyAddHeaders徹底解説 - リバースプロキシでのヘッダ転送

ProxyAddHeaders は Apache HTTP Server の mod_proxy モジュールが提供するディレクティブの一つです。このディレクティブは、リバースプロキシとして動作している Apache がバックエンドのサーバ（オリジンサーバ）にリクエストを転送する際に、特定のリクエストヘッダを自動的に追加するかどうかを制御します。

もう悩まない！ProxyBadHeaderエラー回避のためのバックエンドプログラミング

具体的には、以下のような状況でこのエラーが発生することがあります。バックエンドサーバーの応答の問題: バックエンドサーバー自体が、予期せぬ、または破損したHTTPレスポンスを返している場合。これは、バックエンドアプリケーションのバグ、あるいはネットワークの問題によるデータの破損が原因であることもあります。

Apache ProxyBlockとProxyAllow：効果的なアクセス制限の設定

「mod_proxy: ProxyBlock」は、Apache HTTP Serverのmod_proxyモジュールが提供するディレクティブの一つです。このディレクティブは、Apacheがプロキシとして動作する際に、特定のホストやドメインへのアクセスを拒否（ブロック）するために使用されます。

mod_proxy: ProxyDomain

ProxyDomainは、Apache HTTP Serverのmod_proxyモジュールでかつて使用されていたディレクティブです。現在では非推奨 (deprecated) となっており、ほとんどの場合、使用すべきではありません。このディレクティブの目的は、プロキシされたリクエストのHTTPヘッダーにあるHostヘッダーを、指定されたドメイン名に書き換えることでした。具体的には、Apacheがリバースプロキシとして機能し、バックエンドのアプリケーションサーバーにリクエストを転送する際に、リクエストが本来意図していたドメイン名をバックエンドサーバーに伝えるために使われました。