Squidプロキシサーバーの設定方法：アクセス制限・認証・キャッシュとWordPressからの利用

Squid をフォワードプロキシとして使うには、パッケージを入れたあと squid.conf で「誰に使わせるか（acl と http_access）」を決め、squid -k parse で構文を確かめてから再読み込みし、curl -x で動作を確認します。この記事では、社内やサーバー群からの外向き通信をまとめる用途を想定し、アクセス制限、宛先の制限、認証、キャッシュ、ログの読み方、WordPress から Squid を経由させる設定までを説明します。

Squid で何ができるか

Squid は、クライアントの代わりに Web サーバーへアクセスする「フォワードプロキシ」としてよく使われます。主な用途は次のとおりです。

• 外向き通信の出口をまとめる: 複数のサーバーからの外部 API へのアクセスを1台にまとめれば、相手側の許可リストに登録する IP アドレスが1つで済みます。
• 接続先を制限する: Web サーバーが接続してよい宛先を決めておけば、改ざんされたプラグインが外部へ不審な通信をしようとしても止めやすくなります。
• 記録を残す: いつ、どこから、どの宛先へアクセスしたかがログに残ります。

なお、Web サイトの手前に置いて訪問者からのアクセスを受ける「リバースプロキシ」の用途もありますが、現在は nginx などで構成することが多く、この記事では扱いません。

インストールと設定ファイルの場所

# Debian / Ubuntu
sudo apt install squid

# RHEL 系（AlmaLinux、Rocky Linux など）
sudo dnf install squid
sudo systemctl enable --now squid

squid -v   # 版とビルド時のオプションを確認

設定ファイルは /etc/squid/squid.conf です。既定のファイルは説明のコメントが大部分を占めているため、有効な行だけを見るには次のようにします。編集する前に、元のファイルを残しておいてください。

sudo cp -a /etc/squid/squid.conf /etc/squid/squid.conf.orig
grep -Ev '^[[:space:]]*(#|$)' /etc/squid/squid.conf

Debian 系のパッケージでは、/etc/squid/conf.d/ 配下のファイルを読み込む設定が入っていることがあります。既定の内容や版はディストリビューションによって異なるので（2026年10月現在）、手元のファイルを確認してから編集してください。待ち受けるポートは既定で 3128 番（http_port 3128）です。

アクセス制限：acl と http_access の考え方

Squid の制御は、条件に名前を付ける acl と、その条件で許可・拒否を決める http_access の組み合わせで書きます。理解しておくべき規則は3つです。

1. http_access は上から順に評価され、最初に一致した行で決まる。後ろに書いた許可は、前の拒否より優先されません。
2. 1つの acl に複数の値を書くと「または」。acl office src 192.168.10.0/24 192.168.20.0/24 は、どちらかの範囲に当てはまれば一致します。
3. 1行の http_access に複数の acl を並べると「かつ」。すべての条件を満たしたときだけ、その行が一致します。

既定の設定には、危険なポートへの接続を拒否する行（Safe_ports、SSL_ports）と、最後にすべてを拒否する http_access deny all が入っています。その間に、自分の許可ルールを書く場所を示すコメントがあるので、そこに追加します。

# 許可する接続元
acl office    src 192.168.10.0/24
acl wpservers src 10.0.0.11 10.0.0.12

# WordPress サーバーが接続してよい宛先
acl wp_dest dstdomain .wordpress.org .github.com

http_access allow office
http_access allow wpservers wp_dest
# （この下に既定の http_access deny all がある）

この例では、事務所のネットワークからはどこへでも接続でき、WordPress サーバーからは wordpress.org と github.com（先頭の . でサブドメインも含む）にだけ接続できます。既定の設定に localnet という名前で私設アドレス全体が定義されていることがありますが、範囲が広すぎる場合は、上のように実際に使う範囲で定義し直したほうが安全です。

もっとも避けるべきなのは、http_access allow all のように誰でも使える状態（オープンプロキシ）にすることです。見つかると、第三者に攻撃や不正アクセスの踏み台として使われます。Squid の設定に加えて、ファイアウォールでも 3128 番への接続を許可した接続元だけに絞ってください。

HTTPS の通信で見えるもの

HTTPS のサイトへは、クライアントが Squid に CONNECT 宛先:443 を送り、Squid は暗号化された通信をそのまま中継します。Squid に分かるのは宛先のホスト名とポートだけなので、dstdomain による宛先の制限は効きますが、URL のパスによる制限やキャッシュはできません。通信を復号して中身を検査する機能（SSL Bump）もありますが、クライアントへの独自の証明書の配布が必要で、利用者のプライバシーや社内規程との調整も伴います。導入する場合は公式ドキュメントを読み、十分に検証してください。

認証を付ける

接続元のアドレスで絞れない場合は、ユーザー名とパスワードによる認証を付けます。パスワードファイルは、Apache の htpasswd コマンド（Debian 系は apache2-utils、RHEL 系は httpd-tools に含まれます）で作ります。

sudo htpasswd -c /etc/squid/passwords proxyuser
sudo chown root:proxy /etc/squid/passwords   # RHEL 系ではグループが squid
sudo chmod 640 /etc/squid/passwords

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED

http_access allow authenticated

認証ヘルパー basic_ncsa_auth の場所は、Debian 系では /usr/lib/squid/、RHEL 系では /usr/lib64/squid/ 配下が一般的です。ls で実際の場所を確かめてから書いてください。

注意したいのは、Basic 認証ではユーザー名とパスワードがほぼそのままの形でプロキシまで送られることです。クライアントと Squid の間の通信が盗み見られる環境では使わず、社内ネットワークや VPN の中に限るか、接続元の制限と組み合わせます。Squid 自体には認証の試行回数を制限する仕組みが乏しいため、ログに記録される認証の失敗を監視し、接続元の制限を併用するのが現実的です。

キャッシュの設定

Squid は HTTP の応答を保存し、同じ内容への2回目以降のアクセスを速くできます。ただし、前述のとおり HTTPS の通信はキャッシュされないため、現在の Web では効果が出る場面は限られます。パッケージの更新ファイルなど、HTTP で配られる大きなファイルを多数のサーバーで取得する場合に向いています。

cache_mem 256 MB
maximum_object_size 200 MB
cache_dir ufs /var/spool/squid 10000 16 256

cache_dir の数値は、使うディスク容量（MB）と、内部で作るディレクトリの数です。ディスクのキャッシュを新たに設定したときは、サービスを止めて sudo squid -z で保存先を作ってから起動します。キャッシュ用の容量は、ディスクの空きに余裕を残して決めてください。

反映と動作確認

設定を変えたら、まず構文を確認し、問題がなければ再読み込みします。

sudo squid -k parse
sudo systemctl reload squid

squid -k parse でエラーや警告が出た場合は、表示された行番号の記述を見直します。動作は、クライアントから curl で確かめます。

curl -x http://192.168.10.5:3128 -sI https://wordpress.org/ | head -n 1
curl -x http://192.168.10.5:3128 --proxy-user proxyuser -sI https://wordpress.org/

--proxy-user にユーザー名だけを渡すと、パスワードは実行時に入力を求められるので、コマンドの履歴に残りません。

access.log の読み方

接続の記録は /var/log/squid/access.log に残ります。各行の4列目にある結果コードを見ると、何が起きたかが分かります。

• TCP_MISS/200: キャッシュに無く、取りに行って成功した。
• TCP_HIT/200・TCP_MEM_HIT/200: キャッシュから返した。
• TCP_TUNNEL/200: HTTPS の CONNECT を中継した。
• TCP_DENIED/403: http_access で拒否された。ルールの順序と acl の条件を見直します。
• TCP_DENIED/407: 認証が必要、または認証に失敗した。

Squid が起動しない、宛先に接続できないといった問題は、/var/log/squid/cache.log に理由が出ます。起動しない場合は、3128 番を別のプロセスが使っていないか（ss -ltnp | grep 3128）、キャッシュの保存先の権限が正しいかも確認します。

WordPress から Squid を経由させる

WordPress は、wp-config.php に定数を書くと、コアの HTTP API（wp_remote_get() など）による外部への通信をプロキシ経由にできます。プラグインやテーマの更新確認もこの仕組みを使います。

// wp-config.php（"That's all, stop editing!" の行より上に書く）
define( 'WP_PROXY_HOST', '10.0.0.5' );
define( 'WP_PROXY_PORT', '3128' );
// 認証を使う場合
define( 'WP_PROXY_USERNAME', 'proxyuser' );
define( 'WP_PROXY_PASSWORD', 'your-proxy-password' );
// プロキシを通さない宛先
define( 'WP_PROXY_BYPASS_HOSTS', 'localhost, *.example.com' );

wp-config.php を編集する前にバックアップを取り、ステージング環境で試してから本番に反映してください。パスワードを書く場合は、wp-config.php のパーミッションを必要以上に緩めないよう注意します。また、HTTP API を使わずに独自に通信するプラグインには、この設定が効かないことがあります。

宛先を dstdomain で絞る場合、どの宛先が必要かは、ステージング環境で宛先を制限せずに更新や連携機能を一通り動かし、access.log に記録された宛先から洗い出すのが現実的です。更新の確認やダウンロードには api.wordpress.org や downloads.wordpress.org など wordpress.org のサブドメインが使われますが、プラグインによっては別の宛先にも接続します。許可漏れがあると更新や外部サービスとの連携が失敗するので、拒否された宛先（TCP_DENIED/403）をログで確認しながら調整してください。

まとめ

• http_access は上から順に評価され、最初に一致した行で決まる。許可ルールは既定の deny all より上に書く。
• 接続元は必要な範囲だけに絞り、オープンプロキシにしない。ファイアウォールでも 3128 番を制限する。
• HTTPS は CONNECT で中継されるため、宛先のホスト名による制限はできるが、パスによる制限やキャッシュはできない。
• Basic 認証は通信が保護された環境で使い、パスワードファイルの権限を絞る。
• 変更後は squid -k parse で構文を確認し、curl -x と access.log の結果コードで動作を確かめる。
• WordPress からは WP_PROXY_HOST などの定数で、コアの HTTP API の通信を Squid 経由にできる。

• nginxでリバースプロキシを設定する方法
• ufwでファイアウォールを設定する方法