Nginx と HAProxy のロードバランサー比較｜WordPressの負荷分散でどちらを選ぶか

WordPress の前段にロードバランサーを置くとき、Nginx と HAProxy はどちらも有力な選択肢です。大まかに言うと、Nginx は「Webサーバー兼キャッシュ兼LB」として1台で多くの役割をこなせるのが強みで、HAProxy は「負荷分散専用」として能動的なヘルスチェックや運用中の操作、細かな統計が充実しているのが強みです。この記事では、オープンソース版同士を前提に、分散方式、ヘルスチェック、サーバーの増減への追従、TLS、運用のしやすさを比べ、WordPress ではどんな条件でどちらを選ぶとよいかを整理します。

前提：比べるのはオープンソース版

Nginx には有償の NGINX Plus があり、能動的ヘルスチェックや API による動的なサーバー追加など、LB 向けの機能の一部は Plus 側にあります。HAProxy にも商用版がありますが、オープンソース版だけで LB に必要な機能の多くがそろっています。比較記事を読むときは、どちらの版の話なのかを確認すると誤解を避けられます。以下は特記がない限りオープンソース版の話です（2026年10月現在）。

分散方式

どちらも主要な方式は備えています。

• Nginx：既定はラウンドロビン。least_conn（接続数の少ない順）、ip_hash（クライアントIPで固定）、hash（任意のキー、consistent 指定で一貫性ハッシュ）、random が使えます
• HAProxy：roundrobin、leastconn、source、uri、hdr() など。さらに stick-table を使うと、Cookie や送信元ごとの状態を保持して振り分けやレート制限に使えます

WordPress ではログイン状態を Cookie で持ち、検証はデータベースと wp-config.php の認証用キーで行うため、全サーバーで同じキーとDBを使っていればセッション固定（スティッキー）は基本的に不要です。PHP セッションを使うプラグインがある場合だけ、固定かセッションの共有を検討します。

ヘルスチェック：最も差が出るところ

Nginx のオープンソース版のヘルスチェックは「受動的」です。実際のリクエストが失敗した回数を数え、max_fails 回失敗したサーバーを fail_timeout の間だけ外します。設定が簡単な反面、誰かのリクエストが失敗して初めて異常に気づく仕組みです。定期的にURLを叩いて確認する能動的ヘルスチェック（health_check ディレクティブ）は NGINX Plus の機能です。

upstream wp_backend {
    least_conn;
    server 10.0.1.11:80 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:80 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

    location / {
        proxy_pass http://wp_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_next_upstream error timeout http_502 http_503;
    }
}

proxy_next_upstream は失敗時に次のサーバーへ再送する設定ですが、Nginx は既定では POST などの冪等でないリクエストを再送しません。投稿の二重保存や注文の二重処理を防ぐための動きなので、安易に non_idempotent を付けないほうが安全です。なお http2 on; は比較的新しい書き方で、古いバージョンでは listen 443 ssl http2; と書きます。

HAProxy は能動的ヘルスチェックを標準で持ち、HTTP のステータスや本文まで条件にできます。

global
    stats socket /run/haproxy/admin.sock mode 660 level admin

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

frontend fe_https
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request set-header X-Forwarded-Proto https
    option forwardfor
    default_backend be_wp

backend be_wp
    balance leastconn
    option httpchk
    http-check send meth GET uri /healthz.html hdr Host example.com
    http-check expect status 200
    server web1 10.0.1.11:80 check inter 5s fall 3 rise 2
    server web2 10.0.1.12:80 check inter 5s fall 3 rise 2

fall 3 rise 2 は「3回連続失敗で外し、2回連続成功で戻す」という意味です。ヘルスチェック用のURLは静的ファイルにしておくと、PHP やDBの負荷を増やさずに済みます。

サーバーの増減（オートスケール）への追従

Webサーバーを自動で増減させる構成では、LB がバックエンドの一覧をどう更新するかが重要です。

• Nginx：基本は設定ファイルを書き換えて nginx -s reload（または systemctl reload nginx）します。リロードは処理中の接続を切らずに新しい設定へ移る仕組みです。比較的新しいバージョンではオープンソース版でも upstream の server に resolve パラメータを付け、DNS の変化を追従できるようになっています。使えるかどうかは手元のバージョンの公式ドキュメントで確認してください
• HAProxy：server-template と resolvers を組み合わせ、DNS に登録されたサーバーを自動で取り込めます。さらに Runtime API で、再起動せずにサーバーを切り離せます

# web1 を新規接続の対象から外し、処理中の接続が終わるのを待つ
echo "set server be_wp/web1 state drain" | sudo socat stdio /run/haproxy/admin.sock

台数が頻繁に変わる環境や、デプロイのたびに1台ずつ切り離したい運用では、HAProxy のほうが手順を組みやすいと感じる人が多いでしょう。

TLS と HTTP/2・HTTP/3

どちらも TLS 終端、HTTP/2、SNI による複数証明書に対応しています。HTTP/3（QUIC）も両方で使えるようになっていますが、ビルドオプションや対応する TLS ライブラリに条件があるため、使うバージョンの資料を確認してください。証明書の自動更新は、Nginx なら certbot の Nginx プラグイン、HAProxy なら certbot で取得した証明書と秘密鍵を1つの PEM にまとめる処理を更新フックに入れる、という形が一般的です。

運用と監視

• Nginx：アクセスログの書式を自由に組めます。$upstream_addr や $upstream_response_time をログに入れると、どのサーバーが遅いかを追えます。状態を見る stub_status は接続数程度の簡易な情報です
• HAProxy：統計ページや Runtime API で、サーバーごとの状態、エラー数、待ち行列などを細かく確認できます。Prometheus 形式での出力にも対応しています

WordPress で選ぶときの目安

両方を組み合わせる構成もよく使われます。前段の HAProxy で振り分けとヘルスチェックを行い、各Webサーバーでは Nginx と PHP-FPM が WordPress を動かす、という形です。どちらの場合も、WordPress 側には X-Forwarded-Proto を見て HTTPS と判定する設定、訪問者IPを X-Forwarded-For から復元する設定、wp-content/uploads を全サーバーで共有する仕組みが必要です。設定変更は検証環境で試し、本番では変更前の設定ファイルを控えてから nginx -t や haproxy -c -f /etc/haproxy/haproxy.cfg で構文を確認してから反映してください。

まとめ

• Nginx は Webサーバー・キャッシュ・LB を1台で兼ねられるのが強み。オープンソース版のヘルスチェックは受動的
• HAProxy は LB 専用で、能動的ヘルスチェック、Runtime API、詳しい統計が標準でそろう
• サーバー台数が多い、または自動で増減する環境では HAProxy のほうが運用を組みやすい
• 小規模で役割を兼ねたいなら Nginx、両者を組み合わせる構成も現実的
• WordPress 側の HTTPS 判定、訪問者IP、メディア共有はどちらでも必要

• Nginx のロードバランシング設定方法（upstreamの書き方・分散方式・障害時の切り離し）
• WordPress を HAProxy で負荷分散して可用性を高める設定方法