HAProxy と Squid の比較｜負荷分散とフォワードプロキシ・キャッシュの違いと使い分け

HAProxy と Squid はどちらも「プロキシ」と呼ばれますが、得意な向きが反対です。HAProxy は外から来たリクエストを複数のサーバーへ振り分ける受け側（リバースプロキシ・ロードバランサー）が本業で、Squid は内側の端末やサーバーが外へ出ていく通信を中継・制限・キャッシュする出口側（フォワードプロキシ）が本業です。この記事では、両者の役割の違い、キャッシュの扱い、WordPress 運用でそれぞれをどこに置くかを、設定例とともに整理します。

向きの違いを押さえる

プロキシには大きく2つの向きがあります。

• リバースプロキシ：インターネット上の訪問者から見て「サイトの入口」。訪問者は裏にサーバーが何台あるかを知りません。HAProxy、Nginx、Apache mod_proxy などがこの用途で使われます。
• フォワードプロキシ：社内やサーバー群から見て「外への出口」。利用する側がプロキシの存在を設定して使います（ブラウザのプロキシ設定や環境変数 https_proxy など）。Squid の代表的な用途です。

Squid にもリバースプロキシとして動かすモード（アクセラレーターモード）がありますし、HAProxy で外向きの通信を中継することも工夫すれば不可能ではありません。ただ、どちらも本業ではない用途では設定が回りくどくなり、情報も少なくなります。まずは「入口を作りたいのか、出口を作りたいのか」で考えると選択を誤りにくくなります。

比較の要点

キャッシュの違い

キャッシュの厚みは両者の大きな差です。Squid はもともとキャッシュプロキシとして発展してきたソフトで、cache_dir でディスク上に大きなキャッシュ領域を持ち、HTTP のキャッシュ制御ヘッダーに沿って再利用を判断します。

HAProxy にも cache セクションによるキャッシュ機能がありますが、メモリ上に小さなオブジェクトを短時間置く用途を想定したものです。画像や CSS の一部を前段で返して裏の負荷を少し減らす、といった使い方が中心で、Squid や Varnish のような大規模キャッシュの代わりにはなりません。

WordPress のページそのものをキャッシュする場合は、どちらのソフトでも「ログイン中の利用者」「カートやマイページ」「プレビュー」を外す設定が必要です。WordPress はログイン時に wordpress_logged_in_ で始まる Cookie を付けるので、その Cookie があるリクエストはキャッシュを通さないのが基本です。ページキャッシュ用途なら、WordPress 側のキャッシュプラグインや、より用途に合ったキャッシュ層を先に検討するほうが運用しやすいことが多いです。

Squid をフォワードプロキシとして使う例

WordPress のサーバーから外へ出る通信を Squid に集める例です。プラグインの更新やライセンス認証で外部へ出る先を限定でき、どこへ通信しているかをログで追えるようになります。

# /etc/squid/squid.conf の要点（既定の acl と http_access の並びをこの形に整理する例）
acl wpservers src 10.0.0.0/24
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl CONNECT method CONNECT
acl wp_dest dstdomain .wordpress.org .github.com

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow wpservers wp_dest
http_access deny all

http_port 3128

http_access は上から順に評価され、最初に一致した行で決まります。deny all より後に書いた許可は効かないので、許可の行は手前に置きます。宛先ドメインは例なので、実際に使っているプラグインの通信先をアクセスログで確かめながら調整してください。

WordPress 側は wp-config.php に次の定数を書くと、WordPress の HTTP API（wp_remote_get など）がプロキシを経由します。編集前に wp-config.php をバックアップしてください。

define( 'WP_PROXY_HOST', '10.0.0.5' );
define( 'WP_PROXY_PORT', '3128' );
define( 'WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com' );

自サイトへのループバック通信（WP-Cron やサイトヘルスの確認）までプロキシに流れないよう、WP_PROXY_BYPASS_HOSTS に自サイトのホスト名を入れておきます。プラグインによっては HTTP API を使わず独自に通信するものがあり、その場合はこの定数が効きません。

HAProxy を入口に置く例

訪問者からの通信を受けて、2台の WordPress へ振り分ける最小構成です。

frontend fe_web
    mode http
    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
    mode http
    balance roundrobin
    option httpchk
    http-check send meth GET uri /healthz.php
    server app1 10.0.0.11:8080 check
    server app2 10.0.0.12:8080 check

HAProxy は1台が応答しなくなると自動で振り分け先から外し、戻れば復帰させます。WordPress 側では X-Forwarded-Proto を受けて HTTPS と判定させる設定と、プロキシ以外からの直接アクセスを塞ぐファイアウォール設定がセットで必要です。

WordPress 運用でどちらを置くか

• 訪問者が増えてサーバーを複数台にしたい：HAProxy（入口）
• サーバーから外への通信先を絞りたい、監査したい：Squid（出口）
• 社内ネットワークからのアクセスをまとめて制御したい：Squid（出口）
• 静的ファイルを前段でたくさんキャッシュしたい：Squid のアクセラレーターモードも選択肢ですが、Varnish や CDN、Nginx のキャッシュと比べてから決める
• 両方必要：入口に HAProxy、出口に Squid という併用は珍しくありません。役割が重ならないので、設定もそれぞれ単純に保てます

Squid で HTTPS の中身まで検査する機能（SSL Bump）もありますが、通信内容の復号を伴うため、利用者への告知や社内規程、証明書の配布など運用上の準備が大きくなります。必要性をよく検討したうえで、公式ドキュメントに沿って進めてください。

どちらのソフトも版ごとに機能や設定の書式が変わります（2026年10月現在）。導入時は使う版のドキュメントを確認し、ステージングで動作を確かめてから本番に反映してください。

まとめ

• HAProxy は入口（リバースプロキシ・負荷分散）、Squid は出口（フォワードプロキシ・アクセス制御・キャッシュ）が本業です。
• 大きなキャッシュが必要なら Squid、HAProxy のキャッシュは小さなオブジェクト向けの補助と考えます。
• WordPress から外への通信は WP_PROXY_HOST などの定数で Squid に集められます。自サイト宛ては除外します。
• 両者は競合せず、入口と出口に分けて併用する構成も一般的です。
• 変更前にバックアップを取り、ステージングで確認してから本番へ反映します。

• Squid のリバースプロキシ設定方法
• プロキシサーバー経由で外部にアクセスする設定