mod_proxy: ProxySourceAddress

2025-05-26

ProxySourceAddress は、Apache の mod_proxy モジュールで使用されるディレクティブで、プロキシとしてリクエストを転送する際に、Apache 自身がその転送元（クライアント）として使用するIPアドレスを指定するものです。

通常、Apache がバックエンドのサーバー（プロキシ先）にリクエストを転送する際、Apache 自身のIPアドレスがそのリクエストの送信元IPアドレスとして使用されます。しかし、特定のネットワーク構成や要件において、この送信元IPアドレスを明示的に指定したい場合があります。その際に ProxySourceAddress が役立ちます。

使用例と目的

例えば、以下のようなシナリオで利用されます。

特定のIPアドレスからの通信に制限がある場合: バックエンドのサーバーが、特定のIPアドレスからの接続のみを許可するように設定されている場合、Apache がその許可されたIPアドレスを使用してリクエストを送信する必要があります。このとき、ProxySourceAddress で許可されたIPアドレスを指定することで、Apache からのプロキシリクエストが正しく受け入れられるようになります。
複数のネットワークインターフェースを持つサーバーの場合: Apache サーバーが複数のネットワークインターフェース（複数のIPアドレス）を持っている場合、通常はOSがルーティングテーブルに基づいて送信元IPアドレスを自動的に選択します。しかし、特定のネットワークインターフェース（IPアドレス）からの通信を強制したい場合に ProxySourceAddress を使用します。これにより、トラフィックが特定の経路を通過するように制御できます。
ロードバランサーやファイアウォールでの識別: バックエンドのロードバランサーやファイアウォールが、特定の送信元IPアドレスからのトラフィックに基づいて処理を行う場合、ProxySourceAddress を設定することで、それらのデバイスがApacheからのプロキシリクエストを正しく識別・処理できるようになります。

構文

ProxySourceAddress の基本的な構文は以下の通りです。

ProxySourceAddress IP-address

IP-address: Apache がプロキシリクエストの送信元として使用するIPアドレスを指定します。IPv4またはIPv6アドレスを指定できます。

例

<VirtualHost *:80>
    ServerName example.com
    ProxyRequests Off
    ProxyPreserveHost On

    # プロキシリクエストの送信元IPアドレスを 192.168.1.100 に設定
    ProxySourceAddress 192.168.1.100

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    ProxyPass / http://backend-server.example.com/
    ProxyPassReverse / http://backend-server.example.com/
</VirtualHost>

注意点

他のプロキシ設定との兼ね合い: ProxySourceAddress は、ProxyPass や ProxyPassMatch などの他の mod_proxy ディレクティブと組み合わせて使用されます。
グローバルな設定とバーチャルホスト: ProxySourceAddress は、サーバー全体（グローバルコンテキスト）で設定することも、特定のバーチャルホスト内で設定することも可能です。バーチャルホスト内で設定した場合、そのバーチャルホストからのプロキシリクエストにのみ適用されます。
権限: Apache が指定されたIPアドレスをバインド（使用）する権限を持っている必要があります。通常、低ポート番号（1024未満）を使用する場合や、特定のネットワーク設定によってはroot権限での起動が必要になる場合があります。
指定したIPアドレスがApacheサーバーに存在すること: ProxySourceAddress で指定するIPアドレスは、そのApacheサーバーが所有している、有効なIPアドレスである必要があります。存在しないIPアドレスを指定すると、接続エラーが発生する可能性があります。

ProxySourceAddress は便利なディレクティブですが、設定ミスや環境要因によってエラーが発生することがあります。ここでは、よくあるエラーパターンとその原因、およびトラブルシューティングの手順を説明します。

(99)Cannot assign requested address: AH00959: ProxySourceAddress: failed to bind socket to address ...

エラーメッセージ例

[core:crit] [pid 12345:tid 140000000000000] (99)Cannot assign requested address: AH00959: ProxySourceAddress: failed to bind socket to address 192.168.1.100

原因
このエラーは、ProxySourceAddress で指定されたIPアドレスをApacheが使用できない場合に発生します。主な原因は以下の通りです。

ネットワーク設定の誤り: サブネットマスクの不一致、ルーティングの問題など。
権限の問題: Apacheが指定されたIPアドレスにバインドするための十分な権限を持っていない（特に非特権ユーザーで実行されている場合）。
指定したIPアドレスが別のプロセスによって使用されている: 他のアプリケーションやサービスがそのIPアドレス（特にポート）を既にバインドしている。
指定したIPアドレスがApacheサーバーに存在しない、またはアクティブでない: ApacheサーバーがそのIPアドレスを所有していないか、そのネットワークインターフェースがダウンしている。

トラブルシューティング

IPアドレスの確認:
- Apacheサーバー上で、ProxySourceAddress で指定したIPアドレスが実際に設定され、アクティブになっているかを確認します。
  - Linux: ip a または ifconfig
  - Windows: ipconfig
- IPアドレスが設定されていない場合は、OSのネットワーク設定で追加します。
IPアドレスの衝突確認:
- 指定したIPアドレスの特定のポートが、他のプロセスによって使用されていないか確認します。
  - Linux: netstat -tulnp | grep <IP_ADDRESS>:<PORT> (例: netstat -tulnp | grep 192.168.1.100:80 - ただしProxySourceAddressは送信元IPなのでポートはバックエンドのポートになります)
  - 基本的にProxySourceAddressは送信元IPなので、ポートが衝突することは稀ですが、IPアドレス自体が正しく設定されていない場合は確認が必要です。
Apacheの実行ユーザーの権限確認:
- Apacheが低ポート番号（例: 80, 443）を使用している場合、root権限で起動されていないと特定の操作ができないことがあります。Apacheが使用するユーザー（例: apache, www-data）が、そのIPアドレスにバインドする権限を持っているか確認します。
- 通常、ProxySourceAddress の設定自体はIPアドレスのバインドに関わるため、ApacheプロセスがIPアドレスをバインドできる環境で実行されている必要があります。
ネットワークの疎通確認:
- 指定したIPアドレスからバックエンドサーバーへのPingやTelnetなどで、ネットワーク的な疎通が可能か確認します。

バックエンドサーバーからの接続拒否 / タイムアウト

原因
ProxySourceAddress 自体がエラーを出していなくても、バックエンドサーバー側で接続が拒否されたり、タイムアウトになったりする場合があります。

SNAT/MASQUERADEとの競合: Linuxサーバーの場合、iptablesなどでSource NAT (SNAT) やMASQUERADEが設定されており、ProxySourceAddressで指定したIPアドレスが、NATによって別のIPアドレスに変換されてしまう。
ルーティングの問題: Apacheサーバーからバックエンドサーバーへのルーティングが正しくなく、指定したProxySourceAddressからの通信がバックエンドサーバーに到達できない。
バックエンドサーバーのアクセス制御リスト (ACL): バックエンドサーバー側の設定で、特定のIPアドレスからのアクセスのみを許可しており、ProxySourceAddress のIPアドレスがそのリストに含まれていない。
バックエンドサーバーのファイアウォール設定: バックエンドサーバーのファイアウォールが、ProxySourceAddress で指定されたIPアドレスからの接続を許可していない。

トラブルシューティング

バックエンドサーバーのログ確認:
- バックエンドサーバーのアクセスログやエラーログを確認し、Apacheからの接続試行が記録されているか、または接続拒否のエラーが出ているかを確認します。
ファイアウォール設定の確認:
- バックエンドサーバーのファイアウォール（例: firewalld, ufw, iptables、Windows Firewallなど）で、ProxySourceAddress で指定したIPアドレスからの通信を許可しているか確認します。必要であればルールを追加します。
バックエンドサーバーのアクセス制御確認:
- バックエンドアプリケーション（例: Apache, Nginx, Javaアプリケーションなど）自体が、アクセス制御リスト（ACL）を持っている場合、ProxySourceAddress のIPアドレスが許可されているか確認します。
ルーティングの確認:
- Apacheサーバーからバックエンドサーバーへのルーティングテーブルを確認します (route -n や ip r)。
- ProxySourceAddressで指定したIPアドレスからのパケットが、バックエンドサーバーに到達できる経路があることを確認します。
NAT設定の確認（Linux）:
- ApacheサーバーがLinuxの場合、iptables -t nat -L POSTROUTING コマンドなどで、POSTROUTINGチェーンにSNATやMASQUERADEのルールが設定されていないか確認します。もし設定されている場合、ProxySourceAddressの指定がNATによって上書きされてしまう可能性があります。必要であれば、特定の送信元IPアドレスに対するNATをスキップするルールを追加するか、ProxySourceAddressの使用を再検討します。

mod_proxy が正しく動作しない

原因
ProxySourceAddress自体はエラーを出していないものの、プロキシ全体の動作がおかしい場合。

他のmod_proxyディレクティブとの競合: まれに、他のmod_proxy関連の複雑な設定がProxySourceAddressの意図しない動作を引き起こす可能性。
ディレクティブの配置ミス: ProxySourceAddressが適切なコンテキスト（サーバーコンテキストまたはバーチャルホストコンテキスト）に配置されていない。
mod_proxy モジュールがロードされていない: Apacheのmod_proxyやmod_proxy_http（または必要なプロトコルモジュール）が有効になっていない。

トラブルシューティング

モジュールの確認:

httpd.conf または apache2.conf で、以下の行がコメントアウトされていないか確認します。

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
# 必要に応じて
# LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
# LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
# LoadModule proxy_connect_module modules/mod_proxy_connect.so

Apache起動中に httpd -M または apache2ctl -M を実行して、proxy_module と proxy_http_module がリストにあることを確認します。

設定ファイルの構文チェック:
- apachectl configtest または httpd -t を実行し、設定ファイルに構文エラーがないか確認します。
ProxySourceAddress の配置場所:
- ProxySourceAddress は、サーバーコンテキスト（httpd.confのトップレベル）または <VirtualHost> コンテナ内で使用されます。不適切な場所に配置されていないか確認します。

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

最小限の設定でテストする: 問題を切り分けるために、必要最小限の mod_proxy と ProxySourceAddress の設定のみでテスト環境を構築し、段階的に設定を追加していくと、問題の特定が容易になります。
設定変更後の再起動: Apacheの設定を変更した後は、必ずApacheを再起動（またはリロード）してください。
デバッグレベルのログを有効にする: より詳細なログが必要な場合は、LogLevel debug を設定して、より多くの情報がログに記録されるようにします（本番環境では注意）。
Apacheのエラーログを確認する: Apacheのエラーログ（通常 logs/error_log または /var/log/apache2/error.log）は、問題の原因を特定するための最も重要な情報源です。詳細なエラーメッセージ、時刻、関連するモジュールなどが記録されています。

以下に、いくつかの一般的な設定例と、それぞれの目的を説明します。

基本的なプロキシ設定での ProxySourceAddress の使用

この例では、example.com へのリクエストをバックエンドサーバー http://backend.internal にプロキシしますが、その際に Apache サーバーが 192.168.1.100 という送信元IPアドレスを使用するように指定します。

設定コード

# mod_proxy モジュールがロードされていることを確認
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

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

    # プロキシリクエストを無効にする（リバースプロキシとしてのみ機能させる）
    ProxyRequests Off
    # クライアントのHostヘッダーをバックエンドに転送する
    ProxyPreserveHost On

    # ここが ProxySourceAddress の設定
    # Apache がバックエンドに接続する際の送信元IPアドレスを 192.168.1.100 に指定
    ProxySourceAddress 192.168.1.100

    # プロキシに関するセキュリティ設定（必要に応じて調整）
    <Proxy *>
        Require all granted
    </Proxy>

    # / へのリクエストをバックエンドサーバーにプロキシ
    ProxyPass / http://backend.internal/
    # プロキシ先からのリダイレクトURLを書き換える
    ProxyPassReverse / http://backend.internal/

    ErrorLog /var/log/httpd/example.com_error.log
    CustomLog /var/log/httpd/example.com_access.log combined
</VirtualHost>

解説

動作: この設定により、example.com への外部からのリクエストが Apache に到達すると、Apache はそのリクエストを http://backend.internal/ に転送しますが、その際に送信元IPアドレスとして常に 192.168.1.100 を使用します。バックエンドサーバーのログには、接続元が 192.168.1.100 と記録されます。
目的: バックエンドサーバーが、特定のIPアドレス（ここでは 192.168.1.100）からの接続のみを許可している場合や、Apacheが複数のネットワークインターフェースを持つ環境で特定のインターフェースから通信したい場合に利用されます。

ロードバランサー設定での ProxySourceAddress の使用

複数のバックエンドサーバーに対してロードバランシングを行う際に、プロキシ元のIPアドレスを統一したい場合にも利用できます。

設定コード

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

<VirtualHost *:80>
    ServerName myapp.example.com
    ProxyRequests Off
    ProxyPreserveHost On

    # ロードバランサーのメンバー定義
    <Proxy balancer://mycluster>
        BalancerMember http://backend1.internal:8080 route=1
        BalancerMember http://backend2.internal:8080 route=2
        # ロードバランサー経由での接続元IPアドレスを 192.168.1.101 に統一
        ProxySourceAddress 192.168.1.101
        # ロードバランシングメソッド (例: ByRequests, ByTraffic, ByBusyness)
        ProxySet lbmethod=byrequests
    </Proxy>

    # プロキシに関するセキュリティ設定
    <Proxy *>
        Require all granted
    </Proxy>

    # / をロードバランサーにプロキシ
    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/

    ErrorLog /var/log/httpd/myapp_error.log
    CustomLog /var/log/httpd/myapp_access.log combined
</VirtualHost>

解説

動作: この設定により、myapp.example.com へのリクエストはApacheによって backend1 または backend2 のいずれかに転送されますが、どちらのバックエンドサーバーへの接続も、送信元IPアドレスは常に 192.168.1.101 となります。
目的: 複数のバックエンドサーバー（backend1, backend2）が、特定の送信元IPアドレスからの接続のみを許可している場合、ロードバランサーであるApacheがその許可されたIPアドレス（192.168.1.101）を使用して接続するように強制できます。

特定のパスへのプロキシと送信元IPアドレスの指定

ウェブサイトの一部のみをプロキシし、そのプロキシ通信の送信元IPアドレスを制御したい場合。

設定コード

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

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

    ProxyRequests Off
    ProxyPreserveHost On

    # /data/ ディレクトリへのリクエストのみをプロキシする
    <Location /data/>
        # この Location ブロック内のプロキシ通信にのみ適用される送信元IPアドレス
        ProxySourceAddress 192.168.1.102
        ProxyPass http://fileserver.internal/data/
        ProxyPassReverse http://fileserver.internal/data/
    </Location>

    # 他のパスはローカルの DocumentRoot から提供される

    ErrorLog /var/log/httpd/files_error.log
    CustomLog /var/log/httpd/files_access.log combined
</VirtualHost>

解説

動作: files.example.com/data/ へのリクエストが来ると、Apacheは fileserver.internal/data/ に転送しますが、その際の送信元IPは 192.168.1.102 になります。一方、/data/ 以外のリクエスト（例: /index.html）は、Apacheサーバー自身の DocumentRoot から通常通り提供され、プロキシは発生しません。ProxySourceAddress は <Location> コンテキストに適用されるため、そのコンテキスト内のプロキシ通信にのみ影響します。
目的: サイトの一部（例: /data/）を別のファイルサーバーにプロキシしつつ、そのプロキシ通信を特定のIPアドレスから行いたい場合に利用されます。

ファイアウォールとルーティング: バックエンドサーバーのファイアウォールやネットワークルーティング設定が、ProxySourceAddress で指定したIPアドレスからの接続を許可していることを確認する必要があります。
ネットワーク構成: これらの設定は、Apacheサーバーが内部ネットワークや特定のサブネットに接続されている、または複数のIPアドレスを持っているような複雑なネットワーク構成で特に役立ちます。
IPアドレスの有効性: 設定する ProxySourceAddress のIPアドレスは、Apacheが稼働しているサーバーに実際に設定され、有効なものである必要があります。存在しないIPアドレスを指定すると、Apacheが起動できなかったり、プロキシ接続が失敗したりします。

これらは、Apacheの設定自体で制御するのではなく、OSのネットワーク設定や別のミドルウェア、またはバックエンドサーバー側の設定で対応する方法です。

OSレベルでのSource NAT (SNAT) / IPマスカレード

最も一般的な代替方法の一つが、LinuxなどのOSの機能であるSource NAT (SNAT) やIPマスカレードを使用することです。これは、Apacheサーバーが外部にパケットを送信する際に、指定した送信元IPアドレスにパケットのヘッダを書き換える機能です。

欠点
- OSのネットワーク設定に関する知識が必要。
- iptables や nftables のルールが複雑になる可能性がある。
- Apache以外のアプリケーションにも影響を与える可能性があるため、慎重な設定が必要。
利点
- Apacheの設定を変更する必要がない。
- OSレベルで一元的に送信元IPアドレスを制御できるため、Apache以外のプロセスからの通信にも適用できる。
- ルーティングの設定と組み合わせて、複雑なネットワークトポロジに対応しやすい。
Linux (iptables/nftables) での例
例えば、ApacheがどのIPアドレスを使って接続を開始しても、特定のIPアドレス（例: 192.168.1.200）から出ているように見せかけることができます。
```
# 192.168.1.0/24 ネットワークへの通信について、
# 送信元IPアドレスを 192.168.1.200 に書き換える例
sudo iptables -t nat -A POSTROUTING -d 192.168.1.0/24 -j SNAT --to-source 192.168.1.200
```

複数のネットワークインターフェースとルーティングポリシー

Apacheサーバーに複数のネットワークインターフェース（NIC）とそれに紐づく複数のIPアドレスがある場合、OSのルーティングポリシーを設定することで、特定の宛先への通信を特定の送信元IPアドレスを持つインターフェースから送信するように制御できます。

欠点
- ネットワーク設定が複雑になり、OSのルーティングに関する深い知識が必要。
- 設定のテストとデバッグが難しい場合がある。
利点
- ネットワークトラフィックをより詳細に制御できる。
- OSのルーティング機能と統合される。
設定例 (LinuxのIPポリシーベースルーティング)
例えば、バックエンドサーバーが属するネットワーク 192.168.1.0/24 への通信は、Apacheサーバーの eth1 インターフェース（IPアドレス 10.0.0.10 と仮定）から送信し、それ以外の通信は eth0 から送信する、といった設定が可能です。
1. 特定の送信元IPアドレス用のルーティングテーブルを作成
2. そのルーティングテーブルを使用するルールを追加

ロードバランサー/プロキシの前に別のプロキシ/ゲートウェイを配置

Apacheサーバーの前に、L4/L7ロードバランサー（例: Nginx, HAProxy, F5 Big-IP, AWS ELB/ALB, Google Cloud Load Balancer）やファイアウォール/ゲートウェイを配置し、そこで送信元IPアドレスの変換を行う方法です。

欠点
- 追加のハードウェアまたは仮想アプライアンスが必要になる。
- 構成がより複雑になり、管理コストが増加する。
利点
- ネットワークインフラストラクチャ全体でIPアドレスの制御を一元化できる。
- Apacheサーバーの負担を軽減し、スケーラビリティを向上できる。
- より高度なルーティングやセキュリティ機能（WAFなど）を統合できる。
構成例
クライアント -> L4/L7ロードバランサー -> Apache (プロキシ) -> バックエンドサーバー

この場合、L4/L7ロードバランサーがバックエンドのApacheに接続する際の送信元IPアドレスを制御できます。もしApacheが直接バックエンドに接続するのではなく、このロードバランサーを経由してバックエンドに接続するのであれば、ロードバランサーの設定で送信元IPを制御します。

バックエンドサーバー側の設定でIPアドレスの制御を緩める

これは直接的な代替方法ではありませんが、なぜProxySourceAddressが必要なのか、その根本原因を解決するアプローチです。もしバックエンドサーバーが特定のIPアドレスからの接続のみを許可しているためにProxySourceAddressを使用している場合、バックエンドサーバーのIPアドレス制限を緩和するか、許可リストにApacheサーバーの複数のIPアドレスを含めることで、ProxySourceAddressが不要になる場合があります。

欠点
- セキュリティ要件との兼ね合いを考慮する必要がある。
- バックエンドサーバーの設定変更が必要。
利点
- 設定がシンプルになる場合がある。
- 柔軟性が増す。

ProxySourceAddress は Apache の設定ファイル内で簡単に送信元IPアドレスを制御できるため、多くの場合に便利なディレクティブです。しかし、より大規模な環境や複雑なネットワーク要件がある場合には、上記のようなOSレベルの機能や専用のロードバランサー、ネットワークゲートウェイを活用した代替方法が有効となります。

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