Apache mod_proxy と HAProxy の比較｜TLS終端・負荷分散・ヘルスチェックの違いと使い分け

Apache の mod_proxy と HAProxy は、どちらも「前段で受けて裏のサーバーへ渡す」リバースプロキシとして使えます。結論から言うと、Webサーバーとしての Apache をすでに運用していて転送先が少数なら mod_proxy で十分で、複数台への負荷分散・細かなヘルスチェック・高い同時接続数が主目的なら HAProxy が向いています。この記事では、TLS 終端、負荷分散、ヘルスチェック、運用時の見えやすさの4点で両者を比べ、WordPress の前段に置くときの設定例と注意点までを整理します。

そもそも役割が少し違う

Apache は本来 Web サーバーで、静的ファイルの配信や PHP の実行（mod_php や PHP-FPM 連携）を受け持ちつつ、mod_proxy を読み込むことでプロキシの機能を「追加」できます。1台の Apache の中で、あるパスは自分で処理し、別のパスだけ裏の Node.js アプリへ渡す、といった混在構成が得意です。

HAProxy はプロキシと負荷分散のための専用ソフトです。ファイルを配信したり PHP を実行したりはしません。そのぶん、接続の振り分け、サーバーの死活判定、接続数の制御、統計情報の出力といった機能が厚く、設定もその用途に絞られています。

「どちらが上か」ではなく、「Web サーバーの延長でプロキシもしたい」のか「プロキシ専任の層を置きたい」のかで選ぶのが筋です。

比較の要点

機能の有無だけを見ると大きな差はありません。差が出るのは、同時接続が増えたときの扱いやすさと、障害時に「どのサーバーがなぜ外れたか」を追いやすいかどうかです。HAProxy はサーバーごとの状態遷移がログと統計に細かく出るため、台数が増えるほど運用面の差が開きます。

TLS 終端の違い

どちらもクライアントとの HTTPS をプロキシで終わらせ、裏側は HTTP で渡す構成（TLS 終端）が組めます。証明書の更新を1か所にまとめられるのが利点です。

Apache では、いつもの VirtualHost に mod_ssl の設定を書き、その中で ProxyPass を使います。裏側も HTTPS にしたい場合は、VirtualHost 内で SSLProxyEngine on が別に必要です。これを忘れると、HTTPS の転送先へ接続できずにエラーになります。

HAProxy では、bind 行に ssl crt で証明書ファイル（証明書と秘密鍵を連結した PEM）を指定します。certbot などで更新した証明書を連結し直す手順が要るので、更新フックを用意しておくのが一般的です。

どちらの場合も、WordPress から見ると通信は HTTP で届きます。そのままだと is_ssl() が偽になり、管理画面のリダイレクトが繰り返されたり、混在コンテンツが出たりします。プロキシ側で X-Forwarded-Proto を付け、WordPress 側で受け取る設定がセットで必要です。

負荷分散とヘルスチェック

Apache mod_proxy の場合

複数台へ振り分けるには mod_proxy_balancer と、振り分け方式のモジュール（リクエスト数で均等に配る mod_lbmethod_byrequests など）を有効にします。死活監視は mod_proxy_hcheck を読み込み、BalancerMember にパラメータを足して設定します。Ubuntu/Debian 系なら a2enmod proxy proxy_http proxy_balancer lbmethod_byrequests proxy_hcheck のように有効化します（モジュール名はディストリビューションやパッケージで異なる場合があります）。

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile    /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem

    <Proxy "balancer://wpcluster">
        BalancerMember "http://10.0.0.11:8080" hcmethod=GET hcuri=/healthz.php hcinterval=10
        BalancerMember "http://10.0.0.12:8080" hcmethod=GET hcuri=/healthz.php hcinterval=10
        ProxySet lbmethod=byrequests
    </Proxy>

    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"
    ProxyPass        "/" "balancer://wpcluster/"
    ProxyPassReverse "/" "balancer://wpcluster/"
</VirtualHost>

ProxyPreserveHost On は、裏側の WordPress に元の Host ヘッダー（example.com）を渡すための設定です。これが無いと WordPress は内部 IP 宛てのリクエストとして受け取り、リダイレクト先が内部アドレスになることがあります。RequestHeader には mod_headers が必要です。

HAProxy の場合

HAProxy は frontend（受け口）と backend（転送先の組）を分けて書きます。ヘルスチェックは server 行の check で有効になり、http-check で確認内容を指定します。

defaults
    mode http
    timeout connect 5s
    timeout client  60s
    timeout server  60s
    option httplog

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    option forwardfor
    default_backend be_wp

backend be_wp
    balance roundrobin
    option httpchk
    http-check send meth GET uri /healthz.php
    http-check expect status 200
    server app1 10.0.0.11:8080 check
    server app2 10.0.0.12:8080 check

option forwardfor は X-Forwarded-For にクライアント IP を付けます。Apache の mod_proxy_http は、既定でこのヘッダーを自動で付けます。http-check send の書式は HAProxy 2.2 以降のもので、古い版では option httpchk GET /healthz.php の形になります。

ヘルスチェック先の /healthz.php は、DB に軽く接続して 200 を返すだけの小さなファイルを用意するのが扱いやすい方法です。トップページを叩かせると、キャッシュ切れのたびに重い処理が走り、それ自体が負荷になります。

WordPress 側で必要な設定

プロキシの後ろに置いた WordPress では、wp-config.php の require_once ABSPATH . 'wp-settings.php'; より前に次を書きます。編集前に wp-config.php のバックアップを取ってください。

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

この判定はヘッダーを信用するので、WordPress のサーバーへプロキシ以外から直接届かないよう、ファイアウォールで送信元を絞っておくことが前提です。直接アクセスできる状態だと、誰でもヘッダーを偽れます。アクセス元 IP を記録するプラグインやセキュリティ系プラグインでは、X-Forwarded-For をどこまで信用するかの設定があることが多いので、プロキシの IP だけを信用するよう見直してください。

どちらを選ぶかの目安

• Apache 1台で WordPress を動かしていて、一部のパスだけ別アプリへ渡したい：mod_proxy
• 2台以上の WordPress へ振り分け、1台落ちても自動で外したい：HAProxy が扱いやすい
• 同時接続が多い、または接続数の上限や待ち行列を細かく制御したい：HAProxy
• 構成を増やしたくない、管理者が Apache に慣れている：mod_proxy
• HAProxy の前段（または後段）に Apache を残す二段構成も一般的です。HAProxy で TLS 終端と振り分けを行い、各サーバーの Apache が PHP を実行する形です

バージョンごとの機能差はあるため、導入前に使う版の公式ドキュメントを確認してください。Apache は 2.4 系、HAProxy は LTS 版と短期サポート版が並行してリリースされています（2026年10月現在）。どちらを選ぶにしても、本番に入れる前にステージングで切り替えを試し、設定の検査コマンド（apachectl configtest または haproxy -c -f /etc/haproxy/haproxy.cfg）を通してから再読み込みするのが安全です。

まとめ

• mod_proxy は Web サーバーの延長としてのプロキシ、HAProxy はプロキシ・負荷分散専用という違いがあります。
• TLS 終端はどちらも可能です。Apache で HTTPS の転送先を使うときは SSLProxyEngine on が別に必要です。
• 複数台の振り分けや死活監視、障害時の追跡のしやすさを重視するなら HAProxy が向いています。
• WordPress 側では X-Forwarded-Proto を受けて HTTPS 判定を補い、プロキシ以外からの直接アクセスを塞ぎます。
• 切り替えはバックアップとステージングでの確認を済ませてから行います。

• Apacheでリバースプロキシを設定する方法
• WordPressをHAProxyで負荷分散してサイトの可用性を高める設定方法