Squid はフォワードプロキシとして知られていますが、http_port に accel を付けて cache_peer で転送先を指定すると、Web サイトの前段に置くリバースプロキシ（アクセラレーター）として動きます。WordPress の前に置く場合に一番大切なのは、ログイン中のユーザーや管理画面のページをキャッシュさせない設定です。この記事では、accel モードの最小構成から、WordPress 向けのキャッシュ除外、実際にキャッシュが効いているかの確認方法までを説明します。
HTTPS を Squid で受けて復号する構成は、別記事「Squid でSSLターミネーションする方法」で扱っています。この記事では HTTP の受け口と転送・キャッシュの設計に絞ります。
フォワードプロキシとリバースプロキシの違い
フォワードプロキシは、社内の利用者などが外部のサイトへアクセスするときに通る中継点です。リバースプロキシはその逆で、外部からのアクセスを自分のサイトの前で受け止め、裏にあるサーバーへ渡します。
Squid をリバースプロキシとして使う主な目的は次の2つです。
- よく見られるページや画像をキャッシュして、WordPress（PHP と DB）の負荷を下げる
- 外部に公開するのを Squid だけにして、バックエンドのサーバーを直接さらさない
同じ Squid でも、フォワードプロキシ用の既定設定のまま公開すると、第三者に中継サーバーとして悪用されるおそれがあります。リバースプロキシとして使う場合は、受け付けるドメインを限定する設定が欠かせません。
手順1：構成を決めてバックエンドのポートを変える
ここでは、同じサーバー上で次のように役割を分けます。
- Squid：80 番ポートで外部からのリクエストを受ける
- Apache または Nginx（WordPress）：127.0.0.1 の 8080 番ポートで待ち受ける
Web サーバーの待ち受けポートを変える前に、設定ファイルのバックアップを取ります。Apache なら Listen 127.0.0.1:8080 とバーチャルホストのポート、Nginx なら listen 127.0.0.1:8080; に変更します。127.0.0.1 で待ち受けることで、バックエンドに外部から直接アクセスできなくなります。
作業中はサイトが一時的に表示できなくなる時間が出るため、ステージング環境で手順を確かめてから本番で実施してください。
手順2：squid.conf を accel モードで書く
既存の squid.conf を退避してから編集します。
sudo cp /etc/squid/squid.conf /etc/squid/squid.conf.bak.$(date +%Y%m%d)最小構成の例です。
# 80番でアクセラレーターとして受ける
http_port 80 accel defaultsite=example.com vhost
# 転送先（オリジン）
cache_peer 127.0.0.1 parent 8080 0 no-query originserver name=wp_origin
# 受け付けるドメインを限定する
acl our_sites dstdomain example.com www.example.com
http_access allow our_sites
cache_peer_access wp_origin allow our_sites
cache_peer_access wp_origin deny all
http_access deny all
# キャッシュの容量
cache_mem 256 MB
maximum_object_size_in_memory 1 MB
cache_dir ufs /var/spool/squid 2000 16 256
maximum_object_size 20 MB各行の役割は次のとおりです。
accelは、このポートをリバースプロキシ用として扱う指定です。vhostで Host ヘッダーを見て処理し、defaultsiteは Host ヘッダーがないときの既定値になります。cache_peer ... originserverは、転送先が別のプロキシではなく Web サーバーそのものであることを示します。no-queryは、プロキシ同士の問い合わせ（ICP）を使わない指定です。http_access deny allを最後に置き、許可したドメイン以外は拒否します。Squid はアクセス制御を上から順に評価するため、この行より前に許可ルールを書く必要があります。cache_memはメモリ上のキャッシュ容量、cache_dirはディスク上のキャッシュの場所と容量（この例では約2,000MB）です。サーバーのメモリとディスクの空きに合わせて調整します。
cache_dir を新しく設定した場合は、最初にキャッシュ用ディレクトリを初期化します。
sudo squid -z
sudo squid -k parse
sudo systemctl restart squid手順3：WordPress でキャッシュしてはいけないページを除外する
ここが WordPress で最もつまずきやすい部分です。ログイン中のユーザー向けに生成されたページをキャッシュすると、管理バーや他人の情報が別の訪問者に表示される事故につながります。Cookie と URL を見て、キャッシュ対象から外します。
# ログイン中・コメント投稿者・パスワード保護ページ閲覧者のCookie
acl wp_cookie req_header Cookie -i (wordpress_logged_in_|wordpress_sec_|comment_author_|wp-postpass_)
# 管理画面・ログイン・Ajax・REST API・プレビュー
acl wp_nocache_path urlpath_regex -i ^/wp-admin/ ^/wp-login\.php ^/wp-json/ ^/xmlrpc\.php
acl wp_preview urlpath_regex -i [?&]preview=true
cache deny wp_cookie
cache deny wp_nocache_path
cache deny wp_previewcache deny に一致したリクエストは、キャッシュを使わず毎回オリジンへ転送されます。EC サイト用のプラグイン（WooCommerce など）を使っている場合は、カートや決済のページ、カート用の Cookie も除外対象に加えます。プラグインが使う Cookie 名やページの URL はバージョンや設定で変わるため、実際のレスポンスヘッダーや開発者ツールで確認したうえで ACL に追加してください。
キャッシュの有効期間は WordPress 側のヘッダーで決める
Squid は、オリジンが返す Cache-Control や Expires ヘッダーを基準にキャッシュの可否と期間を決めます。これらのヘッダーがない場合は、refresh_pattern の値をもとに推測で期間を決めます。
refresh_pattern -i \.(css|js|png|jpe?g|gif|webp|svg|woff2?)$ 1440 50% 10080
refresh_pattern . 0 20% 4320refresh_pattern の数値は、最短期間（分）、最終更新日時からの割合、最長期間（分）の順です。HTML について長めの期間を強制するオプションもありますが、記事を更新しても古いページが出続ける原因になるため、HTML の期間は WordPress 側（キャッシュプラグインや Web サーバーの設定）が返すヘッダーで管理するほうが扱いやすくなります。Squid はキャッシュの一括削除が得意ではないので、HTML は短め、画像や CSS は長めという方針が無難です。
手順4：実際にキャッシュが効いているか確認する
同じ URL に2回リクエストを送り、レスポンスヘッダーを比べます。
curl -sI http://example.com/sample-page/ | grep -iE 'x-cache|age|cache-control'
curl -sI http://example.com/sample-page/ | grep -iE 'x-cache|age|cache-control'Squid は既定で X-Cache ヘッダーを付けるため、1回目が MISS、2回目が HIT になればキャッシュが効いています。Age ヘッダーはキャッシュされてからの経過秒数です。ヘッダーの名前や有無は設定やバージョンで変わる場合があります（2026年10月現在）。
アクセスログでも確認できます。
sudo tail -f /var/log/squid/access.logログの結果コードが TCP_HIT や TCP_MEM_HIT ならキャッシュから応答、TCP_MISS ならオリジンから取得、TCP_REFRESH_UNMODIFIED ならオリジンに確認したうえでキャッシュを再利用しています。ログインした状態のブラウザでアクセスしたときに、すべて MISS になっていれば Cookie による除外が効いています。
手順5：WordPress 側で接続元 IP を正しく扱う
Squid を経由すると、WordPress から見た接続元 IP はすべて 127.0.0.1 になります。ログイン試行の制限やアクセス解析、コメントのスパム判定が正しく動かなくなるため、Squid が付ける X-Forwarded-For ヘッダーから本来の IP を復元します。Squid は既定で X-Forwarded-For を付けます（forwarded_for ディレクティブで制御できます）。
Apache なら mod_remoteip を有効にして、信頼するプロキシを指定します。
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1信頼するプロキシを限定せずにヘッダーを信用すると、クライアントが偽の IP を名乗れてしまいます。復元の設定は、プロキシのアドレスを明示したうえで行ってください。
まとめ
- Squid のリバースプロキシは
http_port ... accelとcache_peer ... originserverで組む - 受け付けるドメインを ACL で限定し、最後に
http_access deny allを置いて中継の悪用を防ぐ - WordPress ではログイン Cookie、管理画面、REST API、プレビューを
cache denyで除外する - HTML のキャッシュ期間は WordPress 側のヘッダーで管理し、静的ファイルは長めにする
- X-Cache ヘッダーと access.log の結果コードでキャッシュの効き具合を確認する