Apacheリバースプロキシの要！ProxyPassReverseCookieDomain徹底解説

2025-05-26

「ProxyPassReverseCookieDomain」とは何か？

このディレクティブは、Apacheがリバースプロキシとして機能する際に、バックエンド（オリジン）サーバーからクライアントへ返されるHTTPレスポンスのSet-Cookieヘッダーに含まれるドメイン属性を書き換えるために使用されます。

なぜ必要なのか？

リバースプロキシの一般的なシナリオでは、クライアントはApache（プロキシサーバー）にアクセスし、Apacheがそのリクエストをバックエンドサーバーに転送します。バックエンドサーバーは処理を行い、クライアントに返すレスポンスの中にセッション管理などのためにCookieを含めることがあります。

この時、バックエンドサーバーは自分自身のドメイン（例: backend.example.com）でCookieを発行します。しかし、クライアントはApacheのドメイン（例: public.example.com）でアクセスしているため、バックエンドサーバーのドメインが設定されたCookieを受け取っても、ブラウザはそのCookieをApacheのドメインに送信しません。これにより、セッションが維持できないなどの問題が発生します。

ProxyPassReverseCookieDomainは、この問題を解決するために、バックエンドサーバーが設定したCookieのドメイン属性を、クライアントがアクセスしているApacheのドメインに書き換えることで、クライアントが正しくCookieを扱い、セッションを維持できるようにします。

構文

ProxyPassReverseCookieDomain internal-domain public-domain [interpolate]

[interpolate]: (オプション) この引数を指定すると、public-domainで環境変数を使用できるようになります。
public-domain: クライアントがアクセスする（外部から見える）Apacheのドメイン名です。
internal-domain: バックエンドサーバーがCookieに設定する（内部的な）ドメイン名です。

例

例えば、以下のような設定が考えられます。

ProxyPass "/app/" "http://backend.example.com/app/"
ProxyPassReverse "/app/" "http://backend.example.com/app/"
ProxyPassReverseCookieDomain "backend.example.com" "public.example.com"

この設定では：

クライアントがhttp://public.example.com/app/にアクセスします。
Apacheはリクエストをhttp://backend.example.com/app/に転送します。
backend.example.comがCookieをSet-Cookie: JSESSIONID=abc; Domain=backend.example.comのように発行します。
Apacheはクライアントに返す際に、このCookieをSet-Cookie: JSESSIONID=abc; Domain=public.example.comのように書き換えます。

これにより、クライアントのブラウザはpublic.example.comに対して次回のリクエストからこのCookieを送信するようになり、リバースプロキシ環境下でもセッション管理が正常に機能するようになります。

バックエンドサーバーがCookieを発行しない場合は不要ですが、多くのWebアプリケーションではCookieを使用するため、通常は設定しておくことが推奨されます。
ProxyPassReverseCookieDomainは、ProxyPassReverseと同様に、リバースプロキシを使用する際にはほぼ必須のディレクティブと考えてよいでしょう。

ProxyPassReverseCookieDomain はリバースプロキシ環境でCookieのドメインを正しく書き換えるために不可欠なディレクティブですが、設定ミスや予期せぬ挙動により問題が発生することがあります。

Cookieが書き換えられない/セッションが維持されない

症状

アプリケーションが「セッション切れ」のエラーを返す。
ブラウザの開発者ツールでSet-Cookieヘッダーを確認すると、CookieのDomain属性がバックエンドのドメインのままになっている。
クライアントがバックエンドアプリケーションにログインしても、ページ遷移すると再度ログインを求められる。

原因

アプリケーション側のCookie設定
- バックエンドアプリケーションがCookieのドメインを厳密にチェックしており、Apacheによる書き換えを拒否している。
- バックエンドアプリケーションが、そもそもDomain属性を設定していない場合、Apacheは書き換えるべき対象がないため、このディレクティブは効果を発揮しません。
ブラウザのキャッシュ/Cookieの問題
- 古いCookieがブラウザに残っているため、新しい設定が反映されない。
SSL/TLS の問題
- Apacheとバックエンドサーバー間の通信がHTTPSの場合、またはクライアントとApache間の通信がHTTPSの場合、CookieのSecure属性やSameSite属性が正しく処理されていない可能性がある。
ProxyPassReverseCookieDomain の設定ミス
- internal-domain と public-domain の値が間違っている。特に、internal-domain はバックエンドサーバーが実際にCookieに設定しているドメインと完全に一致する必要があります。
- ProxyPassReverseCookieDomain ディレクティブがそもそも設定されていない。

トラブルシューティング

設定の確認
- httpd.conf や sites-enabled ディレクトリ内の設定ファイルを開き、ProxyPassReverseCookieDomain ディレクティブのスペル、引数の順序、値が正しいかを確認します。
- internal-domain は、実際にバックエンドサーバーが設定しているドメイン（例: backend.example.com）である必要があります。ブラウザの開発者ツールで、バックエンドから直接アクセスした場合のSet-Cookieヘッダーを確認し、Domainの値を確認してください。
- public-domain は、Apacheが公開しているドメイン（例: public.example.com）である必要があります。
Apacheの再起動/リロード
- 設定変更後は必ずApacheを再起動またはリロードします（例: sudo systemctl restart apache2 または sudo apachectl graceful）。
ブラウザのキャッシュクリア
- ブラウザのキャッシュとCookieをすべてクリアし、シークレットモード（プライベートブラウジング）でアクセスを試みます。
アクセスログとエラーログの確認
- Apacheのエラーログ（通常、/var/log/apache2/error.log や /var/log/httpd/error_log）にmod_proxy関連のエラーが出ていないか確認します。
- アクセスログ（通常、/var/log/apache2/access.log や /var/log/httpd/access_log）を確認し、リクエストが正しくバックエンドに転送されているか、またレスポンスコードが正常（200 OKなど）であるかを確認します。
ネットワークトラフィックの分析
- ブラウザの開発者ツール（[F12]キーで開く）の「Network」タブを使用し、HTTPリクエストとレスポンスを詳細に確認します。
- 特に、バックエンドからのSet-CookieヘッダーがApacheによってどのように書き換えられているかを監視します。Domain属性が正しく書き換えられているか、またPathやSecureなどの他の属性が期待通りかを確認します。
ProxyPassReverseCookiePath の確認
- もしURLパスの書き換えも行っている場合（例: /app を / にマッピングしている場合など）、ProxyPassReverseCookiePath も必要になることがあります。CookieのPath属性が問題の原因である可能性も考慮します。
ProxyPreserveHost On の影響
- ProxyPreserveHost On が設定されている場合、バックエンドサーバーにはクライアントからの元のHostヘッダーがそのまま渡されます。これにより、バックエンドアプリケーションが自身のドメインでCookieを発行する動作に影響を与えることは通常ありませんが、もしバックエンドがHostヘッダーに基づいて特別な処理を行っている場合は確認が必要です。

サブドメインを含むCookieの書き換え問題

症状

または、その逆で、先頭にドットが必要な場合に付与されない。
backend.example.com のCookieが、public.example.com ではなく、.public.example.com のように、先頭にドットが付いた形で書き換えられることがある。

原因

ProxyPassReverseCookieDomain の挙動は、Apacheのバージョンや内部的な実装によって、このドットの扱いが微妙に異なる場合があります。また、バックエンドアプリケーションが発行するCookieのDomain属性にドットが含まれているかどうかも影響します。
CookieのDomain属性の仕様では、先頭にドットが付いている場合（例: .example.com）はそのドメインとそのすべてのサブドメインでCookieが有効になります。先頭にドットがない場合（例: example.com）はそのドメインのみで有効になります。

トラブルシューティング

両方のパターンを試す
- ProxyPassReverseCookieDomain "backend.example.com" "public.example.com"
- ProxyPassReverseCookieDomain "backend.example.com" ".public.example.com"
- どちらの形式がアプリケーションの動作に合致するか、ブラウザの開発者ツールで確認しながら試行します。
バックエンドアプリケーションのCookie設定
- 可能であれば、バックエンドアプリケーション側でCookieのDomain属性の生成方法を調整できないか検討します。例えば、Domain属性を省略して、ブラウザが現在のホスト名に基づいて自動的に設定するようにすることも有効な場合があります。

複数のアプリケーション/パスでの問題

症状

あるパス (/app1) では動作するが、別のパス (/app2) では動作しない。
複数のアプリケーションを同じApacheリバースプロキシで公開している場合、一部のアプリケーションではCookieが正しく機能するが、他のアプリケーションでは機能しない。

原因

パスの競合/不一致
- ProxyPassReverseCookiePath の設定と合わせて考慮する必要がある場合。
- バックエンドアプリケーションがCookieを発行するパスと、Apacheがリバースプロキシしているパスとの間に不一致がある。
ProxyPassReverseCookieDomain の適用範囲
- ProxyPassReverseCookieDomain は、通常、VirtualHost または Location ブロック内に記述されますが、その適用範囲が意図したものと異なる場合があります。

Location ブロックでの詳細設定

アプリケーションごとに異なる設定が必要な場合は、Locationブロック内でProxyPassReverseCookieDomainを個別に指定します。

<Location "/app1/">
    ProxyPass "http://backend1.example.com/app1/"
    ProxyPassReverse "http://backend1.example.com/app1/"
    ProxyPassReverseCookieDomain "backend1.example.com" "public.example.com"
    # 必要に応じてProxyPassReverseCookiePathも
</Location>

<Location "/app2/">
    ProxyPass "http://backend2.example.com/app2/"
    ProxyPassReverse "http://backend2.example.com/app2/"
    ProxyPassReverseCookieDomain "backend2.example.com" "public.example.com"
</Location>

ProxyPassReverseCookiePath の確認
- ProxyPassReverseCookieDomain と同様に、ProxyPassReverseCookiePath もCookieのPath属性を書き換えます。これもセッション維持に影響を与えるため、正しく設定されているか確認します。
- 例: ProxyPassReverseCookiePath "/backend_path" "/public_path"

バックエンドサーバーの稼働状態
バックエンドサーバー自体が稼働しているか、期待するポートでリクエストをリッスンしているかを確認します。
SELinux/ファイアウォールの問題
Apacheサーバーがバックエンドサーバーに接続できない場合、SELinuxやファイアウォールの設定が原因である可能性があります。エラーログにPermission deniedやConnection refusedなどのメッセージが出ていないか確認し、必要に応じてSELinuxの許可設定やファイアウォールのルールを調整します。
モジュールの読み込み忘れ
mod_proxy および mod_proxy_http (HTTP/HTTPSの場合) がApacheにロードされているか確認します。
- LoadModule proxy_module modules/mod_proxy.so
- LoadModule proxy_http_module modules/mod_proxy_http.so

ProxyPassReverseCookieDomain ディレクティブは、Apache をリバースプロキシとして使用する際に、バックエンドサーバーから発行される Cookie のドメイン属性を書き換えるために利用されます。これにより、クライアントが Apache のドメインを介してアプリケーションにアクセスしても、セッションなどの情報が正しく維持されるようになります。

ここでは、一般的なシナリオにおける ProxyPassReverseCookieDomain の設定例をいくつかご紹介します。

基本的な設定例：単一のバックエンドアプリケーション

最も一般的なケースで、クライアントがアクセスする Apache のドメインと、バックエンドサーバーが Cookie に設定するドメインが異なる場合です。

# mod_proxy モジュール群がロードされていることを確認
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
# 必要であれば mod_ssl もロード

<VirtualHost *:80>
    ServerName public.example.com # クライアントがアクセスするApacheのドメイン

    # /app/ へのリクエストをバックエンドサーバーに転送
    ProxyPass "/app/" "http://backend.internal.com:8080/app/"
    # バックエンドからのリダイレクトURLを書き換え
    ProxyPassReverse "/app/" "http://backend.internal.com:8080/app/"

    # ここが重要: Cookieのドメインを書き換える設定
    # バックエンドが "backend.internal.com" で発行したCookieのDomainを
    # クライアントがアクセスする "public.example.com" に書き換える
    ProxyPassReverseCookieDomain "backend.internal.com" "public.example.com"

    ErrorLog ${APACHE_LOG_DIR}/public_example_com_error.log
    CustomLog ${APACHE_LOG_DIR}/public_example_com_access.log combined
</VirtualHost>

解説

ProxyPassReverseCookieDomain "backend.internal.com" "public.example.com":
- backend.internal.com: これは、バックエンドサーバーが発行する Set-Cookie ヘッダーに含まれる元の Domain 属性の値です。バックエンドアプリケーションが通常自身を識別するために使うドメイン名と一致させる必要があります。
- public.example.com: これは、Apache が Cookie の Domain 属性を書き換える新しい値です。クライアントが Apache にアクセスしているドメインと一致させることで、ブラウザがその Cookie を public.example.com に送信するようになります。
ProxyPassReverse "/app/" "http://backend.internal.com:8080/app/": バックエンドアプリケーションからのリダイレクト（例: ログイン後のリダイレクト）URL に backend.internal.com が含まれる場合、それを public.example.com に書き換えます。
ProxyPass "/app/" "http://backend.internal.com:8080/app/": public.example.com/app/ へのリクエストを backend.internal.com:8080/app/ へと転送します。
ServerName public.example.com: これは、ユーザーがウェブブラウザに入力する Apache のドメインです。

複数のバックエンドアプリケーションを扱う設定例

Apache を単一のエントリポイントとして、複数の異なるバックエンドアプリケーションにプロキシする場合の設定です。

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

    # アプリケーションA
    <Location "/app-a/">
        ProxyPass "http://backend-a.internal.com:8080/webapp-a/"
        ProxyPassReverse "http://backend-a.internal.com:8080/webapp-a/"
        ProxyPassReverseCookieDomain "backend-a.internal.com" "mainapp.example.com"
        ProxyPassReverseCookiePath "/webapp-a/" "/app-a/" # 必要であればパスも書き換え
    </Location>

    # アプリケーションB
    <Location "/app-b/">
        ProxyPass "http://backend-b.internal.com:9090/webapp-b/"
        ProxyPassReverse "http://backend-b.internal.com:9090/webapp-b/"
        ProxyPassReverseCookieDomain "backend-b.internal.com" "mainapp.example.com"
    </Location>

    ErrorLog ${APACHE_LOG_DIR}/mainapp_error.log
    CustomLog ${APACHE_LOG_DIR}/mainapp_access.log combined
</VirtualHost>

解説

ProxyPassReverseCookiePath: この例では ProxyPassReverseCookiePath も追加しています。これは、バックエンドが発行する Cookie の Path 属性も書き換える必要がある場合に使用します。例えば、バックエンドが /webapp-a/ のパスで Cookie を発行しているが、クライアントは /app-a/ でアクセスしている場合に必要になります。
Location ブロック: 特定のURLパスごとにプロキシ設定を分けたい場合に便利です。それぞれのアプリケーションに対して独立した ProxyPassReverseCookieDomain を設定できます。

HTTPS (SSL/TLS) 環境での設定例

本番環境ではHTTPSが一般的です。クライアントとApache間、またはApacheとバックエンド間でHTTPSを使用する場合の設定です。

<VirtualHost *:443>
    ServerName secureapp.example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/secureapp.example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/secureapp.example.com.key

    # クライアントからのリクエストをHTTPSでバックエンドに転送
    ProxyPass "/" "https://backend.internal.com:8443/"
    ProxyPassReverse "/" "https://backend.internal.com:8443/"

    # Cookieのドメインを書き換える設定
    # バックエンドが "backend.internal.com" で発行したCookieのDomainを
    # クライアントがアクセスする "secureapp.example.com" に書き換える
    ProxyPassReverseCookieDomain "backend.internal.com" "secureapp.example.com"

    # HTTPSでは、Secure属性を持つCookieも考慮に入れる
    # 必要に応じて、CookieのSecure属性を調整するProxyPassReverseCookieSecureも検討
    # ProxyPassReverseCookieSecure On # クライアントがHTTPSでアクセスしている場合、CookieにSecure属性を追加

    ErrorLog ${APACHE_LOG_DIR}/secureapp_error.log
    CustomLog ${APACHE_LOG_DIR}/secureapp_access.log combined
</VirtualHost>

解説

ProxyPassReverseCookieSecure (オプション):
- このディレクティブは、ProxyPassReverseCookieDomain とは直接関係ありませんが、HTTPS環境で重要になります。
- バックエンドが発行したCookieにSecure属性がない場合でも、クライアントとApache間の接続がHTTPSであれば、Apacheがこの属性を付与することができます。これにより、ブラウザはそのCookieをHTTPS接続でのみ送信するようになり、セキュリティが向上します。
ProxyPassReverseCookieDomain: HTTPS環境でも、ドメインの書き換えの原理は同じです。
ProxyPass "/" "https://backend.internal.com:8443/": https:// スキームを使用することで、Apache とバックエンド間の通信も HTTPS になります。
SSLEngine on, SSLCertificateFile, SSLCertificateKeyFile: HTTPSを有効にするための基本的なSSL設定です。

`interpolate` オプションの使用例

interpolate オプションを使用すると、public-domain の部分で環境変数を使用できるようになります。これは、動的な設定や、設定ファイルが複数ある場合に便利です。

# Apacheの環境変数として外部ドメインを設定（例: httpd.confの先頭やenvvarsファイルで）
# SetEnv MY_PUBLIC_DOMAIN "dynamic.example.com"

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

    ProxyPass "/app/" "http://backend.internal.com:8080/app/"
    ProxyPassReverse "/app/" "http://backend.internal.com:8080/app/"

    # interpolate オプションを使って環境変数 MY_PUBLIC_DOMAIN の値を使用
    ProxyPassReverseCookieDomain "backend.internal.com" "${MY_PUBLIC_DOMAIN}" interpolate

    ErrorLog ${APACHE_LOG_DIR}/dynamic_error.log
    CustomLog ${APACHE_LOG_DIR}/dynamic_access.log combined
</VirtualHost>

"${MY_PUBLIC_DOMAIN}" interpolate: ProxyPassReverseCookieDomain の public-domain 部分に環境変数 MY_PUBLIC_DOMAIN の値を適用します。interpolate キーワードがこの機能を使えるようにします。
SetEnv MY_PUBLIC_DOMAIN "dynamic.example.com": Apacheの環境変数を設定します。

ここでは、ProxyPassReverseCookieDomain の代替となりうる方法と、それぞれのプログラミング（設定）に関連する説明を提供します。

mod_headers を使用した Set-Cookie ヘッダーの書き換え

mod_headers モジュールは、HTTPリクエストおよびレスポンスヘッダーを操作するための強力な機能を提供します。これを使用して、Set-Cookie ヘッダーの Domain 属性を正規表現で検索し、置換することができます。

利点

特定の条件に基づいてCookieのドメインを書き換えたい場合に有効。
ProxyPassReverseCookieDomain よりも柔軟な正規表現での置換が可能。

欠点

Cookieのパス (Path) やセキュア属性 (Secure) も同時に書き換えたい場合は、追加の Header edit ディレクティブが必要になる。
ProxyPassReverseCookieDomain ほどシンプルではないため、設定ミスが生じやすい。
Set-Cookie ヘッダーが複数ある場合や、複雑なCookieの形式の場合、正規表現の記述が難しくなる可能性がある。

設定例

LoadModule headers_module modules/mod_headers.so

<VirtualHost *:80>
    ServerName public.example.com
    ProxyPass "/app/" "http://backend.internal.com:8080/app/"
    ProxyPassReverse "/app/" "http://backend.internal.com:8080/app/"

    # Set-Cookie ヘッダーの Domain 属性を書き換える
    # edit* は、マッチするすべてのインスタンスを置換する（通常はDomainは一つだが念のため）
    Header edit* Set-Cookie "(?i)(Domain=)backend\.internal\.com" "$1public.example.com"
    
    # 必要に応じて、Secure属性も追加/削除
    # Header edit* Set-Cookie "(?i)(;\\s*secure)" "" # Secure属性を削除する場合
    # Header edit* Set-Cookie "(?i)(.*)" "$1; Secure" # Secure属性を追加する場合 (他の属性の後に来るように注意)
</VirtualHost>

解説

"$1public.example.com": 置換後の文字列です。キャプチャグループ1 ($1) を再利用することで、"Domain=" の部分を維持しつつ、ドメイン名を public.example.com に書き換えます。
"(?i)(Domain=)backend\.internal\.com": 検索する正規表現です。
- (?i): 大文字小文字を区別しないマッチングを行います。
- (Domain=): "Domain=" の部分をキャプチャグループ1 ($1) として保持します。
- backend\.internal\.com: 置換対象のドメインをエスケープして指定します。
Header edit* Set-Cookie: Set-Cookie ヘッダーに対して、正規表現による置換を実行します。edit* はヘッダー値内に複数の一致がある場合にすべてを置換します（Set-Cookie ヘッダー自体が複数来る場合は、それぞれのヘッダーに適用されます）。

mod_rewrite と [CO] フラグの使用

mod_rewrite はURLの書き換えに特化していますが、[CO] (cookie) フラグを使用することで、Cookieを生成または変更することができます。しかし、これはバックエンドからの Set-Cookie ヘッダーを「受信して書き換える」のではなく、Apache自身が「新しいCookieを発行する」というアプローチになります。

利点

条件に基づいた非常に柔軟なCookie操作が可能。

欠点

通常は ProxyPassReverseCookieDomain の直接的な代替にはなりません。これは、バックエンドが発行する既存のCookieを書き換えるのではなく、Apacheが自身の判断でCookieを発行するシナリオに適用されます。
バックエンドがCookieの内容を頻繁に変更する場合、Apacheの設定も追従して更新する必要がある。
バックエンドアプリケーションが発行する元のCookieの内容を完全に把握し、Apache側で再構築する必要があるため、実装が非常に複雑になる。

LoadModule rewrite_module modules/mod_rewrite.so

<VirtualHost *:80>
    ServerName public.example.com
    ProxyPass "/app/" "http://backend.internal.com:8080/app/"
    ProxyPassReverse "/app/" "http://backend.internal.com:8080/app/"

    RewriteEngine On
    # 例: 特定のURLアクセス時に、新しいセッションCookieを発行する場合
    RewriteRule "^/app/login$" "-" [CO=MySessionID:newValue:public.example.com:/app:0]
    # MySessionID:newValue:public.example.com:/app:0 の意味:
    # MySessionID: Cookie名
    # newValue: Cookie値
    # public.example.com: Domain属性
    # /app: Path属性
    # 0: 有効期限 (0はブラウザセッション中のみ有効)
</VirtualHost>

解説

これはバックエンドからのSet-Cookieを書き換えるものではなく、Apacheが独自にCookieを発行する用途で使われることがほとんどです。そのため、ProxyPassReverseCookieDomainの直接の代替とは言いにくいです。バックエンドがまったくCookieを発行せず、Apacheがセッション管理を肩代わりするような非常に特殊なケースで利用される可能性があります。
[CO=Name:Value:Domain:Path:Lifetime:Flags] の形式でCookieを発行します。

mod_lua または外部スクリプト/リバースプロキシソリューション

Apacheの mod_lua モジュールを使用すると、Luaスクリプトを記述して、HTTPリクエストやレスポンスを非常に柔軟に操作できます。これには、Set-Cookie ヘッダーの解析と書き換えも含まれます。

利点

正規表現だけでは対応が難しいような、動的なCookie操作が可能。
mod_headers よりもさらに高度で複雑なロジックを実装できる。

欠点

Apacheのコア機能ではなく、追加のスキルセットが必要。
Apacheのパフォーマンスに影響を与える可能性がある。
Luaスクリプトの記述とデバッグが必要になり、複雑性が増す。

設定例 (概念的なもの、実際のLuaスクリプトはより複雑になります)

LoadModule lua_module modules/mod_lua.so

<VirtualHost *:80>
    ServerName public.example.com
    ProxyPass "/app/" "http://backend.internal.com:8080/app/"
    ProxyPassReverse "/app/" "http://backend.internal.com:8080/app/"

    # Luaスクリプトをレスポンスフィルターとして設定
    # レスポンスヘッダーが送信される直前に実行されるフック
    LuaHookFixups /path/to/lua/script/rewrite_cookie.lua rewrite_cookie_domain

    ErrorLog ${APACHE_LOG_DIR}/public_example_com_error.log
    CustomLog ${APACHE_LOG_DIR}/public_example_com_access.log combined
</VirtualHost>

rewrite_cookie.lua (抜粋、概念的なコード)

function rewrite_cookie_domain(r)
    local headers = r:get_headers_out() -- レスポンスヘッダーを取得

    for i, header_val in ipairs(headers["Set-Cookie"]) do
        -- Set-Cookie ヘッダーの Domain 属性を正規表現で検索し置換
        local new_header_val = header_val:gsub("(?i)(Domain=)backend%.internal%.com", "%1public.example.com")
        
        -- 必要であれば、Secure属性も操作
        -- new_header_val = new_header_val:gsub("(?i);%s*Secure", "") -- Secureを削除
        -- if r.parsed_uri.scheme == "https" then
        --     new_header_val = new_header_val .. "; Secure" -- HTTPSの場合にSecureを追加
        -- end

        headers:set("Set-Cookie", new_header_val) -- 書き換えたヘッダーを再設定
    end

    return apache2.OK
end

外部リバースプロキシソリューション

NginxやHAProxyのような他のリバースプロキシソフトウェアは、Cookieの書き換え機能を内蔵しているか、Luaスクリプトなどを用いて柔軟な操作が可能です。もしApacheでの実装が非常に困難な場合や、よりパフォーマンスが求められる場合は、これらのツールを検討するのも一つの方法です。

HAProxy
http-response replace-header や Luaスクリプトを使用してCookieを操作できます。
Nginx
proxy_cookie_domain ディレクティブや sub_filter モジュール、または ngx_http_lua_module を使用してCookieを操作できます。

方法	利点	欠点	推奨されるケース
`ProxyPassReverseCookieDomain`	最もシンプルで推奨される。専用のディレクティブ。	特定の正規表現に基づく高度な操作には向かない。	ほとんどのリバースプロキシシナリオ。
`mod_headers`	正規表現による柔軟な置換が可能。	設定が複雑になりがち。複数Cookieや複雑なケースは注意が必要。	`ProxyPassReverseCookieDomain` では対応できない複雑な書き換えが必要な場合。
`mod_rewrite` (`[CO]`)	条件に基づくCookie生成。	既存のCookie書き換えには不向き。ApacheがCookieを「発行」する形になる。	ApacheがCookieを発行してセッション管理を肩代わりする特殊なケース。
`mod_lua`/外部プロキシ	非常に高度で複雑なロジックを実装可能。	複雑性と専門知識が必要。パフォーマンスへの影響も考慮。	非常に特殊な要件、またはApache以外のリバースプロキシ導入を検討する場合。

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