Squidとは？プロキシサーバー構築の仕組み・squid.confの設定と採用判断を実装者向けに解説

Squidは、社内から外部へ出ていくHTTP・HTTPS通信を中継するフォワードプロキシとして最も長く使われているオープンソースのサーバーソフトウェアです。現行の安定版は7.6系で、2026年6月に公開されました。この記事では、Squidが担う中継経路と既定ポート3128の意味、squid.confにおけるaclとhttp_accessの評価順序、cache_memとcache_dirによるキャッシュ設計、SSL Bumpで復号するかどうかの判断、そしてSquid 7で削除された管理ツールが既存構成に与える影響までを、実際にプロキシを構築・運用する立場から整理しました。

まとめ：Squidを採用する条件と代替手段との使い分けの結論

Squidが向くのは、社外へ出る通信を1か所に集約し、宛先ドメイン単位の許可リストと通信ログを自前で持ちたい場合です。ACLの粒度と監査ログの自由度では、クラウドの標準機能より細かく制御できます。逆に、単に外部へ出る経路を作りたいだけならクラウド側のNATゲートウェイやマネージドなファイアウォールで足り、Squidを立てる必然性はありません。

設計で最初に決めるべきは、HTTPSを復号するかどうかです。復号しない構成ならSNIを見た宛先制御までで、運用負荷は小さく収まります。復号する構成では独自CAの配布と鍵管理が全端末に波及するため、監査要件がそれを求めている場合に限って選ぶべき選択肢です。

もう1点、7系へ上げる際にはsquidclientとcachemgr.cgiが削除されている前提で、監視スクリプトを含む運用手順の書き換えが要ります。

Squidの定義とフォワードプロキシとしての中継経路と既定ポートの整理

Squidが中継するリクエストの流れと既定ポート3128の役割

Squidは、クライアントから受け取ったHTTPリクエストを自分が代理で送り直し、返ってきた応答をクライアントへ返します。クライアントから見た通信相手はSquidであり、外部のWebサーバーから見た通信相手もSquidです。両端のどちらからも実際の相手が直接は見えません。この二重の付け替えが、宛先制御・ログ取得・キャッシュという3つの機能が同じ場所で成立する理由です。

待ち受けは既定で3128番ポートです。http_port ディレクティブで変更できますが、ブラウザやOSのプロキシ設定、コンテナのHTTP_PROXY環境変数など参照側が多く、番号を変えると設定漏れの捜索コストが跳ね上がります。特段の理由がなければ3128のまま運用するほうが安全でしょう。

プロキシサーバーという概念とSquidという実装ソフトの区別

プロキシは通信を中継する役割の総称で、Squidはその役割を実装した製品の1つにすぎません。役割としての定義や種類の全体像はプロキシの仕組みと種類、VPNとの違いで整理しているため、この記事では実装ソフトとしてのSquidに絞ります。

同じ「プロキシ」でも、クライアント側に置くフォワードプロキシとサーバー側に置くリバースプロキシでは、守る対象も設定の書き方も別物です。Squidは両方の動作モードを持ちますが、実運用でSquidが選ばれるのは圧倒的にフォワード側です。

7.6系という現行バージョンとディストリビューション提供版のずれ

公式が現行として案内しているのは7.6系で、2026年6月の公開です。ところが手元のサーバーに入るバージョンは、たいていディストリビューションの提供版に引きずられます。Debianの場合、2026年7月29日時点でstableのパッケージは6.13、testingとunstableが7.6という状態でした。

この差は無視できません。7系で削除された機能を使った設定は6系では動くため、「本番は動いているのに検証環境で落ちる」という形で表面化します。手順書を書くときは、対象がどの系列かを先頭に明記しておくと後任が迷いません。

Squidが取り得る4つの動作モードと復号方針の選び分け基準

フォワードとインターセプトとアクセラレータの3形態の使い分け

フォワードは、クライアント側にプロキシ設定を入れて明示的にSquidへ送らせる形です。インターセプトは、ルーターやファイアウォールで宛先80番・443番の通信をSquid側へ折り返し、クライアント設定なしで中継させる形になります。アクセラレータは accel オプションを付けてリバースプロキシとして振る舞わせる形です。

設定できない端末が混ざる環境ではインターセプトが選ばれますが、経路制御をネットワーク機器側に依存するため障害切り分けが難しくなります。端末に設定を配れるならフォワードを選んでおくのが定石です。

cache_peerで組む多段プロキシと上位プロキシへの中継設計

4つ目が多段構成です。cache_peer で上位のプロキシを登録すると、Squidは自分で外部へ出る代わりに上位へ中継します。拠点ごとにSquidを置き、本社の親プロキシへ集約する構成がこれにあたります。

登録時の種別には親子関係を示す parent と、同格でキャッシュを融通し合う sibling があります。siblingどうしはICPやHTCPで相手のキャッシュ有無を問い合わせてから取りに行く仕組みです。ただし拠点間の遅延が大きい環境では問い合わせ自体が待ち時間になるため、拠点数が少ないうちは素直にparentだけで組むほうが速く済みます。

SSL Bumpのpeek・splice・bumpと復号を選ばない条件

HTTPS通信の中身をSquidで検査するには ssl_bump による復号が必要です。動作は段階的で、まずpeekでTLSハンドシェイクの情報だけを覗き、そのまま素通しするならsplice、復号して中身を見るならbumpを選びます。復号を選んだ場合、Squidが自前のCA証明書でサーバー証明書を作り直すため、全クライアントにそのCAを信頼させる必要が生じます。

復号を選ばない判断が妥当なのは、宛先ドメイン単位の制御で監査要件が満たせる場合です。peekの段階でもSNIから接続先ホスト名は取れるため、許可リスト運用は復号なしで成立します。証明書ピンニングを実装したアプリやクライアント証明書認証を使うサービスは復号すると通信が壊れるため、業務システムを含む環境ではまずspliceの例外リストを用意してから範囲を広げる進め方が現実的でしょう。

squid.confのアクセス制御設計と評価順序で起きる典型的な事故

aclとhttp_accessの評価順序と最初に一致した行で確定する挙動

acl は条件に名前を付けるだけの定義で、それ自体は許可も拒否もしません。判定するのは http_access の行です。上から順に評価され、最初に一致した行で結論が確定し、以降の行は読まれません。

事故はここで起きます。既定のsquid.confには最終行に全拒否のルールが入っており、独自の許可ルールをその後ろに書き足すと永久に届きません。逆に、広い許可ルールを先頭付近に置くと、後段で書いた細かい拒否ルールが無効化されます。設定を足すときは、行を追加する位置そのものが仕様である、と考えてください。なお7系では、重なり合うIP範囲やドメイン、ステータスコードをaclが検出してマージするようになりました。同じ範囲を二重に書いていた設定は挙動が変わる可能性があります。

送信先ドメイン制御と許可リスト運用でつまずく具体的な条件と判断基準

宛先で絞る場合は dstdomain を使い、先頭にドットを付けたドメインでサブドメインまで含めます。ここで頻出する落とし穴が3つあります。

• CDN配信のドメインが実体と異なり、許可したはずのサービスが読み込みに失敗する
• OSやパッケージ管理の更新先が複数ドメインに分かれており、1つ許可しただけでは通らない
• SaaSが接続先ドメインを予告なく増やし、後日突然エラーになる

優先度をつけるなら、まず更新系の通信先を洗い出すところから始めます。業務アプリの不通は利用者から即座に報告が上がりますが、パッケージ更新の失敗は静かに滞留し、脆弱性が残り続ける形で後から効いてくるためです。

ユーザー認証を挟む場合のbasic_ncsa_authの構成と限界

誰がどこへ接続したかを記録するには、送信元IPではなくユーザー単位の認証を挟みます。Squid同梱の basic_ncsa_auth ヘルパーを auth_param で呼び出し、パスワードファイルを参照させる構成が最も手数の少ない方法です。認証済みかどうかは proxy_auth のaclで判定します。

限界も明確です。Basic認証は資格情報を毎回送るため、経路が暗号化されていない区間があると平文で流れます。またパスワードファイルの管理が社内のディレクトリサービスと二重化するため、利用者が数十人を超えるとKerberosやLDAP連携のヘルパーへ移す判断が必要になるでしょう。

cache_memとcache_dirで決まるキャッシュ設計と効果が出る条件

Squidの名前はキャッシュ機能に由来しますが、いまのトラフィックでキャッシュがどこまで効くかは冷静に見積もる必要があります。

cache_memとcache_dirの役割分担とディスク初期化の手順

cache_mem はメモリ上に保持する容量、cache_dir はディスクへ書き出す領域の指定です。cache_dirの行では格納方式に続けて、ディレクトリのパス、容量、第1階層のディレクトリ数、第2階層のディレクトリ数を順に並べます。16と256という値が例としてよく出てきますが、これは1階層目16個、2階層目256個という意味であり、容量に対して極端に少ないと1ディレクトリあたりのファイル数が膨らんで性能が落ちます。

cache_dirを新規に定義したら、Squidを起動する前に squid -z でディレクトリ構造を作成します。この手順を飛ばすと起動時にキャッシュ領域を開けず、cache.logにエラーを残して立ち上がりません。既存構成に領域を追加した場合も同じです。

refresh_patternの指定とHTTPS化でキャッシュ効果が落ちた理由

refresh_pattern は、応答にキャッシュ制御ヘッダーが無い場合にどれだけ保持するかを正規表現ごとに決める指定です。最小保持時間、鮮度の割合、最大保持時間の3つを並べます。順番に評価され、最初に一致したパターンが使われる点はhttp_accessと同じ考え方です。

ただし、いまのWebでこの設定が効く範囲は狭くなりました。通信の大半がHTTPSであり、復号しない構成ではSquidは暗号化されたバイト列を素通しするだけでキャッシュできないからです。動的生成のコンテンツが増えたことも重なり、キャッシュヒット率を目的にSquidを導入する動機はほぼ失われました。

インストールから疎通確認までの最小構築手順と設定反映の安全策

Squidのパッケージ導入からクライアント疎通確認までの手順

最小構成であれば、次の5工程で外部への中継が動きます。

1. ディストリビューションのパッケージ管理でsquidを導入し、入ったバージョン系列を控える
2. squid.confで社内ネットワークのアドレス範囲をaclとして定義する
3. そのaclを許可するhttp_accessの行を、既定の全拒否ルールより前に挿入する
4. cache_dirを定義した場合は squid -z でキャッシュ領域を初期化する
5. サービスを起動し、クライアントからプロキシ指定付きで外部URLを取得して応答を確認する

疎通確認はブラウザではなくコマンドラインから始めるほうが早く切り分けられます。ブラウザは自動設定スクリプトやシステム設定を参照するため、どこを見て接続したのかが曖昧になりやすいためです。

squid -k parseとsquid -k reconfigureによる安全な反映

設定を変更したら、反映の前に squid -k parse で構文を検証しておきましょう。誤りがあれば行番号付きで指摘されるため、サービスを落としてから気付く事態を避けられます。検証が通ったら squid -k reconfigure で再読み込みします。プロセスを再起動しないため、既存の接続を切らずに設定を差し替えられる点が利点です。

再起動が必要になるのは、待ち受けポートやSMPのワーカー数など、起動時に確定するパラメータを変えた場合に限られます。日常のACL追加はreconfigureで完結すると考えて構いません。ただしreconfigureは一時的に応答が滞ることがあるため、業務時間帯の大量変更はまとめて1回にすると影響を抑えられます。

Squid 7で廃止された管理ツールと既存squid.confへの影響範囲

ここが7系へ上げるときに最も見落とされる部分です。7系は新しいディレクティブを1つも追加していない一方で、長年使われてきた周辺ツールをまとめて削除しました。

squidclientとcachemgr.cgiの廃止とHTTP経由の管理への移行

Squidの状態確認に使われてきた squidclient コマンドと、ブラウザから統計を見る cachemgr.cgi は、7系で削除されました。あわせて、Cache Managerを呼び出す cache_object: というURIスキームも廃止され、通常のHTTPまたはHTTPSのURLで管理情報を取得する方式へ統一されています。

影響を受けるのは、Squidそのものより監視側です。squidclientの出力をパースして接続数やヒット率を取得しているスクリプトは、バージョンアップと同時に無言で値を返さなくなります。7系への更新計画には、監視項目の取得方法を書き換える工数を必ず含めてください。

ESIとIdentとsquidpurgeの削除が既存構成に及ぼす影響

削除されたのは管理ツールだけではありません。ページ断片を組み立てるEdge Side Includes、接続元のユーザー名を問い合わせるIdentプロトコル、キャッシュを個別に破棄する squidpurge も7系で外されました。Identは仕様上なりすましが容易で、認証手段としては以前から推奨されていなかったものです。

そのほか、collapsed_forwarding による集約応答は再検証せずfreshとして扱う挙動に変わり、quick_abort_pct は応答サイズの大小に関わらず適用されるようになりました。7.6系ではHTTP/1.1のTransfer-Encodingにidentityを指定した通信を拒否し、FTPの制御応答にヘッダーサイズ上限を適用する変更も入っています。既存設定をそのまま持ち込む前に、これらの挙動変更に依存した運用がないかを確認しておくと安全です。

access.logとcache.logで追う遅延と拒否の切り分け手順

トラブル対応は2つのログを順に見れば足ります。access.logには1リクエストずつ、結果コードと所要時間、宛先が並びます。TCP_DENIEDが出ていればhttp_accessで拒否されており、設定側の問題です。TCP_MISSで所要時間が長い場合は、上流の応答待ちかDNS解決の遅延を疑います。

cache.logはプロセス側のログで、起動失敗、ヘルパープロセスの枯渇、証明書の読み込みエラーなどが記録されます。切り分けの順番は、まずaccess.logに記録が出ているかどうかです。記録自体が無ければクライアントからSquidに届いておらず、経路やプロキシ設定側を疑うことになります。

Squidを採用する条件と代替手段に切り替えるべき場面の判断基準

Squidが向く3つの条件と自前運用が成立する組織の規模の目安

Squidを選ぶ理由が立つのは、次の3条件が重なる場合です。宛先ドメイン単位の許可リストを自社の裁量で細かく維持したい。誰がどこへ接続したかのログを自社の保管ポリシーで保持したい。そして、設定ファイルを読み書きできる運用担当が社内または委託先に常時いる。

3つ目が満たせないなら採用は見送るべきです。squid.confは評価順序に依存する設定言語であり、担当者が入れ替わったときに「触れないので放置」となりやすい構造をしています。放置されたプロキシは許可リストが古いまま残り、業務の障害要因に変わります。目安として、インフラを見る担当が実質1人しかいない組織では、自前運用の維持は現実的ではありません。踏み台サーバーのように、統制のために置いた仕組みが管理されずに残る失敗と同じ形です。

Squidを選ばないほうがよい場面とクラウド側機能への寄せ方

外部への経路を確保したいだけならSquidは不要です。クラウド上の構成ならNATゲートウェイで足り、宛先の制限もマネージドなファイアウォールのドメインフィルタリングで実現できます。冗長化とスケーリングを自分で設計しなくて済む差は大きく、可用性の要求が高い環境ほどマネージド側が有利です。

もう1つ、公開サイトの前段に置く用途でSquidを選ぶ理由はありません。この領域はHAProxyやnginxが実質的な標準で、設定資産も運用ノウハウも厚く蓄積されています。Squidのアクセラレータモードは動きますが、あえて選ぶ利点は見当たりません。フォワード用途に限定して使う、という線引きが最も無理のない使い分けです。

クラウド移行時にSquidをそのまま持ち込む場合の構成上の注意点

オンプレミスのSquidを仮想マシンごとクラウドへ持ち込む移行は珍しくありません。ただし単純な引っ越しでは、単一障害点をそのまま運び込むことになります。プロキシが落ちれば外向き通信が全停止するため、複数台構成と接続先の振り分け方をセットで設計してください。あわせて、インスタンスタイプによる帯域上限、キャッシュ領域を置くディスクの種類、そしてログの保管先を移行時に決めておく必要があります。

既存のACLをどこまでクラウド側の機能へ寄せ、どこからをSquidに残すかの線引きは、移行後の運用コストを大きく左右します。現行構成の棚卸しから移行後の運用設計までを含めて相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援で対応しています。

よくある質問

Squidの導入検討と運用で繰り返し出てくる質問をまとめました。

Squidは無料で使えますか？

GPLで公開されているオープンソースソフトウェアのため、ライセンス費用はかかりません。費用が発生するのはサーバー費用と運用の人件費です。商用のプロキシ製品と比べると初期費用は下がりますが、許可リストの維持とバージョン追随が自社負担になるため、総コストで見ると担当者の工数次第で逆転します。

Squidの設定ファイルはどこにありますか？

パッケージで導入した場合、squid.confはetc配下のsquidディレクトリに置かれるのが一般的です。同じディレクトリにエラーページのテンプレートや証明書関連のファイルも配置されます。ソースからビルドした場合は指定したprefix配下に変わるため、squid -k parse の出力に表示されるパスで確認するのが確実です。

SquidでHTTPSの中身をログに残せますか？

ssl_bumpでbumpを選び復号すれば、URLパスまで含めて記録できます。復号しない場合に残るのはCONNECTメソッドの記録で、接続先ホスト名とポート、転送量までです。監査要件が接続先の把握までなら復号は不要と判断できます。復号を選ぶ場合は、独自CAの配布と鍵の保管体制を先に用意してください。

SquidとnginxやHAProxyはどう違いますか？

想定している向きが逆です。Squidは社内から外部への通信を中継するフォワード用途、nginxやHAProxyは外部から自社サーバーへの通信を受けるリバース用途が主戦場になります。反対方向の機能も一応持ってはいますが、実務では得意な向きに合わせて選びます。

Squid 7へ上げる際に気を付けることは何ですか？

squidclientとcachemgr.cgiが削除されているため、これらを使う監視や運用手順の書き換えが先に必要です。ESI、Ident、squidpurgeも同時に外されました。加えてaclの重複範囲がマージされる挙動やcollapsed_forwardingの再検証停止など、既存設定の解釈が変わる変更が入っています。検証環境で squid -k parse を通したうえで、実トラフィックを流して確認する段取りを組んでください。

関連記事

• プロキシとは？仕組み・役割と種類、VPNとの違いと設定の意味までわかりやすく解説：Squidが実装している「プロキシ」という役割そのものの全体像を整理しています
• リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説：Squidのフォワード用途と対になる、サーバー側に置く中継の判断材料になります
• HAProxyとは？L4/L7ロードバランサーの仕組みと設定・nginxとの違いを実装目線で解説：公開サイトの前段でSquidの代わりに選ばれる製品の設定と比較を扱っています
• 踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】：外向き・内向きの通信を1か所へ集約する統制の考え方が共通します
• サーバーとは？役割・種類・クライアントとの違いと企業の選び方を解説【2026年版】：プロキシサーバーを含むサーバー全体の分類を俯瞰できます