ProxyPassInheritに頼らないApacheプロキシ設定術：代替方法で柔軟なルーティングを実現

2025-05-26

ProxyPassInheritは、Apache HTTP Serverのmod_proxyモジュールが提供するディレクティブの一つです。Apache HTTP Server 2.4.5以降で利用可能です。

このディレクティブの主な機能は、メインサーバー（グローバルスコープ）で定義されたProxyPassディレクティブの設定を、その子となるバーチャルホストに継承させるかどうかを制御することです。

通常、バーチャルホスト内でProxyPassディレクティブを定義すると、メインサーバーで定義されたProxyPass設定はそのバーチャルホストには適用されません。しかし、ProxyPassInheritディレクティブを使用することで、このデフォルトの動作を変更できます。

設定値

ProxyPassInheritは、OnまたはOffを設定できます。

ProxyPassInherit Off: これがデフォルトの動作です。この設定をバーチャルホスト内で記述するか、または何も記述しない場合、そのバーチャルホストはメインサーバーのProxyPass設定を継承しません。バーチャルホスト内で定義されたProxyPassディレクティブのみが適用されます。
ProxyPassInherit On: この設定をバーチャルホスト内で記述すると、そのバーチャルホストはメインサーバー（グローバルスコープ）で定義されたすべてのProxyPassディレクティブの設定を「継承」します。つまり、メインサーバーとバーチャルホストの両方で定義されたProxyPassルールがそのバーチャルホストに適用されることになります。これは、予期せぬプロキシ動作を引き起こす可能性もあるため、注意が必要です。

なぜこのディレクティブが必要なのか？

大規模な環境でApacheを設定する場合、メインサーバーレベルで共通のプロキシ設定を行い、個々のバーチャルホストでその設定を上書きしたり、追加したりしたい場合があります。ProxyPassInheritは、このようなシナリオで柔軟性を提供します。

ただし、Apacheの公式ドキュメントでは、ProxyPassInherit Onを使用すると「問題や一貫性のない動作を引き起こす可能性がある」と警告しています。特に、動的な変更を行うBalancer Managerを使用している場合は、このディレクティブを無効（Off）にすることが推奨されています。これは、継承されたルールと動的な変更が競合する可能性があるためです。

使用例

# メインサーバーのコンテキスト (httpd.confなど)
ProxyPass "/app1" "http://backend-app1.example.com/"
ProxyPassInherit Off # グローバル設定。すべてのバーチャルホストに影響するデフォルトを設定

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

    # このバーチャルホストでは、メインサーバーのProxyPass設定は継承されない（ProxyPassInheritのデフォルトがOffのため）
    # ここで定義されたProxyPassのみが適用される
    ProxyPass "/myapp" "http://myapp-server.local/"
</VirtualHost>

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

    # このバーチャルホストでは、メインサーバーのProxyPass設定を継承する
    # 結果として、/app1 と /devapp の両方がこのバーチャルホストで有効になる
    ProxyPassInherit On
    ProxyPass "/devapp" "http://devapp-server.local/"
</VirtualHost>

上記の例では、www.example.com のバーチャルホストは、メインサーバーのProxyPass "/app1"を継承せず、自身のProxyPass "/myapp"のみを使用します。一方、dev.example.comのバーチャルホストはProxyPassInherit Onが設定されているため、メインサーバーのProxyPass "/app1"と自身のProxyPass "/devapp"の両方を使用します。

ProxyPassInherit は便利なディレクティブですが、その特性上、設定ミスや予期せぬ動作につながることがあります。

予期しないプロキシ動作・ルーティングの競合

エラー/症状

バーチャルホスト内で定義したProxyPassが機能しない、またはメインサーバーの設定が優先されてしまう。
複数のProxyPassルールが競合し、どれが適用されるか分かりにくい。
特定のURLパスへのリクエストが、意図しないバックエンドサーバーにプロキシされる。

原因

特に、メインサーバーに広範なProxyPass（例: /）があり、バーチャルホストで特定のパス（例: /app）を定義した場合、継承されるProxyPassが優先されてしまうことがあります。
ProxyPassInherit On が設定されているバーチャルホストで、メインサーバーのProxyPassディレクティブとバーチャルホスト自身のProxyPassディレクティブが同じパス（または重複するパス）を定義している場合、どちらが優先されるか不明瞭になることがあります。Apacheは設定ファイルの記述順序に基づいてProxyPassルールを評価するため、通常はより具体的なパスが先に記述されている必要がありますが、ProxyPassInheritが絡むと複雑化します。

トラブルシューティング

アクセスログとエラーログの確認
Apacheのアクセスログ（access_log）とエラーログ（error_log）を詳細に確認します。特に、リクエストがどのVirtualHostに到達し、どのProxyPassルールが適用されたかを示す情報がないか探します。デバッグレベルのログを有効にすると、より詳細なプロキシ処理の情報を得られる場合があります。
メインサーバーの設定のレビュー
メインサーバー（グローバルスコープ）に広範なProxyPass設定がある場合、それが予期せぬ継承を引き起こしていないか確認します。必要であれば、メインサーバーのProxyPassを削除するか、より限定的なものに変更します。
ProxyPassの順序の確認
ProxyPassディレクティブは、設定ファイル内でより具体的なパスから順に記述する必要があります。例えば、/app/sub が /app の前に来なければなりません。継承が絡む場合も、この原則を念頭に置いて全体の設定を評価する必要があります。
ProxyPassInherit Off の検討
ほとんどの場合、各バーチャルホストで必要なProxyPassディレクティブを明示的に定義し、ProxyPassInherit Off（デフォルト）を使用するのが最も安全で推奨される方法です。これにより、バーチャルホストの設定がメインサーバーの設定と独立して機能することを保証できます。

Balancer Managerとの競合

エラー/症状

Balancer Manager (ロードバランシングを動的に管理する機能) を使用している環境で、ProxyPassInherit On を設定すると、ロードバランサーのメンバーの状態が正しく更新されない、またはプロキシ動作が不安定になる。

原因

Apacheの公式ドキュメントでも警告されているように、ProxyPassInherit On は Balancer Manager を使用した動的な変更と競合する可能性があります。継承された設定と動的に追加・変更された設定が衝突し、一貫性のない動作を引き起こすためです。

トラブルシューティング

ProxyPassInherit Off の設定 (必須)
Balancer Manager を使用する場合は、必ず ProxyPassInherit Off を設定してください。これにより、各バーチャルホストが自身のプロキシ設定のみを管理し、動的な変更との競合を防ぐことができます。

503 Service Unavailable エラー

エラー/症状

プロキシされたリクエストが503 Service Unavailableエラーを返す。

原因（ProxyPassInheritに直接関連する場合）

複数のProxyPassルールが競合し、結果として有効なプロキシ先が見つからない場合。
ProxyPassInherit On が設定されているが、継承されたProxyPassディレクティブのバックエンドサーバーがダウンしている、または到達できない場合。

トラブルシューティング

Apacheエラーログの詳細確認
エラーログにmod_proxyからの具体的なエラーメッセージ（例: AH00957: HTTP: attempt to connect to ... failed, AH01114: HTTP: failed to make connection to backendなど）が出力されていないか確認します。これにより、接続の問題か、プロキシ先のURLの問題かを特定できます。
ProxyPassルールの確認
ProxyPassInherit On の有無にかかわらず、適用されるべきProxyPassルールが正しいバックエンドURLを指しているか、タイプミスがないかを確認します。
バックエンドサーバーの稼働確認
プロキシ先のバックエンドサーバーが正しく稼働しており、Apacheからネットワーク的に到達可能であることを確認します。

設定ファイルの構文エラー

エラー/症状

Apacheの起動またはリロード時に構文エラーが発生し、サーバーが起動しない。

原因

ProxyPassInheritはApache HTTP Server 2.4.5以降で導入されたディレクティブです。それ以前のバージョンで使用しようとすると構文エラーになります。

構文の確認
ディレクティブのスペルが正しいか、設定値（On/Off）が正しいかを確認します。
Apacheのバージョン確認
httpd -v または apachectl -v コマンドでApacheのバージョンを確認します。バージョンが2.4.5未満の場合は、このディレクティブは使用できません。

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

シンプルに始める
もし複雑なプロキシ設定で問題に直面しているなら、最もシンプルなProxyPass設定から始めて、段階的に複雑なルールを追加していくと、問題の切り分けがしやすくなります。
デバッグログの有効化
より詳細な情報を得るために、一時的にApacheのログレベルをdebugに設定することを検討してください（ただし、本番環境ではディスクスペースを大量に消費するため注意）。
ログファイル
Apacheのアクセスログ (access_log) とエラーログ (error_log) は、トラブルシューティングの最も重要な情報源です。特にエラーログは、何が問題なのかの具体的な手がかりを与えてくれます。
apachectl configtest または httpd -t
設定ファイルを変更した後は、必ずこのコマンドを実行して構文エラーがないか確認してください。

ProxyPassInherit ディレクティブは、Apache HTTP Server 2.4.5 以降で利用可能です。このディレクティブは、メインサーバー（グローバルコンテキスト）で定義された ProxyPass ディレクティブの設定を、その子となるバーチャルホストに継承させるかどうかを制御します。

デフォルトの動作 (ProxyPassInherit Off の場合)

ProxyPassInherit のデフォルト値は Off です。これは、バーチャルホストはメインサーバーの ProxyPass 設定を継承しないことを意味します。

設定例 (httpd.conf や extra/httpd-vhosts.conf など)

# --- メインサーバーのコンテキスト (グローバルスコープ) ---
# ここで定義されたProxyPassは、特別な指示がない限りバーチャルホストには継承されない
ProxyPass "/global-app" "http://global-backend.example.com/"
ProxyPassReverse "/global-app" "http://global-backend.example.com/"

# この行は明示的にデフォルト動作を示していますが、通常は不要です。
# ProxyPassInherit Off はグローバルスコープでの設定は意味がありません。
# バーチャルホスト内で効果を発揮します。

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

    # このバーチャルホストは、メインサーバーの '/global-app' 設定を継承しない
    # ここで定義されたProxyPassのみが適用される
    ProxyPass "/webapp" "http://webapp-server.example.com/"
    ProxyPassReverse "/webapp" "http://webapp-server.example.com/"

    # `/` へのリクエストは DocumentRoot にマッピングされる
    # (ProxyPassInherit Off のため、メインサーバーの '/global-app' は影響しない)
</VirtualHost>

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

    # このバーチャルホストも、メインサーバーの '/global-app' 設定を継承しない
    # ここで定義されたProxyPassのみが適用される
    ProxyPass "/data" "http://data-service.example.com/"
    ProxyPassReverse "/data" "http://data-service.example.com/"
</VirtualHost>

解説

結果として、www.example.com/global-app や api.example.com/global-app へのアクセスは、メインサーバーの /global-app にルーティングされず、これらのバーチャルホストの DocumentRoot にマッピングされるか、存在しないパスとして扱われます。
ProxyPassInherit がデフォルトの Off であるため、これらのバーチャルホストはメインサーバーの /global-app の設定を継承しません。
www.example.com と api.example.com の両方のバーチャルホストには、それぞれ独自の ProxyPass ディレクティブ (/webapp と /data) があります。
メインサーバーで /global-app へのプロキシが定義されています。

ProxyPassInherit On を使用して継承を有効にする場合

特定のバーチャルホストで、メインサーバーの ProxyPass 設定を継承させたい場合に ProxyPassInherit On を使用します。

設定例

# --- メインサーバーのコンテキスト (グローバルスコープ) ---
ProxyPass "/common-assets" "http://assets.example.com/"
ProxyPassReverse "/common-assets" "http://assets.example.com/"

ProxyPass "/admin-api" "http://admin-backend.example.com/"
ProxyPassReverse "/admin-api" "http://admin-backend.example.com/"

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

    # このバーチャルホストは、メインサーバーのProxyPass設定を継承しない (デフォルト)
    ProxyPass "/app-specific" "http://app-backend.example.com/"
    ProxyPassReverse "/app-specific" "http://app-backend.example.com/"
</VirtualHost>

<VirtualHost *:80>
    ServerName dev.myapp.com
    DocumentRoot "/var/www/html/dev"

    # ここでProxyPassInherit Onを設定すると、メインサーバーのProxyPassも適用される
    ProxyPassInherit On

    # このバーチャルホスト固有のProxyPass
    ProxyPass "/dev-app" "http://dev-backend.example.com/"
    ProxyPassReverse "/dev-app" "http://dev-backend.example.com/"

    # /admin-api のパスを上書きしたい場合（ただし、これは推奨されないパターン）
    # ProxyPass "/admin-api" "http://dev-admin-backend.example.com/"
    # ProxyPassReverse "/admin-api" "http://dev-admin-backend.example.com/"
    # 上記のように上書きすると、継承された設定が優先される場合とされない場合があり、
    # 混乱を招くため、ProxyPassInherit On の場合は上書きを避けるべきです。
</VirtualHost>

解説

結果として、dev.myapp.com では以下のパスがプロキシされます。
- dev.myapp.com/common-assets -> http://assets.example.com/
- dev.myapp.com/admin-api -> http://admin-backend.example.com/
- dev.myapp.com/dev-app -> http://dev-backend.example.com/
dev.myapp.com バーチャルホストには ProxyPassInherit On が設定されています。
- これにより、メインサーバーの /common-assets と /admin-api の設定がこのバーチャルホストに継承されます。
- さらに、バーチャルホスト固有の /dev-app のプロキシも適用されます。
www.myapp.com バーチャルホストは、ProxyPassInherit Off（デフォルト）であるため、/app-specific のみがプロキシされます。/common-assets や /admin-api はプロキシされません。
メインサーバーで /common-assets と /admin-api へのプロキシが定義されています。

ProxyPassInherit Off を明示的に記述する場合

通常はデフォルト動作なので不要ですが、設定の意図を明確にするためにバーチャルホスト内で明示的に ProxyPassInherit Off を記述することもあります。

設定例

# --- メインサーバーのコンテキスト ---
ProxyPass "/shared-service" "http://shared-service.example.com/"
ProxyPassReverse "/shared-service" "http://shared-service.example.com/"

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

    # このバーチャルホストは、メインサーバーのProxyPass設定を継承しないことを明示的に示す
    ProxyPassInherit Off

    # このバーチャルホスト固有のProxyPassのみが適用される
    ProxyPass "/api" "http://app1-api.example.com/"
    ProxyPassReverse "/api" "http://app1-api.example.com/"
</VirtualHost>

デフォルト動作と同じですが、設定ファイルを見たときに「このバーチャルホストは継承しない」という意図が明確になります。
これにより、メインサーバーの /shared-service はこのバーチャルホストには適用されず、/api のみがプロキシされます。
この例では、app1.example.com バーチャルホストで ProxyPassInherit Off を明示的に設定しています。

特に Balancer Manager を使用して動的なロードバランシングを行う場合は、ProxyPassInherit On は使用すべきではありません。動的な変更と継承された静的な設定が衝突し、問題が発生する可能性が高いです。
ProxyPassInherit On を使用する場合は、ProxyPass ルールの競合に特に注意が必要です。 メインサーバーとバーチャルホストの両方で同じパスが定義された場合、Apacheがどちらを優先するかは設定ファイルの記述順やApacheの内部的なルール評価に依存し、直感的でない動作を引き起こす可能性があります。
ProxyPassInherit On は、メインサーバーに「共通の」プロキシ設定があり、それを多くのバーチャルホストで共有したい場合に検討されます。
ほとんどのユースケースでは ProxyPassInherit Off (デフォルト動作) が推奨されます。 各バーチャルホストが必要なプロキシ設定を独自に持つ方が、設定の管理が容易で、予期せぬ動作を避けることができます。

ProxyPassInherit を使用せずに、同様の、またはより制御された方法でプロキシ設定を行うための代替手段について説明します。

ProxyPassInherit は、メインサーバーのプロキシ設定をすべて継承させるという、ある意味で「大ざっぱな」方法です。多くの場合、開発者は特定のプロキシ設定のみを適用したい、あるいはバーチャルホストごとに完全に独立したプロキシ設定を持ちたいと考えます。そのための代替手段は以下の通りです。

各バーチャルホストで必要な ProxyPass を明示的に定義する (推奨される方法)

これは最も一般的で推奨されるアプローチです。各 VirtualHost ブロック内で、そのバーチャルホストに必要な ProxyPass および ProxyPassReverse ディレクティブをすべて記述します。

利点

競合の回避
ProxyPassInherit On で発生しがちな予期せぬプロキシルーティングの競合を防げます。
トラブルシューティングの容易さ
問題が発生した場合、影響を受けるバーチャルホストの設定のみを確認すればよいため、デバッグが容易です。
独立性
各バーチャルホストの設定が他のバーチャルホストやメインサーバーの設定に影響されません。
明確性
各バーチャルホストが何をするかが一目で分かります。

コード例

# --- メインサーバーのコンテキスト (httpd.conf など) ---
# ここにはProxyPassディレクティブを記述しないか、
# フォワードプロキシ設定（ProxyRequests On）のようなグローバルなもののみを記述する
# 通常、リバースプロキシのProxyPassはバーチャルホスト内で定義する

# ProxyPass "/old-api" "http://old-api-server.example.com/" # このような設定は避ける

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

    # このバーチャルホストが必要とするプロキシ設定を明示的に記述
    ProxyPass "/app" "http://app-backend.example.com/"
    ProxyPassReverse "/app" "http://app-backend.example.com/"

    # もう一つのプロキシ設定
    ProxyPass "/cdn-assets" "http://cdn-server.example.com/"
    ProxyPassReverse "/cdn-assets" "http://cdn-server.example.com/"

    # 他のVirtualHostからの継承はしない (デフォルト動作)
    # ProxyPassInherit Off は明示的に記述しても良いが、通常は不要
</VirtualHost>

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

    # このバーチャルホストが必要とするプロキシ設定を明示的に記述
    ProxyPass "/v1" "http://api-v1-server.example.com/"
    ProxyPassReverse "/v1" "http://api-v1-server.example.com/"

    ProxyPass "/v2" "http://api-v2-server.example.com/"
    ProxyPassReverse "/v2" "http://api-v2-server.example.com/"
</VirtualHost>

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

複数のバーチャルホストで同じ ProxyPass 設定を共有したい場合、その共通設定を別のファイルに記述し、各バーチャルホストから Include ディレクティブで読み込むことができます。これは ProxyPassInherit On のような「すべて継承」ではなく、「必要な共通設定のみを読み込む」というより粒度の細かい制御を可能にします。

利点

明確な依存関係
どのファイルから設定が読み込まれているか明確です。
再利用性
複数のバーチャルホストで同じ設定を簡単に適用できます。
コードの重複削減
共通のプロキシ設定を一度記述すればよく、管理が容易です。

コード例

conf/common_proxy_settings.conf (共通設定ファイル)

# 共通で適用したいProxyPassディレクティブをここに記述
ProxyPass "/common-assets" "http://common-asset-server.example.com/"
ProxyPassReverse "/common-assets" "http://common-asset-server.example.com/"

# 必要であれば、別の共通プロキシも追加
# ProxyPass "/static-files" "http://static-file-server.example.com/"
# ProxyPassReverse "/static-files" "http://static-file-server.example.com/"

httpd-vhosts.conf (各バーチャルホストファイル)

# --- メインサーバーのコンテキスト ---
# ここにはProxyPassディレクティブを記述しない

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

    # 共通のプロキシ設定を読み込む
    Include /etc/httpd/conf/common_proxy_settings.conf

    # このバーチャルホスト固有のプロキシ設定
    ProxyPass "/api/v1" "http://app1-api-v1.example.com/"
    ProxyPassReverse "/api/v1" "http://app1-api-v1.example.com/"
</VirtualHost>

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

    # 共通のプロキシ設定を読み込む
    Include /etc/httpd/conf/common_proxy_settings.conf

    # このバーチャルホスト固有のプロキシ設定
    ProxyPass "/data" "http://app2-data-service.example.com/"
    ProxyPassReverse "/data" "http://app2-data-service.example.com/"
</VirtualHost>

mod_rewrite の [P] フラグを使用する

mod_rewrite モジュールは、リクエストURLの書き換えに非常に強力な機能を提供します。RewriteRule ディレクティブの [P] (Proxy) フラグを使用すると、書き換えられたURLに対して mod_proxy によるプロキシ処理を強制できます。これにより、より複雑な条件に基づいてプロキシ先を決定することができます。

利点

高度なルーティング
特定のヘッダー、クエリ文字列、IPアドレスなどに基づいてプロキシ先を動的に変更できます。
柔軟性
正規表現や条件（RewriteCond）を使用して、非常に柔軟なルーティングロジックを実装できます。

欠点

ProxyPassReverse の代替が必要
ProxyPassReverse の機能は mod_rewrite では提供されないため、別途 ProxyPassReverse や ProxyPassReverseCookieDomain などを使用するか、mod_substitute などでコンテンツを書き換える必要があります。
複雑さ
ProxyPass よりも設定が複雑になりがちで、デバッグも難しくなることがあります。

コード例

<VirtualHost *:80>
    ServerName rewrite-proxy.example.com
    DocumentRoot "/var/www/html/rewrite"

    RewriteEngine On
    ProxyRequests Off # リバースプロキシでは通常Offにする

    # /api/v1 へのリクエストをAPIサーバーへプロキシ
    RewriteRule "^/api/v1/(.*)$" "http://api-backend.example.com/v1/$1" [P,L]

    # /assets へのリクエストを別の資産サーバーへプロキシ
    RewriteRule "^/assets/(.*)$" "http://asset-cdn.example.com/$1" [P,L]

    # 上記のRewriteRuleでプロキシされたレスポンスヘッダーを書き換えるために必要
    ProxyPassReverse "/api/v1" "http://api-backend.example.com/v1/"
    ProxyPassReverse "/assets" "http://asset-cdn.example.com/"

    # 例: クエリパラメータ 'env=dev' がある場合のみ開発環境APIへプロキシ
    # RewriteCond %{QUERY_STRING} env=dev [NC]
    # RewriteRule "^/app-api/(.*)$" "http://dev-api-backend.example.com/$1" [P,L]

    # 開発環境でない場合、本番APIへプロキシ
    # RewriteRule "^/app-api/(.*)$" "http://prod-api-backend.example.com/$1" [P,L]
</VirtualHost>

ProxyPassMatch を使用する

ProxyPassMatch は ProxyPass の正規表現版です。これにより、URLパスのパターンマッチングをより柔軟に行い、キャプチャグループを使用してプロキシ先のURLを構築できます。これは mod_rewrite ほどではありませんが、ProxyPassInherit よりは特定のパスの制御に向いています。

利点

ProxyPass と同等の機能
ProxyPassReverse と組み合わせて使用できます。
正規表現による柔軟なパス指定
ProxyPass よりも詳細なパスマッチングが可能です。

コード例

<VirtualHost *:80>
    ServerName regex-proxy.example.com
    DocumentRoot "/var/www/html/regex"

    # /users/123 のようなパスをユーザーサービスへプロキシ
    ProxyPassMatch "^/users/([0-9]+)$" "http://user-service.example.com/profile/$1"
    ProxyPassReverse "/users/" "http://user-service.example.com/profile/" # Reverseも必要

    # /products/abc/detail のようなパスを製品サービスへプロキシ
    ProxyPassMatch "^/products/(.*)/(detail|info)$" "http://product-service.example.com/item/$1/$2"
    ProxyPassReverse "/products/" "http://product-service.example.com/item/" # Reverseも必要
</VirtualHost>

ProxyPassInherit は特定のシナリオで有用かもしれませんが、その継承の特性から意図しないプロキシ動作や競合を引き起こすリスクがあります。

ほとんどの場合、以下の代替手段がより推奨されます。

各バーチャルホストで明示的に ProxyPass を記述する
最もシンプルで明確なアプローチです。
Include ディレクティブで共通設定を共有する
コードの重複を避けつつ、制御された継承を実現します。
mod_rewrite の [P] フラグを使用する
最も柔軟性が高いですが、設定が複雑になります。
ProxyPassMatch を使用する
正規表現でパスをマッチングし、より柔軟なプロキシパスを定義します。

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がリバースプロキシとして機能し、バックエンドのアプリケーションサーバーにリクエストを転送する際に、リクエストが本来意図していたドメイン名をバックエンドサーバーに伝えるために使われました。