公開2026.07.14更新2026.09.11 インフラ・クラウド

HAProxyとは：L4/L7ロードバランサーの仕組みと設定・nginxとの違いを実装目線で解説

HAProxyとは、クライアントからの通信を複数のバックエンドサーバーへ振り分ける、TCP/HTTP対応の高性能ロードバランサー兼リバースプロキシのオープンソースソフトウェアです。名前の由来は High Availability Proxy で、1台のサーバーに負荷と障害リスクが集中する構成を、複数台への分散と死活監視によって解消する目的で使われます。この記事では、HAProxyがロードバランサーやリバースプロキシとどう関係するのかという定義から、frontend／backendという設定の構造、L4（TCP）とL7（HTTP）の処理モデルの違い、負荷分散アルゴリズムとヘルスチェックの設計、そのまま貼って動く最小構成のhaproxy.cfgとdocker composeでの検証手順、HAProxy自身の冗長化、そしてnginxやクラウドのマネージドLBとの違いと、どんなときに採用しどんなときに見送るかまでを、実装者と発注者の双方が判断に使える形で整理します。数値と版番号はHAProxy公式サイトのバージョン表と3.4系の設定リファレンスを2026年9月11日に参照した実測です。

まとめ｜HAProxyの正体と負荷分散設計で押さえる要点

HAProxyは、受け取った通信を裏側の複数サーバーに割り振る「交通整理役」のソフトウェアです。設定ファイルは待ち受け側を書くfrontendと、振り分け先を書くbackendに分かれ、この2つの対応関係が構成の骨格になります。振り分けはbalanceで指定するアルゴリズムで決まり、順番に回すroundrobinや、接続数の少ない先を選ぶleastconnがよく使われます。serverにcheckを付ければ、停止中のサーバーには通信が送られません。TCPをそのまま流すmode tcp（L4）と、HTTPの中身を見て振り分けるmode http（L7）の2つのモードを、扱うプロトコルに応じて使い分けます。

実務で最初に押さえるべきは、HAProxy自身が単一障害点になりうるという一点です。負荷分散でバックエンドを冗長化しても、入口のHAProxyが1台なら、そこが落ちれば全体が止まります。本番ではKeepalived等でHAProxyを2台構成にし、仮想IPを引き継ぐ形にすることが、高可用性を成立させるための条件です。もう一点、既定のヘルスチェックは2秒間隔で3回連続の失敗をもって切り離すため、障害検知には約6秒かかります。この秒数を許容できるかは設計時に決めておく数字です。nginxやクラウドのマネージドLBという選択肢もあるなかで、HAProxyが向くのはL4/L7を細かく制御したい自前運用の場面です。フルマネージドで済ませたい構成や小規模な単一サーバーでは過剰になります。以下で定義・仕組み・設定・検証・冗長化・採否の判断を順に解説します。

HAProxyとは｜TCP/HTTPを振り分けるロードバランサー兼リバースプロキシの定義

最初にHAProxyが何をするソフトなのかを固めます。ここが曖昧だと、後半のnginxとの比較や採否の判断が宙に浮きがちです。HAProxyは、クライアントとサーバーの間に立ち、受けた通信を複数の実サーバーへ振り分ける中継役として動きます。

HAProxyとロードバランサー・リバースプロキシの関係と位置づけ

HAProxyは、TCPおよびHTTPのトラフィックを受け付け、あらかじめ登録したバックエンドサーバー群へ分配するオープンソースのプロキシです。単に通信を横流しするのではなく、各サーバーが生きているかを定期的に確認し、応答しないサーバーを振り分け先から自動で外します。この「分配」と「死活監視」の2つが揃うと、1台が落ちても残りのサーバーで処理を続けられます。ライセンスはGPLで、追加費用なしにLinux上へ導入できる点も採用の後押しです。実装はC言語の単一プロセス・イベント駆動で、ソースはGitHubのhaproxy/haproxyリポジトリで公開されています。単一プロセスで数万規模の同時接続をさばける処理性能が、採用理由になります。

HAProxyが兼ねる2つの役割：負荷分散とリバースプロキシ

HAProxyは、ロードバランサーとリバースプロキシという2つの役割を1つのソフトで兼ねます。負荷分散の一般的な考え方や振り分け方式の全体像はロードバランサーとは？仕組み・種類・振り分け方式を実装目線で解説【2026年版】で整理したとおりで、HAProxyはそれをソフトウェアで実装した具体的な製品です。同時に、クライアントの代わりに背後のサーバーへ通信を取り次ぐリバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説の性質も持ち、SSL終端やヘッダの書き換えといった前段処理も担えます。つまりHAProxyは「振り分けるLB」と「取り次ぐリバースプロキシ」が同居した製品だと捉えると位置づけがつかめます。

HAProxyが解決する課題：単一サーバーの処理限界とSPOF

サービスを1台のWebサーバーだけで運用すると、アクセスが増えたときの処理能力の頭打ちと、その1台が壊れたときの全停止という2つの問題が同時に起こります。前者はサーバーを増やして負荷を分散すれば緩和が可能です。後者は同じ役割のサーバーを複数持てば、1台の故障を吸収できます。HAProxyはこの入口に立ち、来た通信を空いているサーバーへ配り、落ちたサーバーを避けることで両方に対処します。裏を返せば、アクセスも少なくサーバーも1台でよいシステムに、HAProxyを挟む必然性はありません。

HAProxyの仕組み｜frontend/backendとL4・L7の処理モデル

HAProxyの動きは、設定ファイル haproxy.cfg のセクション構造を見ると理解しやすくなります。全体像さえ押さえれば、どこに何を書くソフトなのかは難しくありません。ここでは設定の4セクションと、動作モードの違いを確認します。

設定4セクション：global・defaults・frontend・backend

haproxy.cfg は役割の違う複数セクションで構成されます。globalはプロセス全体の共通設定（実行ユーザーやログ、PIDファイル）を、defaultsは各セクションの既定値をまとめて書く場所です。実際の振り分けを決めるのがfrontendとbackendで、frontendはbindで待ち受けるIP・ポートを定義し、backendはserverで転送先サーバーのホストとポートを列挙します。frontendとbackendを1つにまとめた簡潔な書き方としてlistenセクションも使えます。要は「どこで受けて（frontend）」「どこへ渡すか（backend）」の対応を書くのが設定の中心だと押さえてください。各キーワードの正確な文法と既定値はHAProxy 3.4のConfiguration Manualが一次情報です。

言葉で追うより、動く形を1つ見たほうが早い部分です。次が80番で受けて2台へ振り分けるだけの最小構成で、これをそのまま /etc/haproxy/haproxy.cfg に置けば起動します。

global
    log     /dev/log local0
    maxconn 20000
    user    haproxy
    group   haproxy
    daemon

defaults
    mode    http
    log     global
    option  httplog
    timeout connect 5s
    timeout client  30s
    timeout server  30s

frontend fe_web
    bind :80
    default_backend be_app

backend be_app
    balance roundrobin
    server app1 10.0.0.11:80 check
    server app2 10.0.0.12:80 check

読み方は単純で、frontend fe_web が入口、backend be_app が出口、その対応を default_backend が結んでいます。timeoutを書かないと起動時に警告が出るため、defaultsで3種類（connect・client・server）を最初から入れておくと余計な躓きを避けられます。

mode tcp（L4）とmode http（L7）の違いと使い分け

HAProxyには通信の見方が異なる2つの動作モードがあります。mode tcpはOSI参照モデルのL4で動き、パケットの中身を解釈せずTCP接続をそのまま振り分ける方式です。データベースやメールなどHTTP以外のプロトコルや、暗号化されたまま素通しさせたい通信に向きます。一方のmode httpはL7で動き、HTTPヘッダやURLパス、Cookieといったリクエストの中身を読んで振り分けます。パスごとに別のサーバー群へ流すといった制御は、このL7モードでのみ可能です。判断軸は単純です。通信の中身を見て振り分けたいならL7、速度と汎用性を取るならL4を選びます。

この区別はクラウドのマネージドLBでも同じで、AWSでいえばL7がALB、L4がNLBという製品の分かれ方に対応します（Elastic Load Balancingのユーザーガイド）。HAProxyは1つのソフトでmodeを切り替えるだけで両方をこなすため、L4とL7が混在する構成を1台の設定ファイルに収められる点が違いになります。

ACLによるコンテンツベースルーティングとリクエスト振り分け

mode httpの真価は、ACL（Access Control List）を使ったコンテンツベースの振り分けにあります。ACLは、パスが/apiで始まる・ホスト名が特定ドメイン・送信元IPが社内といった条件に名前を付けた判定ルールです。その真偽に応じてuse_backendで振り分け先を切り替えます。たとえば「/imagesは静的ファイル用サーバー群へ、それ以外はアプリサーバー群へ」という経路制御を、アプリ側を変えずHAProxyの設定だけで実現できます。単なる負荷分散にとどまらないこの柔軟さが、HAProxyの採用理由です。

SSL終端とパス別振り分けを同時に書くと、次の形になります。証明書はbind行にcrtで渡し、backendへは平文で流す構成です。

frontend fe_web
    bind :443 ssl crt /etc/haproxy/certs/example.pem
    http-request set-header X-Forwarded-Proto https

    acl is_static  path_beg /images /css /js
    acl is_api     path_beg /api
    acl from_office src 203.0.113.0/24

    http-request deny if is_api ! from_office
    use_backend be_static if is_static
    use_backend be_api    if is_api
    default_backend be_app

backend be_static
    balance roundrobin
    server st1 10.0.0.21:80 check

backend be_api
    balance leastconn
    server api1 10.0.0.31:8080 check
    server api2 10.0.0.32:8080 check

4行目以降のaclは条件に名前を付けているだけで、実際の分岐はuse_backendとhttp-request denyが担います。! from_office のように否定を組み合わせれば、社内IP以外からのAPI呼び出しを入口で落とす制御まで同じ場所に書けます。アプリ側のコードを触らずに経路と入口制御を変えられることが、前段にHAProxyを置く実利です。

HAProxyの負荷分散アルゴリズムとヘルスチェック設計｜振り分けと死活監視

frontendとbackendの対応を書いたら、次は「どのサーバーへ、どういう基準で配るか」を決めます。ここがHAProxyの設計で最も差が出る部分です。balanceによる配り方と、checkによる死活監視をセットで設計します。

balanceの選び分け：roundrobin・leastconn・source

振り分け方式はbackend（またはlisten）内のbalanceパラメータで指定します。主要なものは次の3つで、システムの性質に合わせて選びます。

アルゴリズム	振り分け基準	向いている場面
roundrobin	登録順に1台ずつ順番に割り当てる	サーバー性能が均一で負荷が揃う構成
leastconn	アクティブ接続数が最少のサーバーを選ぶ	接続が長く続く処理で偏りを避けたい構成
source	送信元IPで同じ利用者を同じサーバーへ	セッションをサーバー側に持ち固定したい構成

迷ったときの実務上の起点はroundrobinです。まず順番配りで様子を見て、接続が長引いて偏るならleastconn、クライアントとサーバーを紐づけたいならsourceへ切り替える、という順で検討すると外しません。全サーバーを等価に列挙せず、性能差があるサーバーにはweightで重み付けし、強いサーバーに多く配る調整も加えられます。

ヘルスチェック（check）による死活監視とフェイルオーバー

負荷分散を安全に成り立たせる鍵が、serverキーワードに付けるcheckオプションです。checkを指定すると、HAProxyは各バックエンドサーバーへ定期的に接続確認を行い、応答しないサーバーを振り分け対象から自動で外します。障害サーバーへ通信を送り続けてエラーを返す事態を防ぎ、復旧すれば自動で振り分けに戻す動きです。L7ではURLを叩いて特定の応答コードを確認する、といった中身に踏み込んだチェックも設定できます。単なるポート開放の確認より、精度の高い死活監視が可能です。この自動フェイルオーバーがあるからこそ、1台の故障がサービス全体の停止に直結しません。

backend be_app
    balance leastconn
    option httpchk
    http-check send meth GET uri /healthz ver HTTP/1.1 hdr Host app.example.com
    http-check expect status 200

    default-server inter 2s fastinter 500ms downinter 5s rise 2 fall 3

    server app1 10.0.0.11:8080 check weight 100
    server app2 10.0.0.12:8080 check weight 50
    server app3 10.0.0.13:8080 check backup

option httpchk と http-check の組み合わせで、/healthz を叩いて200が返るかまで見に行きます。TCPの口が開いているだけでアプリが機能不全という状態を弾けるので、本番のバックエンドには接続確認ではなくHTTPチェックを充てるのが安全側の設計です。backup を付けたサーバーは通常は振り分け対象外で、他が全滅したときだけ使われるため、メンテナンス画面の待避先として置けます。

検知までの秒数を決めるinter・rise・fallの既定値と調整

ヘルスチェックで見落とされがちなのが、障害を検知するまでの所要時間です。3.4系のConfiguration Manualによると、チェック間隔を決めるinterの既定は2000ミリ秒、ダウン判定に必要な連続失敗回数fallの既定は3、復帰判定に必要な連続成功回数riseの既定は2でした。つまり何も書かなければ、サーバーが落ちてから振り分け対象を外れるまでに約6秒、復帰を認識するまでにさらに約4秒かかります。この間のリクエストはエラーになるため、「HAProxyを入れたのに一瞬エラーが出た」という現象の多くはこの既定値で説明が付きます。

短くしたい場合は、状態が遷移しかけているときだけ間隔を詰めるfastinterが有効です。上のコード例のように inter 2s fastinter 500ms fall 3 と書けば、1回目の失敗以降は500ミリ秒間隔で確認するため、検知は約1.5秒まで縮みます。ただしチェックの頻度を上げるほど増えるのが、バックエンドへの負荷とログ量です。稼働率の目標から許容ダウン時間を逆算する考え方は可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】にまとめており、検知秒数もその目標から決めると根拠のある値になります。

スティッキーセッションとstick-tableによるセッション固定

ログイン状態などのセッションをアプリサーバーのメモリに持つ構成では、同じ利用者を毎回同じサーバーへ送る必要があります。これをスティッキーセッションと呼び、実現手段は主に3つです。前述のsourceアルゴリズム、Cookieを使う方式、stick-tableで送信元と振り分け先の対応を記録する方式が代表例です。ただし固定は分散の効きを弱め、固定先が落ちればそのセッションは失われます。設計としては、セッションをアプリ外（RedisやDB）に逃がして固定自体を不要にするほうが、分散と可用性の両面で扱いやすい構成です。

HAProxyを実際に動かして振り分けとフェイルオーバーを確認する

設定を書いたら、本番に入れる前に手元で挙動を見ておきます。ここで確かめておきたいのは、2台に交互に振り分いているか、1台を落としたときに自動で外れるか、設定変更を無停止で反映できるかの3点です。コンテナを使えば数分で用意できます。

docker composeでHAProxyと2台のWebサーバーを動かす

検証環境は、公式のhaproxyイメージと、リクエストを受けた自分のホスト名を返すコンテナを2台並べるだけで足ります。複数コンテナをまとめて定義する書き方はdocker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説で扱ったとおりで、次のcompose.yamlと、先ほどの最小構成のhaproxy.cfgを同じディレクトリに置きます。

services:
  haproxy:
    image: haproxy:3.4-alpine
    ports:
      - "8080:80"
      - "8404:8404"
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    depends_on:
      - app1
      - app2
  app1:
    image: traefik/whoami
  app2:
    image: traefik/whoami

haproxy.cfg 側の server 行は、コンテナ名で解決できるよう server app1 app1:80 check のように書き換えます。あとは起動して、同じURLを何度か叩くだけです。

docker compose up -d
for i in 1 2 3 4; do curl -s localhost:8080 | grep Hostname; done

# 1台止めて、自動で振り分け先から外れることを見る
docker compose stop app2
for i in 1 2 3 4; do curl -s localhost:8080 | grep Hostname; done

Hostnameが交互に入れ替われば振り分けは効いています。app2を止めた直後は既定の検知時間ぶんだけエラーが返り、そのあとapp1だけに寄るはずです。この「切り替わるまでに数秒かかる」挙動を目で見ておくと、前節のinter・fallの調整が何を意味するのかが腹に落ちます。

統計ページとRuntime APIで振り分け状態を確認する方法

本番運用では、どのサーバーがUPでどれだけ捌いているかを常時見える形にしておきます。HAProxyは統計ページを内蔵しており、有効にするために必要なのはfrontendを1つ足すことだけです。あわせて、Runtime API（管理用のUNIXソケット）を開けておくと、再起動せずにサーバーの切り離しと組み戻しができます。

# haproxy.cfg に追記する統計ページ
frontend fe_stats
    bind :8404
    mode http
    stats enable
    stats uri /stats
    stats refresh 5s

# global セクションに追記する管理ソケット
global
    stats socket /var/run/haproxy.sock mode 660 level admin

ブラウザで 8404 番の /stats を開けば、backendごとのUP/DOWNと現在のセッション数が一覧で出ます。ソケット経由の操作は次のとおりで、デプロイ時に1台ずつ外して入れ替えるローリング更新に使えます。

echo "show stat" | socat stdio /var/run/haproxy.sock
echo "disable server be_app/app2" | socat stdio /var/run/haproxy.sock
echo "enable server be_app/app2"  | socat stdio /var/run/haproxy.sock

3.4系ではこの系統がさらに広がり、backend自体をCLIから作成・サーバー追加・公開・削除できるdynamic backendsが入りました。設定ファイルの書き換えとreloadを伴わずに構成を変えられるため、オーケストレータ側から入口を組み替える運用と相性の良い方向へ進んでいます。

設定ミスを止めるhaproxy -cとreloadの無停止反映手順

入口のソフトウェアで最も避けたい事故は、設定ミスによる起動失敗です。HAProxyには構文チェック専用のオプションがあり、反映前に必ず通す運用にしておけば、この事故はほぼ潰せます。CI上で設定ファイルの変更をチェックする使い方も同じコマンドで済みます。

# 構文チェック（反映前に必ず通す。異常があれば非ゼロで終わる）
haproxy -c -f /etc/haproxy/haproxy.cfg

# バージョンとビルドオプションの確認
haproxy -vv

# 無停止で設定を反映（既存接続を処理しきってから旧プロセスが終了する）
systemctl reload haproxy

restartは接続を切りますが、reloadは新しいプロセスを起こして待ち受けを引き継ぎ、旧プロセスは処理中の接続を終えてから落ちます。設定変更のたびにrestartしている現場では、この動作の差が無用な瞬断を引き起こす原因です。CI/CDのパイプラインに haproxy -c を組み込む進め方は、インフラ設定をコードとして扱う流れの一部として設計すると運用が安定します。

HAProxyの導入手順と冗長化｜最小構成の設定例とKeepalived

手元で挙動を確認できたら、本番構成に落とします。導入自体は数ステップで済みますが、本番投入で必ず問題になるHAProxy自身の冗長化まで含めて設計するのが実装の勘所です。

HAProxyのインストールと最小構成のhaproxy.cfg

主要なLinuxディストリビューションではパッケージマネージャ（apt/dnf等）で導入でき、設定ファイルは /etc/haproxy/haproxy.cfg に置きます。ディストリビューション同梱のパッケージは版が古いことがあるため、後述するLTS系列を狙って入れたい場合は公式が案内するリポジトリやコンテナイメージを使う判断になります。設定の骨格は先に示した最小構成のとおりで、frontendで80番を待ち受け、backendに2台のserverをcheck付きで並べ、balanceにroundrobinを指定するだけです。まずこの形で挙動を確認してから、L7の条件分岐やアルゴリズムの調整に進むのが安全です。

HAProxy自身のSPOF回避：Keepalived＋VRRPによる冗長化

負荷分散で背後のサーバーを何台冗長化しても、入口のHAProxyが1台なら、そこが単一障害点です。この構造的な弱点は、HAProxyを2台用意し、KeepalivedとVRRPで仮想IP（VIP）を共有すると解消できます。VRRPはRFC 5798で規定された、複数のルーター（ここではLB）で1つの仮想IPを持ち回るプロトコルです。通常はアクティブ側がVIPを保持して通信を受け、落ちるとスタンバイ側がVIPを引き継ぎます。

vrrp_script chk_haproxy {
    script   "/usr/bin/killall -0 haproxy"
    interval 2
    weight   2
}

vrrp_instance VI_1 {
    state             MASTER
    interface         eth0
    virtual_router_id 51
    priority          101
    advert_int        1
    authentication {
        auth_type PASS
        auth_pass changeme
    }
    virtual_ipaddress {
        192.0.2.100/24
    }
    track_script {
        chk_haproxy
    }
}

要点はvrrp_scriptとtrack_scriptです。これを書かないと、Keepalivedは自分（Keepalivedプロセス）の生死しか見ないため、サーバーは生きているのにHAProxyだけ落ちた状態でVIPを握り続けます。HAProxyのプロセス有無を条件に優先度を上下させて初めて、実サービスの停止に連動した切り替えになります。負荷分散と冗長化は別物であり、この切り分けは冗長化とは？二重化との違い・種類と構成、企業の設計判断まで解説【2026年版】の整理と対で押さえたい観点です。

HAProxyのバージョン選定と運用：3.4系LTSと保守方針

HAProxy公式（haproxy.org）のバージョン表を2026年9月11日に確認したところ、最新の安定系列は3.4系で、ブランチの公開は2026年6月3日、サポート期限は2031年第2四半期のLTSとして案内されていました。同時点の最新パッチは3.4.4（2026年8月27日公開）です。長期サポート対象は3.4系のほか3.2系（2030年第2四半期まで）と3.0系（2029年第2四半期まで）で、3.3系は2027年第1四半期までの通常安定版という位置づけでした。

選定で注意したいのは、番号が新しいほど寿命が長いとは限らない点です。同じ表で3.1系はすでに2026年第1四半期にunmaintainedへ入っており、非LTSの系列は1年強で保守が切れます。新規構築では長期サポート対象のLTS系列（この時点なら3.4系・3.2系・3.0系）から選ぶのが運用面で扱いやすい判断です。開発版としては3.5-dev6（2026年9月3日）が出ており、3.5安定版は2026年第4四半期の見込みと案内されています。設定の書式はメジャー系列間でおおむね継続していますが、機能追加や既定値の変更は起こるため、採用する系列の公式ドキュメントで該当バージョンの記述を一次情報として確認してから設定を固めます。

nginx・クラウドLBとの違いとHAProxyを採用すべき場面・見送る場面

HAProxyは唯一の選択肢ではありません。同じ役割はnginxやクラウドのマネージドLBでも果たせます。ここでは違いを整理したうえで、どんなときにHAProxyを選び、どんなときに見送るかを条件付きで言い切ります。

nginx・クラウドマネージドLBとHAProxyの違いと選定

3者は守備範囲が重なりつつ、得意分野が異なります。選定の目安を整理します。

比較軸	HAProxy	nginx	クラウドマネージドLB（ALB/NLB等）
主目的	負荷分散・プロキシ専用	Webサーバー＋リバースプロキシ兼用	マネージドな負荷分散
L4/L7	L4・L7とも細かく制御可	L7中心（L4はstreamモジュール）	L4/L7で製品が分かれる
ヘルスチェック	HTTP応答まで既定で確認可	能動監視は商用版が中心	マネージド側の設定で指定
運用負荷	自前で冗長化・監視が必要	自前運用が必要	冗長化・スケールは提供側が担う
向く場面	振り分けを細かく作り込む自前基盤	静的配信とプロキシを1台で兼ねたい	運用を任せてインフラ設計を軽くしたい

nginxは静的ファイル配信やアプリ実行を含めて1台で兼ねたいときに強く、HAProxyは負荷分散とヘルスチェックの制御そのものを作り込みたいときに強い、という住み分けです。実装レベルの差として分かりやすいのがヘルスチェックで、nginxのngx_http_upstream_moduleのドキュメントを読むと、能動的にバックエンドを叩くhealth_checkディレクティブは商用版のNGINX Plus向けとして記載されています。オープンソース版のnginxは実リクエストの失敗回数で切り離すmax_fails方式が基本で、HAProxyのように無通信時も定期的にURLを叩いて確かめる動きは標準では入りません。「負荷分散だけを堅くやりたい」要件でHAProxyが選ばれるのは、この差が効くためです。

似た前段の役割を持つAPIゲートウェイとは？役割・機能とリバースプロキシ／サービスメッシュとの違い・導入判断を解説と比べると、HAProxyは認証やレート制限といったAPI管理機能ではなく、あくまで通信の分配と可用性に軸足がある点が異なります。

HAProxyを採用すべき場面：負荷分散を作り込みたい自前基盤

HAProxyが第一候補になるのは、次の条件が重なるときです。オンプレミスや自前で構築したクラウドVM上で、複数の実サーバーへ負荷を分散し、その振り分け方式やヘルスチェックの条件を自分で細かく制御したい場合。加えて、L4のTCP負荷分散（データベースやメール等）が必要で、Webサーバー機能は別に持っている場合。この2条件がそろうなら、単一プロセスで高い同時接続をさばけるHAProxyが素直な選択です。水平にサーバーを増やして受けきる設計は、スケールアウトとスケールアップとは？水平・垂直スケーリングの違いと実装・使い分けを実装目線で解説【2026年版】で示した水平スケールの実装手段そのものであり、HAProxyはその入口を担います。

HAProxyを見送るべき3つの場面とインフラ設計の相談先の判断

逆に、次の場合はHAProxyを見送るほうが合理的です。第一に、サーバーが1台で当面アクセス増の見込みもないシステム。ここに負荷分散を挟むのは運用対象を増やすだけで、得るものがありません。第二に、AWSやクラウド上で完結し、冗長化やスケールを提供側に任せたい構成。マネージドLBを使えばHAProxy自身の2台構成やKeepalivedの保守が不要になり、運用が軽くなります。第三に、Kubernetes上でコンテナを運用する場合。コンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説で扱うとおり、k8sはServiceやIngressとして負荷分散の仕組みを内包するため、その内側に別途HAProxyを立てる必然性は薄くなります（Ingress Controllerの実体としてHAProxyを選ぶ選択肢はあります）。

どのLBを選ぶか、そもそも冗長化をどこまで作り込むかは、可用性の目標と運用体制から逆算する設計判断です。自前運用を選ぶなら、HAProxyの2台構成・Keepalivedの保守・統計の監視・バージョン追随という運用対象が増える点まで見積もりに入れてください。自社での構成設計や構築に迷う場合は、負荷分散・冗長化を含むインフラ構築（AWS/GCP/Azure）の受託で、要件に合わせた可用性設計から相談できます。

HAProxyとロードバランサー・負荷分散に関するよくある質問

検索されることの多い疑問に、仕組みと選定の両面から簡潔に答えます。

HAProxyとは何ですか？

クライアントからの通信を複数のバックエンドサーバーへ振り分ける、TCP/HTTP対応の高性能ロードバランサー兼リバースプロキシのオープンソースソフトウェアです。名前はHigh Availability Proxyの略で、負荷分散とサーバーの死活監視により、1台への集中と単一障害点を解消する目的で使われます。Linux上に無償で導入でき、単一プロセスで高い同時接続をさばけます。2026年9月時点の最新安定系列は3.4系（LTS・サポートは2031年第2四半期まで）です。

HAProxyとnginxの違いは何ですか？

主目的が違います。HAProxyは負荷分散とプロキシに特化した専用ソフトで、L4のTCP負荷分散やヘルスチェックの制御を細かく作り込めます。nginxはWebサーバー機能を持ち、静的配信やアプリ実行とリバースプロキシを1台で兼ねられるのが強みです。実装差として、URLを定期的に叩く能動的なヘルスチェックはHAProxyなら標準機能ですが、nginxの同等機能（health_check）は商用版のNGINX Plus向けです。負荷分散の制御を突き詰めるならHAProxy、Webサーバーと前段プロキシをまとめたいならnginxという選び分けになります。

HAProxyのL4とL7の違いは何ですか？

通信の見方が異なります。L4（mode tcp）はパケットの中身を解釈せず、TCP接続をそのまま振り分ける方式です。HTTP以外のプロトコルや暗号化通信の素通しに向きます。L7（mode http）はHTTPヘッダやURLパス、Cookieを読んで振り分けるため、パスごとに別サーバーへ流すコンテンツベースの制御ができます。中身を見て振り分けたいならL7、速度と汎用性を取るならL4です。クラウドのマネージドLBでいえば、L7がALB、L4がNLBに対応する区別だと考えてください。

HAProxyの負荷分散アルゴリズムはどれを選べばよいですか？

起点はroundrobin（順番配り）です。各サーバーの性能が均一で1リクエストの重さが揃うなら、まずこれで十分でしょう。接続が長く続いて偏るならleastconn（接続数最少を選ぶ）、同じクライアントを同じサーバーに固定したいならsource（送信元IPで固定）へ切り替えます。性能差のあるサーバーへの配分を調整する方法は、weightで重みを付けることです。切り替えの判断は統計ページのセッション数の偏りを見てから行うと、感覚ではなく実測で決められます。

HAProxy自体が故障したらどうなりますか？

入口が1台なら、そこが単一障害点になり全体が止まります。これを防ぐため、本番ではHAProxyを2台構成にし、KeepalivedとVRRPで仮想IP（VIP）を共有する構成が定番です。アクティブ側が落ちるとスタンバイ側がVIPを引き継ぎ、処理を継続します。このときvrrp_scriptでHAProxyプロセスの生死を監視対象に加えておかないと起こるのが、HAProxyだけ落ちた状態でVIPを握り続ける事故です。バックエンドの冗長化とHAProxy自身の冗長化は別の設計であり、両方そろえて初めて止まらない入口になります。