【Apache】ProxyErrorOverrideのトラブルシューティング完全ガイド - よくあるエラーと解決策

2025-05-27

ProxyErrorOverride は、Apache HTTP Server の mod_proxy モジュールで使用されるディレクティブです。これは、Apache がリバースプロキシとして機能している際に、バックエンドサーバー（プロキシの先に存在する実際のWebアプリケーションサーバーなど）からエラー応答（例: 404 Not Found, 500 Internal Server Error など）が返された場合の Apache の挙動を制御します。

役割

通常、リバースプロキシとして動作するApacheは、バックエンドサーバーからの応答をそのままクライアントに転送します。これには、バックエンドサーバーが生成したカスタムエラーページも含まれます。

しかし、ProxyErrorOverride On を設定すると、バックエンドサーバーからエラー応答が返された場合、Apache はそのエラー応答を無視し、Apache 自身が設定しているエラーページ（ErrorDocument ディレクティブで指定されたもの）をクライアントに返すようになります。

逆に、ProxyErrorOverride Off (デフォルトの挙動) の場合、Apache はバックエンドサーバーからのエラー応答をそのままクライアントに転送します。

設定例

<VirtualHost *:80>
    ServerName example.com
    ProxyPass / http://backend.example.com/
    ProxyPassReverse / http://backend.example.com/

    # バックエンドからエラーが返された場合、Apacheのエラーページを表示
    ProxyErrorOverride On

    # 404 Not Found の場合、カスタムエラーページを表示
    ErrorDocument 404 /custom_404.html
    # 500 Internal Server Error の場合、カスタムエラーページを表示
    ErrorDocument 500 /custom_500.html

    # その他の設定...
</VirtualHost>

この例では、ProxyErrorOverride On が設定されているため、http://backend.example.com/ から 404 や 500 のエラーが返された場合、Apache は /custom_404.html や /custom_500.html といった、Apache サーバー上に存在するエラーページをクライアントに表示します。もし ProxyErrorOverride が Off のままであれば、バックエンドサーバーが返すエラーページがそのままクライアントに表示されます。

なぜこれが必要なのか？

ProxyErrorOverride を使用する主な理由は以下の通りです。

一貫したエラーページ表示: 複数のバックエンドサーバーがある場合や、バックエンドサーバーが異なるエラーページを生成する場合でも、クライアントには一貫したデザインのエラーページを表示できます。
情報漏洩の防止: バックエンドサーバーのエラーページには、サーバーの内部情報やスタックトレースなどが含まれている場合があります。ProxyErrorOverride を使用することで、これらの情報をクライアントに直接公開することを防ぐことができます。
メンテナンス性の向上: エラーページの管理をApacheサーバー側で一元化できるため、バックエンドアプリケーションの変更に依存せずにエラーページを更新できます。

注意点

ErrorDocument ディレクティブを適切に設定しないと、デフォルトのApacheエラーページが表示されることになります。
ProxyErrorOverride On を設定すると、バックエンドサーバーが提供するオリジナルのエラーメッセージやコンテンツは失われ、Apache が生成するエラーページに置き換えられます。そのため、バックエンドアプリケーションがエラー時にクライアントに特定の情報を伝えたい場合などには注意が必要です。

ProxyErrorOverride が関係する問題は、主に「期待通りのエラーページが表示されない」「エラーが発生しているのに、それがApacheのログに適切に記録されない」といったケースが多いです。

バックエンドのエラーページがそのまま表示されてしまう

症状
ProxyErrorOverride On を設定しているにもかかわらず、バックエンドサーバーから返されたエラーページ（例: アプリケーション固有の404ページ、データベースエラーメッセージを含む500ページなど）がクライアントに表示されてしまう。

考えられる原因とトラブルシューティング

バックエンドサーバーからの応答がエラーではない場合
バックエンドサーバーがHTTPステータスコード200 (OK) を返しつつ、実際にはエラーコンテンツを返している場合、Apacheはそれを正常な応答と見なし、ProxyErrorOverride は発動しません。これはアプリケーションレベルのエラーであり、Apacheのプロキシ設定では制御できません。
- 確認点
  バックエンドサーバーのログを確認し、どのようなHTTPステータスコードを返しているかを確認します。また、curl -I http://your_backend_server/error_path のように直接バックエンドにリクエストを送り、HTTPステータスを確認します。
- 解決策
  バックエンドアプリケーション側で、エラー時に適切なHTTPステータスコード（例: 404, 500など）を返すように修正する必要があります。
ProxyErrorOverride の適用範囲の誤り
ProxyErrorOverride が意図したVirtualHostやDirectory, Locationブロックに適用されていない可能性があります。
- 確認点
  ProxyErrorOverride On が適切なコンテキスト（例: <VirtualHost>, <Location>, <Directory>) 内に記述されているか確認します。特に複数のVirtualHostが存在する場合、適切なVirtualHostに設定されているか重要です。
- 解決策
  設定ファイルを見直し、ディレクティブの配置を修正します。
モジュールの未ロード
mod_proxy および mod_proxy_http モジュールがロードされていないと、プロキシ機能自体が動作しません。
- 確認点
  httpd.conf で LoadModule proxy_module modules/mod_proxy.so および LoadModule proxy_http_module modules/mod_proxy_http.so がコメントアウトされておらず、正しくロードされているか確認します。
- 解決策
  必要に応じてコメントを解除し、Apacheを再起動します。
ErrorDocument ディレクティブの未設定または誤設定
ProxyErrorOverride On は、Apacheが独自のエラーページを返すように指示しますが、具体的にどのページを返すかは ErrorDocument ディレクティブで指定する必要があります。
- 確認点
  httpd.conf や VirtualHost 設定ファイル内で、対象となるエラーコード（例: ErrorDocument 404 /custom_404.html, ErrorDocument 500 /custom_500.html）が正しく設定されているか確認します。
- 解決策
  適切な ErrorDocument ディレクティブを追加または修正し、指定されたエラーページがApacheサーバー上に存在し、アクセス可能であることを確認します。

エラーログに詳細が出力されない

症状
ProxyErrorOverride On を使用している場合、バックエンドサーバーでエラーが発生しても、Apacheのエラーログには一般的なプロキシエラーしか記録されず、具体的なバックエンド側のエラー情報が不足している。

考えられる原因とトラブルシューティング

バックエンドサーバーのログが確認されていない
ProxyErrorOverride が発動するということは、バックエンドサーバーで何らかのエラーが発生していることを意味します。Apache側では、あくまでバックエンドからのエラー応答をキャッチして処理しているだけなので、根本的な原因はバックエンドにあります。
- 確認点
  バックエンドサーバー（アプリケーションサーバー、データベースサーバーなど）のログを詳細に確認します。そこに、なぜエラーが返されたのかの具体的な原因が記載されているはずです。
- 解決策
  バックエンドサーバーのログを分析し、アプリケーションの修正やサーバー設定の見直しを行います。
Apacheのログレベルが低い
Apacheのログレベルが warn や error などに設定されている場合、詳細なデバッグ情報は出力されません。
- 確認点
  httpd.conf の LogLevel ディレクティブが debug や info に設定されているか確認します（一時的に設定して問題の再現後に戻すことを推奨）。
- 解決策
  LogLevel debug に設定し、Apacheを再起動してエラーを再現させ、ログを再度確認します。これにより、プロキシ通信に関するより詳細な情報が得られることがあります。

ProxyErrorOverride が On に設定されているのに、SSI (Server Side Includes) がエラーメッセージを取り込めない

考えられる原因とトラブルシューティング

ProxyErrorOverride の仕様
Apacheの公式ドキュメントにも記載がありますが、ProxyErrorOverride On の場合、バックエンドからのエラー応答は基本的に破棄され、Apacheが生成するエラーページに置き換えられます。そのため、バックエンドが生成したエラーページの具体的な内容（ボディ）をSSIで取り込むことはできません。SSIエラーが発生するか、単に何も表示されないかのどちらかになります。
- 確認点
  この挙動は ProxyErrorOverride の設計上のものです。
- 解決策
  バックエンドからのエラー情報をApacheのエラーページに取り込みたい場合は、ProxyErrorOverride を使用するのではなく、バックエンドアプリケーション自身でエラーページを生成し、そのエラーページに必要な情報を表示するように変更する必要があります。あるいは、Apacheがプロキシする前に、バックエンドからの応答を別の方法（例: mod_substitute や mod_perl/mod_python などでプロキシ応答を加工する）で加工する複雑な設定を検討する必要がありますが、これは推奨されません。シンプルに、バックエンドでエラーページを生成し、その中に表示すべき情報を盛り込むのが一般的です。

パフォーマンスの低下 (まれなケース)

症状
ProxyErrorOverride On を設定してから、特にエラー発生時にApacheの応答速度がわずかに低下したように感じる。

考えられる原因とトラブルシューティング

ErrorDocument のコンテンツが重い
ErrorDocument で指定されたカスタムエラーページが非常に多くのリソース（大きな画像、多数のCSS/JSファイルなど）を含んでいる場合、Apacheがそれをロードしてクライアントに返す際にわずかなオーバーヘッドが生じる可能性があります。
- 確認点
  カスタムエラーページのサイズと含まれるリソースを確認します。
- 解決策
  エラーページはできるだけ軽量に保つことが推奨されます。

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

Apacheのログを確認する
まずは ErrorLog と CustomLog を確認します。LogLevel debug に設定することで、より詳細な情報を得ることができます。
バックエンドサーバーのログを確認する
エラーの原因がバックエンドにあることが多いため、バックエンドサーバーのログ（アプリケーションログ、データベースログなど）は非常に重要です。
ProxyErrorOverride を Off にして比較する
一時的に ProxyErrorOverride Off に設定し、バックエンドからのエラーがそのまま表示されるかを確認します。これにより、問題が ProxyErrorOverride 自体の設定によるものなのか、それともバックエンドの問題なのかを切り分けやすくなります。
設定ファイルの構文チェック
Apacheの設定を変更した後は、必ず apachectl configtest または httpd -t で構文エラーがないか確認します。
Apacheを再起動する
設定変更はApacheの再起動 (sudo systemctl restart apache2 または sudo apachectl restart) によって適用されます。

ProxyErrorOverride は、バックエンドサーバーからのエラー応答をApacheが自身のカスタムエラーページに置き換えるためのディレクティブです。この機能を利用するには、Apacheのメイン設定ファイル（通常 httpd.conf）またはVirtualHost設定ファイル（sites-available ディレクトリ内のファイルなど）を編集します。

事前準備

mod_proxy および mod_proxy_http モジュールの有効化: ProxyErrorOverride を使用するには、これらのモジュールが有効になっている必要があります。Apacheのインストールによってはデフォルトで有効になっていることもありますが、そうでない場合は以下のコマンドで有効化し、Apacheを再起動します。
```
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo systemctl restart apache2 # または httpd, service httpd restart など
```

カスタムエラーページの作成: Apacheがバックエンドのエラーを上書きして表示するカスタムエラーページを作成します。これらのファイルはApacheの DocumentRoot 以下に配置するのが一般的です。

例: /var/www/html/error_pages/ ディレクトリに以下のファイルを作成します。

/var/www/html/error_pages/custom_404.html
/var/www/html/error_pages/custom_500.html

custom_404.html の内容例

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>ページが見つかりません - 404 Not Found</title>
    <style>
        body { font-family: sans-serif; text-align: center; margin-top: 50px; }
        h1 { color: #cc0000; }
    </style>
</head>
<body>
    <h1>404 Not Found</h1>
    <p>お探しのページは見つかりませんでした。</p>
    <p>URLが正しいかご確認ください。</p>
    <p><a href="/">トップページに戻る</a></p>
    </body>
</html>

custom_500.html の内容例

<!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>サーバー内部エラー - 500 Internal Server Error</title>
    <style>
        body { font-family: sans-serif; text-align: center; margin-top: 50px; }
        h1 { color: #cc0000; }
    </style>
</head>
<body>
    <h1>500 Internal Server Error</h1>
    <p>サーバーで予期せぬエラーが発生しました。</p>
    <p>しばらくしてから再度お試しください。</p>
    <p><a href="/">トップページに戻る</a></p>
</body>
</html>

設定例 1: 基本的なプロキシとエラー上書き

この例では、example.com への全てのアクセスを http://backend.internal:8080/ にプロキシし、バックエンドからエラーが返された場合にApache自身のカスタムエラーページを表示します。

# /etc/apache2/sites-available/example.com.conf (Debian/Ubuntu系)
# または /etc/httpd/conf/httpd.conf (CentOS/RHEL系) の VirtualHost ブロック内

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

    DocumentRoot /var/www/html

    # プロキシ設定
    ProxyPass / http://backend.internal:8080/
    ProxyPassReverse / http://backend.internal:8080/

    # ProxyErrorOverride を有効にする
    # これにより、バックエンドからのエラー応答（4xx, 5xx）はApacheが処理する
    ProxyErrorOverride On

    # カスタムエラーページの指定
    # DocumentRootからの相対パス、または絶対パスで指定
    ErrorDocument 400 /error_pages/custom_400.html
    ErrorDocument 403 /error_pages/custom_403.html
    ErrorDocument 404 /error_pages/custom_404.html
    ErrorDocument 500 /error_pages/custom_500.html
    ErrorDocument 502 /error_pages/custom_502.html # Bad Gateway
    ErrorDocument 503 /error_pages/custom_503.html # Service Unavailable (バックエンドがダウンしている場合など)
    ErrorDocument 504 /error_pages/custom_504.html # Gateway Timeout

    # その他の設定
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    <Directory /var/www/html/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

解説

ErrorDocument XXX /path/to/custom_xxx.html: 各HTTPステータスコードに対して、Apacheが返すカスタムエラーページのパスを指定します。ここで指定されたページが、ProxyErrorOverride On の場合にクライアントに表示されます。
ProxyErrorOverride On: これが最も重要なディレクティブで、バックエンドサーバーからのエラー応答（HTTPステータスコードが4xxまたは5xxの場合）をApacheが捕捉し、独自の処理を行うように指示します。
ProxyPassReverse / http://backend.internal:8080/: バックエンドから返される Location: ヘッダーを example.com ドメインに書き換えます。
ProxyPass / http://backend.internal:8080/: example.com への全てのリクエストを http://backend.internal:8080/ へ転送します。

設定例 2: 特定のパスのみ `ProxyErrorOverride` を適用する

特定のパス（例: /api/）にのみプロキシのエラー上書きを適用し、それ以外のパスではバックエンドのエラーをそのまま返す、というような細かな制御は、ProxyErrorOverride がVirtualHost、Directory、Locationブロックのコンテキストで設定できることを利用して実現できます。

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

    DocumentRoot /var/www/html/api_public

    # デフォルトではProxyErrorOverrideはOff（バックエンドのエラーをそのまま返す）
    # ProxyErrorOverride Off # これはデフォルトなので明示的に書かなくても良い

    # APIパスへのプロキシ
    <Location /v1/>
        ProxyPass http://backend-api.internal:8081/v1/
        ProxyPassReverse http://backend-api.internal:8081/v1/
        # このLocationブロック内でのみProxyErrorOverrideをOnにする
        ProxyErrorOverride On

        # このLocationブロックに特化したエラーページを指定することも可能
        # ErrorDocument 500 /error_pages/api_500.html
    </Location>

    # その他、静的ファイルなどを提供する部分
    <Directory /var/www/html/api_public/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/api_error.log
    CustomLog ${APACHE_LOG_DIR}/api_access.log combined
</VirtualHost>

解説

VirtualHostレベルで ProxyErrorOverride Off を明示的に記述することもできますが、これはデフォルトの挙動なので通常は不要です。
この例では、ProxyErrorOverride を<Location /v1/> ブロック内に配置することで、/v1/ へのリクエストがバックエンドでエラーになった場合にのみApacheがエラーページを上書きするようになります。

設定例 3: SSL/TLS (HTTPS) でのリバースプロキシとエラー上書き

HTTPSでプロキシする場合も基本は同じですが、SSLモジュール（mod_ssl）の有効化と証明書の設定が必要です。

# /etc/apache2/sites-available/secure.example.com-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName secure.example.com

    DocumentRoot /var/www/html/secure_public

    # SSL/TLS設定
    SSLEngine On
    SSLCertificateFile /etc/ssl/certs/secure.example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/secure.example.com.key
    # SSLCertificateChainFile (中間証明書がある場合)

    # プロキシ設定
    ProxyPass / https://backend-secure.internal:8443/
    ProxyPassReverse / https://backend-secure.internal:8443/

    # ProxyErrorOverride を有効にする
    ProxyErrorOverride On

    # カスタムエラーページの指定
    ErrorDocument 404 /error_pages/custom_404.html
    ErrorDocument 500 /error_pages/custom_500.html
    # 他のエラーコードも必要に応じて追加

    # その他の設定
    ErrorLog ${APACHE_LOG_DIR}/secure_error.log
    CustomLog ${APACHE_LOG_DIR}/secure_access.log combined

    <Directory /var/www/html/secure_public/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
</IfModule>

解説

ProxyErrorOverride On の動作はHTTPの場合と同じです。
ProxyPass と ProxyPassReverse でプロトコルを https:// に、ポートをバックエンドのHTTPSポート（例: 8443）に設定します。
SSLEngine On や SSLCertificateFile, SSLCertificateKeyFile など、HTTPSを有効にするための標準的な設定が含まれています。

設定後の確認と注意点

構文チェック: 設定ファイルを変更した後は、必ずApacheの構文チェックを実行してください。
```
sudo apachectl configtest
# または
sudo httpd -t
```
Syntax OK と表示されれば問題ありません。
Apacheの再起動: 設定変更を適用するには、Apacheを再起動する必要があります。
```
sudo systemctl restart apache2
# または
sudo service httpd restart
```
テスト: 実際にバックエンドサーバーを停止させるなどしてエラーを発生させ、Apacheが意図したカスタムエラーページを表示するかどうかを確認してください。
バックエンドのエラーログ: ProxyErrorOverride On にしても、バックエンドサーバーのログには通常通りエラーが記録されます。トラブルシューティングの際は、Apacheのログだけでなく、バックエンドサーバーのログも合わせて確認することが重要です。

バックエンドアプリケーション側でのエラーハンドリング

最も根本的な代替策は、バックエンドのWebアプリケーション自身で全てのエラーを処理し、Apacheがプロキシとしてその応答をそのまま転送するという方法です。

メリット

情報量
バックエンドで発生したエラーに関するより詳細な情報（スタックトレース、カスタムエラーコードなど）をログに出力したり、必要に応じてユーザーに表示したりできます。
一貫性
アプリケーション全体でエラーページの見た目や挙動を一貫させやすくなります。
柔軟性
アプリケーションのロジックに基づいて、非常に詳細で動的なエラーページを生成できます。例えば、エラーの内容、ユーザーのセッション情報、デバッグ情報（開発環境のみ）などをエラーページに含めることができます。

デメリット

バックエンドがダウンした場合
バックエンドサーバー自体が起動していない、または応答不能な状態の場合、この方法ではエラーページを生成できません。Apacheは503 Service Unavailableなどのエラーを返しますが、これはApacheのデフォルトまたは ErrorDocument で指定されたものになります。
セキュリティリスク
不用意に詳細なエラー情報をユーザーに表示してしまうと、情報漏洩のリスクがあります。本番環境では、一般的なエラーメッセージに留めるなどの配慮が必要です。
開発コスト
全てのエラーケースに対してアプリケーション側でエラーページを実装する必要があります。

設定例 (Apache側)
Apacheの設定は非常にシンプルで、ProxyErrorOverride Off (デフォルト) または記述しない状態です。

<VirtualHost *:80>
    ServerName example.com
    ProxyPass / http://backend.example.com/
    ProxyPassReverse / http://backend.example.com/

    # ProxyErrorOverride は Off (デフォルト) なので、バックエンドのエラーをそのまま転送する
    # ErrorDocument はApache自身のエラー（プロキシできない場合など）にのみ適用される
    ErrorDocument 503 /maintenance.html # バックエンドが全く応答しない場合にApacheが返すページ
</VirtualHost>

プログラミング例 (バックエンドアプリケーション - PHPの場合)

<?php
// 例: 存在しないパスへのアクセス
if (!file_exists($_SERVER['DOCUMENT_ROOT'] . $_SERVER['REQUEST_URI'])) {
    http_response_code(404);
    echo '<!DOCTYPE html><html><head><title>404 Not Found (App)</title></head><body>';
    echo '<h1>お探しのページは見つかりませんでした (アプリケーション)</h1>';
    echo '<p>申し訳ありませんが、指定されたリソースは見つかりません。</p>';
    echo '</body></html>';
    exit();
}

// 例: データベースエラーなどの内部サーバーエラー
try {
    // データベース処理など
    // ...
} catch (Exception $e) {
    http_response_code(500);
    error_log("Application Error: " . $e->getMessage()); // ログに出力
    echo '<!DOCTYPE html><html><head><title>500 Internal Server Error (App)</title></head><body>';
    echo '<h1>サーバー内部エラー (アプリケーション)</h1>';
    echo '<p>現在、システムに問題が発生しています。しばらくしてから再度お試しください。</p>';
    // 開発環境であれば $e->getMessage() などを表示しても良いが、本番では避ける
    echo '</body></html>';
    exit();
}

// 通常の処理
echo "Hello, world!";
?>

mod_rewrite と内部リダイレクトによるエラー処理

mod_rewrite を使用して、特定のHTTPステータスコードや条件に基づいて内部リダイレクトを行い、Apacheが管理するエラーページを表示する方法です。これは ProxyErrorOverride と似ていますが、より複雑な条件設定が可能です。

メリット

カスタムエラーページをApache側で一元管理できる。
ProxyErrorOverride よりも柔軟な条件でエラー処理をトリガーできる。

デメリット

ProxyErrorOverride と同様に、バックエンドが生成したエラーページのコンテンツをApacheのエラーページに取り込むことは難しい。
設定が複雑になりがち。

設定例

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

    # mod_rewrite を有効化
    RewriteEngine On

    # プロキシ設定
    ProxyPass / http://backend.example.com/
    ProxyPassReverse / http://backend.example.com/

    # バックエンドから特定のステータスコードが返された場合に内部リダイレクト
    # 例えば、バックエンドが404を返したら、Apacheの/custom_404.htmlに内部リダイレクト
    # 'P' フラグはProxyPassを意味するので、RewriteRuleとProxyPassを併用する場合は注意
    # このケースでは、プロキシされたリクエストに対するPOST_RESPONSE_STATUSが使える
    # ただし、POST_RESPONSE_STATUSはApache 2.4.x以降の比較的新しい機能
    
    # ここでは、バックエンドからのエラーを直接捕捉するRewriteRuleは難しい
    # 実際にはProxyErrorOverrideの方がシンプルで確実
    # 代替案としては、特定のURLパターンに対してのみProxyPassし、
    # それ以外のエラーはDocumentRoot配下の静的エラーページで処理する、というアプローチが現実的

    # 以下は概念的な例（直接的なProxyErrorOverrideの代替ではないが、柔軟なエラー処理の一例）
    # もしバックエンドが応答しない場合、Apacheが503を返し、それを捕捉
    RewriteCond %{ENV:REDIRECT_STATUS} ^503$
    RewriteRule ^.*$ /error_pages/custom_503.html [L]

    # ErrorDocument でカスタムエラーページを指定（RewriteRuleが適用されない場合も考慮）
    ErrorDocument 404 /error_pages/custom_404.html
    ErrorDocument 500 /error_pages/custom_500.html
    ErrorDocument 503 /error_pages/custom_503.html # バックエンドがダウンした場合など

    <Directory /var/www/html/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

注意点
mod_rewrite でプロキシされたリクエストのエラーを直接捕捉するのは非常に困難です。なぜなら、ProxyPass は RewriteRule の後に処理されることが多く、またバックエンドからの応答ステータスコードを RewriteRule が直接参照するような変数が限られているためです。ProxyErrorOverride はこの問題を解決するために導入されたものと考えるべきです。

もし mod_rewrite で代替するなら、以下のようなユースケースが考えられます。

バックエンドが応答しない場合に、Apacheが生成する5xx系のエラーを捕捉し、特別なメンテナンスページにリダイレクトする。
特定のURLパス（例: /admin/）へのアクセスのみをプロキシし、そのパス内でエラーが発生した場合はApacheのエラーページにリダイレクトする。

mod_status とカスタムスクリプト (より高度な監視と通知)

これは直接的なエラーページ表示の代替ではありませんが、バックエンドサーバーの稼働状況を監視し、障害発生時に自動的にエラーページを表示したり、管理者に通知したりする「プログラミング」的なアプローチです。

メリット

障害発生時に管理者への通知（メール、Slackなど）を自動化できる。
バックエンドサーバーのダウンタイムを検出し、即座に静的なメンテナンスページに切り替えるなど、動的な対応が可能。

デメリット

リアルタイム性に限界がある（ポーリング間隔に依存）。
設定が複雑で、外部スクリプトの作成やcronジョブの設定などが必要になる。

概念的な手順

mod_status の有効化
Apacheのステータス情報を取得できるようにします。
監視スクリプトの作成
PythonやShellスクリプトなどで、mod_status の出力やバックエンドサーバーのヘルスチェックエンドポイントを定期的にポーリングします。
状態に応じた設定変更
スクリプトがバックエンドの異常を検出した場合、Apacheの設定ファイル（例: ProxyPass をコメントアウトし、ErrorDocument 503 /maintenance.html のみ有効にする）を書き換え、Apacheをリロードまたは再起動します。
元に戻す処理
バックエンドが復旧したら、元の設定に戻す処理も実装します。

これは非常に複雑で、通常は専用のロードバランサー（Nginx, HAProxy, AWS ALB, GCP Load Balancer など）のヘルスチェック機能や、より高度なコンテナオーケストレーションツール（Kubernetesなど）のサービスディスカバリ・ヘルスチェック機能を使うのが一般的です。

外部のロードバランサーやAPIゲートウェイ

Apacheをシンプルにプロキシとしてのみ使用し、より高機能なエラーハンドリングやルーティングをロードバランサーやAPIゲートウェイに任せる方法です。

代表例

Traefik / Caddy
モダンなリバースプロキシで、動的な設定や自動証明書管理、エラーハンドリング機能を備えています。
AWS Application Load Balancer (ALB) / Google Cloud Load Balancer
クラウド環境でサービスを提供する際に、ヘルスチェックに基づいた自動的なトラフィックルーティングや、カスタムエラーページの表示が可能です。
HAProxy
高度なロードバランシングとヘルスチェック機能が特徴です。
Nginx
高性能なリバースプロキシ機能に加え、柔軟なエラーページ表示、レートリミット、キャッシュなどが可能です。

メリット

複雑なインフラでは、ApacheはWebサーバーとしての役割に徹し、プロキシ/エラー処理は専門のツールに任せることで責務分離ができる。
専用のツールであるため、エラーハンドリング設定がより強力で柔軟な場合が多い。
高可用性、スケーラビリティ、セキュリティなど、Apache単独では難しい高度な機能を実現できる。

デメリット

追加のサーバーやサービスが必要になり、コストが増加する場合がある。
インフラ構成が複雑になる。

Nginx の設定例 (エラーページ)

http {
    # ... その他の設定 ...

    server {
        listen 80;
        server_name example.com;

        # プロキシ設定
        location / {
            proxy_pass http://backend.example.com:8080/;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            # バックエンドからのエラー応答を捕捉し、Nginxのカスタムエラーページを返す
            proxy_intercept_errors on;
            error_page 404 /404.html;
            error_page 500 502 503 504 /50x.html;
        }

        # カスタムエラーページの場所を指定
        location = /404.html {
            root /usr/share/nginx/html; # Nginxのデフォルト静的ファイルパスなど
            internal; # 外部からの直接アクセスを禁止
        }

        location = /50x.html {
            root /usr/share/nginx/html;
            internal;
        }
    }
}

解説
Nginx の proxy_intercept_errors on; は Apache の ProxyErrorOverride On に相当します。これにより、バックエンドからのエラー応答をNginxが捕捉し、error_page ディレクティブで指定されたカスタムページを返します。internal; は、これらのエラーページがNginxの内部リダイレクトでのみアクセス可能であり、クライアントから直接リクエストできないようにします。

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

【Apache】ProxyErrorOverrideのトラブルシューティング完全ガイド - よくあるエラーと解決策

役割

設定例

なぜこれが必要なのか？

注意点

バックエンドのエラーページがそのまま表示されてしまう

エラーログに詳細が出力されない

ProxyErrorOverride が On に設定されているのに、SSI (Server Side Includes) がエラーメッセージを取り込めない

パフォーマンスの低下 (まれなケース)

事前準備

設定例 1: 基本的なプロキシとエラー上書き

設定例 2: 特定のパスのみ ProxyErrorOverride を適用する

設定例 3: SSL/TLS (HTTPS) でのリバースプロキシとエラー上書き

バックエンドアプリケーション側でのエラーハンドリング

mod_rewrite と内部リダイレクトによるエラー処理

mod_status とカスタムスクリプト (より高度な監視と通知)

外部のロードバランサーやAPIゲートウェイ

設定例 2: 特定のパスのみ `ProxyErrorOverride` を適用する