Squidとは？プロキシサーバーの構築手順とsquid.confの書き方【Squid 7.7対応】

Squid（スクイッド）は、社内から外部へ出ていくHTTP・HTTPS通信を中継するオープンソースのプロキシサーバーです。上流の現行安定版は2026年8月24日公開の7.7で、待ち受けの既定ポートは3128番です。この記事では、Debian testingのコンテナでSquid 7.7を実際に動かし、許可リスト方式のsquid.conf、設定検査の終了コード、access.logの読み方、HTTPSを復号せずに宛先で振り分ける設定までを、得られた出力つきで解説します。7系で削除されたsquidclientの代わりになるコマンドも載せています。

まとめ：Squidで構築する前に決めることと押さえる要点

• Squidはフォワードプロキシとして使うのが本筋です。公開サイトの前段（リバースプロキシ）ならnginxやHAProxyを選びます
• 入れる版はディストリビューションで決まります。2026年10月時点でDebian stableは6.13、Ubuntu 24.04は6.14、Ubuntu 26.04は7.2で、上流がサポートするのは最新の7.7だけです
• squid.confの http_access は上から評価され、最初に一致した行で確定します。許可は http_access deny all より前に書きます
• squid -k parse は綴りの誤りを終了コード1で止めますが、行の順番の誤りは検出しません。反映後にcurlとaccess.logで確かめます
• HTTPSは復号しなくても、peekとspliceでSNI（接続先ホスト名）による許可リストが組めます。ただしDebian・Ubuntuの標準の squid パッケージはGnuTLS版でssl-bumpを使えないため、squid-openssl を入れます
• 7系ではsquidclientとcachemgr.cgiが無くなりました。状態は curl http://127.0.0.1:3128/squid-internal-mgr/info で取得します

Squidとは：社内から外部への通信を中継するOSSのプロキシ

中継の流れとSquidが担う3つの機能

Squidは、クライアントから受け取ったリクエストを自分の名前で送り直し、返ってきた応答をクライアントへ戻します。外部のWebサーバーから見える接続元はSquidだけになります。この付け替えを1か所で行うので、宛先の制御・通信ログの記録・応答のキャッシュを同じサーバーでまとめて実施できます。名前は英語の「イカ」で、ライセンスはGNU GPLバージョン2以降です（SquidのREADME）。

プロキシという役割そのものの種類や、VPNとの使い分けはプロキシとVPNの違いを安全性で比較で整理しています。この記事では実装ソフトとしてのSquidに絞ります。サーバー側に置く中継との違いはリバースプロキシの仕組みと導入判断が詳しく、Squidも accel 指定でリバースプロキシになれますが、実務で選ばれるのはほぼフォワード用途です。

既定ポート3128の意味と番号を変えるときの注意

3128はSquidが既定で待ち受けるTCPポートです。パッケージに入っている squid.conf にも http_port 3128 の1行があり、Squidの既定値として広く知られた番号です。社内の別サーバーで3128番が開いていれば、まずSquidかその互換のプロキシを疑ってよいでしょう。

番号は http_port の値で変えられます。ただ、ブラウザやOSのプロキシ設定、コンテナや CI の HTTP_PROXY 環境変数など参照する側が多く、変更すると設定漏れの捜索に手間がかかります。同じサーバーで別のプロキシが3128番を使っているといった事情でもない限り、3128のまま運用するほうが無難です。

現行版7.7と主要ディストリビューションで入る版

Squid公式の配布ページが案内する安定版は7.7（2026年8月24日公開）で、開発チームは最新の安定版しかサポートしないと明記しています。一方、手元のサーバーに入る版はディストリビューション次第です。2026年10月21日に各公式イメージへパッケージを入れて確認した結果は次のとおりでした。

LTSのディストリビューションでは6系や5系が現役で、上流の7系との間に機能差があります。6系で動いていた設定が7系の検証環境で落ちる、という形で差が表に出るため、手順書の先頭には対象の版を書いておきます。ディストリビューションの版はセキュリティ修正をバックポートしている場合があるので、脆弱性への対応状況は各ディストリビューションの告知で確認してください。

Squidでプロキシサーバーを構築する手順（Debian・Ubuntu）

インストールと既定のsquid.confの確認

Debian・Ubuntuではパッケージ管理から入れます。入った版を最初に控えておきます。

sudo apt update
sudo apt install squid
squid -v | head -1
# Squid Cache: Version 7.7（Debian testingの場合）

設定ファイルは /etc/squid/squid.conf です。7.7の既定ファイルは9,361行ありますが、大半はコメントで、有効な行は数十行にすぎません。アクセス制御の部分だけ抜き出すと次のようになっていました。

$ grep -n '^http_access\|^include\|^http_port' /etc/squid/squid.conf
1610:http_access deny !Safe_ports
1613:http_access deny CONNECT !SSL_ports
1616:http_access allow localhost manager
1617:http_access deny manager
1622:http_access allow localhost
1630:http_access deny to_localhost
1634:http_access deny to_linklocal
1639:include /etc/squid/conf.d/*.conf
1646:http_access deny all
2173:http_port 3128

既定で許可されているのはSquid自身（localhost）からの通信だけです。社内のクライアントを通すには、1639行目の include で読まれる /etc/squid/conf.d/ に許可の行を置くか、deny all より前に許可を書き足します。Debian系はパッケージ側の上書きを conf.d/debian.conf に分けているので、自分の設定も conf.d に別ファイルで置くと、パッケージ更新時の差分確認が楽になります。

許可リスト方式のsquid.confの例

社内ネットワークから、許可したドメインにだけ出られる最小構成です。この設定でSquid 7.7を起動して動作を確かめました。

http_port 3128

acl localnet src 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.1
acl SSL_ports port 443
acl Safe_ports port 80 443 1025-65535
acl CONNECT method CONNECT
acl allowed_sites dstdomain .example.com .debian.org

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet allowed_sites
http_access deny all

cache_mem 64 MB
cache_dir ufs /var/spool/squid 100 16 256
coredump_dir /var/spool/squid

localnet の末尾の 127.0.0.1 は、Squidのサーバー上でcurlを実行して確かめるための指定で、本番では外して構いません。dstdomain の値の先頭にドットを付けると、そのドメインとサブドメインの両方に一致します。acl の行は条件に名前を付けるだけで、許可も拒否もしません。判定するのは http_access の行です。

許可リストでつまずきやすいのは、許可したはずのサービスが別ドメインのCDNから部品を読み込んでいる場合と、OSやパッケージの更新先が複数ドメインに分かれている場合です。後者は失敗しても利用者から苦情が来ず、更新が止まったまま脆弱性が残ります。運用を始める前に、更新系の通信先を先に洗い出してください。

squid -k parseによる構文検査とreconfigureによる設定反映

設定を変えたら、反映の前に squid -k parse で構文を検査します。わざと http_access を http_acess と綴り間違えた設定では、次のように止まり、終了コードは1でした。

$ squid -k parse -f /tmp/bad.conf
ERROR: unrecognized directive near 'http_acess'
FATAL: configuration failure: Found 1 unrecognized directive(s)
$ echo $?
1

検査が通ったら squid -k reconfigure でプロセスを止めずに再読み込みします。手元では終了コード0で戻り、既存の接続は切れませんでした。http_port の番号も reconfigure で切り替わり、3128から3129へ変えた直後に3129番で応答が返り、3128番は閉じました。再起動が必要な項目は設定ごとに異なるため、反映後は cache.log の「Accepting HTTP Socket connections」の行で待ち受け先を確かめます。再起動する場合にも注意点があり、squid -k shutdown から停止完了までは約33秒かかりました。既定の shutdown_lifetime（30秒）だけ既存の接続の終了を待つためで、停止直後に起動し直すと「Squid is already running」で失敗します。

curlとaccess.logによる許可・拒否の動作確認

疎通確認はブラウザでなくcurlから始めます。ブラウザは自動設定スクリプトやOSの設定を参照するので、どの経路で接続したのかが曖昧になるからです。上の設定で4通りのリクエストを送りました。

$ curl -s -o /dev/null -w '%{http_code}\n' -x http://127.0.0.1:3128 https://www.example.com/
200
$ curl -s -o /dev/null -w '%{http_code}\n' -x http://127.0.0.1:3128 http://www.example.com/
200
$ curl -s -o /dev/null -w '%{http_code}\n' -x http://127.0.0.1:3128 http://www.google.com/
403
$ curl -s -o /dev/null -w '%{http_code}\n' -x http://127.0.0.1:3128 https://www.google.com/
000

許可外のHTTPSが403でなく000になるのは、Squidが CONNECT（トンネルを張る要求）の段階で拒否し、curlがTLSに入る前に「CONNECT tunnel failed, response 403」で終わるためです。curlの終了コードの読み方はcurlエラーコード一覧にまとめています。

このときの /var/log/squid/access.log です。

... 173 127.0.0.1 TCP_TUNNEL/200 6525 CONNECT www.example.com:443 - HIER_DIRECT/172.66.147.243 -
...  54 127.0.0.1 TCP_MISS/200 1015 GET http://www.example.com/ - HIER_DIRECT/172.66.147.243 text/html
...   0 127.0.0.1 TCP_DENIED/403 3393 GET http://www.google.com/ - HIER_NONE/- text/html
...   0 127.0.0.1 TCP_DENIED/403 3397 CONNECT www.google.com:443 - HIER_NONE/- text/html
...   0 127.0.0.1 TCP_MEM_HIT/200 1016 GET http://www.example.com/ - HIER_NONE/- text/html

2列目が処理時間（ミリ秒）、4列目が結果コードです。TCP_DENIED/403 は http_access で拒否された印なので、設定側を見直します。TCP_TUNNEL/200 は復号せずに中継したHTTPS、TCP_MISS は外部から取得した応答、TCP_MEM_HIT はメモリのキャッシュから返した応答です。リクエストを送っても行が増えない場合は、未到達のほか、ログ出力条件や書き込みの遅延も確認します。その場合はクライアントのプロキシ設定かファイアウォールを疑います。起動失敗や証明書の読み込みエラーは /var/log/squid/cache.log 側に出ます。

squid.confの評価順序で起きる事故と7系の重複ACL警告

deny all以降の許可ルールが評価されない理由

http_access は上から順に評価され、最初に一致した行で結論が確定します。次の設定は、許可の行を末尾に書き足した典型的な失敗です。

http_port 3128
acl localnet src 127.0.0.1 10.0.0.0/8
acl allowed_sites dstdomain .example.com
http_access deny all
http_access allow localnet allowed_sites

この設定で squid -k parse を実行すると、警告もエラーも出ず終了コードは0でした。ところが許可したはずの www.example.com へのリクエストは TCP_DENIED/403 で拒否されます。parse は文法を検査するだけで、行の順番が意図どおりかまでは見ません。設定を変えたら、許可するはずの宛先と拒否するはずの宛先を1つずつcurlで叩くところまでを手順に含めてください。逆に、広い許可を先頭近くに置くと、後ろに書いた細かい拒否が効かなくなります。

ドメイン・IP範囲の重複に対するACL警告

7系では、acl の値が重なっていると検出して片方を捨てるようになりました（Squid 7のリリースノートの src・dst・dstdomain・ssl::server_name などの項）。実際に重なる値を書いて parse すると、次の警告が出ます。

WARNING: Ignoring www.example.com because it is already covered by .example.com
WARNING: Ignoring 10.1.0.0/16 because it is already covered by 10.0.0.0/8

6系から持ち込んだ許可リストを7系で parse すると、この警告が大量に並ぶことがあります。警告が出た値は、どちらかを消して整理します。

Safe_portsによる管理情報アクセスの拒否条件

検証の途中で、Safe_ports を 80 443 だけに絞った設定では、管理情報の取得が403になりました。管理情報のURLは http://ホスト:3128/squid-internal-mgr/ の形で、ポート3128が Safe_ports に入っていないため、先頭の http_access deny !Safe_ports で拒否されたのです。既定の squid.conf は Safe_ports に 1025-65535 を含めています。ポートを絞るなら、管理用の許可（allow localhost manager）を deny !Safe_ports より前に置くか、3128を Safe_ports に含めます。

HTTPSを復号せずSNIで振り分けるpeekとsplice

peek・stare・splice・bumpの違い

HTTPSの通信に対して何をするかは ssl_bump で決めます。Squidは TLS の握手を段階（SslBump1〜3）に分けて扱い、各段階で次の動作を選びます（ssl_bumpの公式リファレンス）。

SslBump2では、ClientHelloにSNIが含まれていれば接続先のホスト名を取得できます。SNIがない場合、ssl::server_nameはCONNECTの要求先を代用するため、常にSNIだけで判定する設定ではありません。宛先の許可リストだけが目的なら、peek で SNI を見て、許可した宛先は splice、それ以外は terminate とすれば、復号もクライアントへの独自CA配布も要りません。

SNIで許可リストを組む設定と実測結果

ここで1つ落とし穴があります。Debian・Ubuntuの squid パッケージは GnuTLS 版で、ssl-bump を指定すると起動前に止まります。

$ squid -v | tr ' ' '\n' | grep -E 'gnutls|ssl-crtd'
'--with-gnutls'
'--disable-ssl-crtd'
$ squid -k parse -f /tmp/b.conf
FATAL: Unknown http_port option 'ssl-bump'.

ssl_bump を使うときは OpenSSL 版の squid-openssl パッケージ（Debian testingでは7.7-1）に入れ替えます。そのうえで、http_port が読む CA の証明書と秘密鍵を1つのPEMファイル（ca.pem）にまとめ、証明書キャッシュを作ってから、SNIで振り分ける設定を書きました。splice だけの運用でも ssl-bump を指定した http_port には CA が要ります。

sudo apt install squid-openssl
sudo mkdir -p /etc/squid/ssl && cd /etc/squid/ssl
sudo openssl req -new -newkey rsa:2048 -sha256 -days 365 -nodes -x509 -subj /CN=proxy-ca -keyout ca.key -out ca.crt
cat ca.crt ca.key | sudo tee ca.pem >/dev/null && sudo chown -R proxy:proxy /etc/squid/ssl
sudo mkdir -p /var/lib/squid && sudo chown proxy:proxy /var/lib/squid
sudo -u proxy /usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 4MB

# squid.conf（宛先は http_access でなく ssl_bump で絞る）
http_port 3128 ssl-bump tls-cert=/etc/squid/ssl/ca.pem generate-host-certificates=on
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 4MB
acl step1 at_step SslBump1
acl allowed_sni ssl::server_name .example.com
ssl_bump peek step1
ssl_bump splice allowed_sni
ssl_bump terminate all

acl localnet src 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.1
acl SSL_ports port 443
acl Safe_ports port 80 443 1025-65535
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access deny all

/var/lib/squid が無い状態で security_file_certgen を実行すると「Cannot create /var/lib/squid/ssl_db」で失敗するため、ディレクトリを先に作ってproxyユーザーの所有にしています。

結果は、www.example.com が200、www.google.com は curl が「TLS connect error（エラー35）」で失敗しました。access.log の記録は次のとおりです。

... 2 127.0.0.1 NONE_NONE/200 0 CONNECT www.example.com:443 - HIER_NONE/- -
... 94 127.0.0.1 TCP_TUNNEL/200 6463 CONNECT www.example.com:443 - HIER_DIRECT/172.66.147.243 -
... 2 127.0.0.1 NONE_NONE/200 0 CONNECT www.google.com:443 - HIER_NONE/- -

terminate で切った接続は TCP_DENIED ではなく NONE_NONE/200 として残ります。access.log を TCP_DENIED で集計している監視は、SNIでの拒否を数えられません。拒否件数を取りたいなら、logformat に ssl::bump_mode（%ssl::bump_mode）を足し、値が terminate の行を数えます。

復号（bump）を選ぶ条件と避ける条件

bump を選ぶ理由が立つのは、URLのパスや送信内容まで監査する要件がある場合だけです。bump では Squid が自前のCAでサーバー証明書を作り直すため、全端末にそのCAを信頼させる配布と、CAの秘密鍵の保管が必要になります。CAの鍵が漏れれば社内の全HTTPS通信になりすませるので、鍵の扱いはDMZの設計と同じ水準で区画を分けて考えます。

避けるべきなのは、証明書ピンニングを実装したアプリやクライアント証明書認証を使うサービスが混ざる環境で、一律に bump する設定です。これらは復号すると通信が壊れます。業務システムを含む環境では、まず splice の例外リストを用意し、bump の範囲を少しずつ広げる順で進めます。

cache_memとcache_dirとrefresh_patternによるキャッシュ設定

cache_mem はキャッシュなどのオブジェクトデータに使うメモリ量の目安で、Squidプロセス全体のメモリ上限ではありません。cache_dir はディスクに置くキャッシュの指定です。例の cache_dir ufs /var/spool/squid 100 16 256 は、ufs 形式・100MB・第1階層16個・第2階層256個のディレクトリという意味です。cache_dir を新しく書いたら、起動前に squid -z でディレクトリを作ります。実行すると /var/spool/squid の下に 00 から 0F までの16個のディレクトリができました。

この記事のようにHTTPSを復号せず中継する構成では、HTTPSの応答内容はキャッシュできません。ssl_bumpで復号する構成では、HTTPのキャッシュ条件を満たす応答をキャッシュできる場合があります。上の実測でも、2回目の http://www.example.com/ は TCP_MEM_HIT になりましたが、HTTPSは TCP_TUNNEL で素通しされ、キャッシュの対象になりません。通信の大半がHTTPSの今、キャッシュ目的でSquidを入れる理由は薄れています。

例外がパッケージの配布です。Debian testing の squid 7.7 は /etc/squid/conf.d/debian.conf に、.deb や tar.xz を長く新鮮とみなし（最大値2592000分）、Release や Packages の一覧は常に古いものとして再検証させる refresh_pattern を同梱していました。パッケージ本体はファイル名に版が入り中身が変わらないため、長く保持しても問題が起きにくいという考え方です。aptのミラーがHTTPで配っている環境なら、同じパッケージを多数のサーバーへ入れるときに帯域を節約できます。refresh_pattern も http_access と同じく最初に一致した行が使われるので、具体的なパターンを汎用の refresh_pattern . より前に置きます。

Squid 7で変わった運用：squidclientの代わりとセキュリティ修正

squidclientに代わるcurlでの管理情報取得

7系では squidclient コマンドと、ブラウザから統計を見る cachemgr.cgi が削除されました。管理情報を呼ぶ cache_object: のURI形式も廃止され、通常のHTTPのURLで取得する方式に統一されています。リリースノートが代わりに示しているのは curl です。7.7で実行した結果を載せます。

$ curl -s http://127.0.0.1:3128/squid-internal-mgr/info | head -3
Squid Object Cache: Version 7.7
...
	Number of clients accessing cache:	1

$ curl -s http://127.0.0.1:3128/squid-internal-mgr/menu | head -3
 index                 	Cache Manager Interface         	public
 menu                  	Cache Manager Menu              	public
 offline_toggle        	Toggle offline_mode setting     	hidden

squidclient mgr:info は squid-internal-mgr/info、mgr:5min は squid-internal-mgr/5min に読み替えます。cachemgr_passwd でパスワードを掛けている項目は curl -u ユーザー名:パスワード で渡します。既定の設定で管理情報を読めるのは localhost からだけで、同じURLを別の端末から開くと403になります。

影響が出るのはSquid本体より監視側です。squidclient の出力を解析して接続数やヒット率を取っていたスクリプトは、7系へ上げた瞬間にコマンドが見つからず値を返さなくなります。Debian testing と Ubuntu 26.04 では squidclient パッケージ自体が消えていました。更新計画には監視の取得方法の書き換えを含めてください。

ESI・Ident・purgeの削除と挙動が変わった設定

削除されたのは管理ツールだけではありません。Edge Side Includes（esi_parser）、Identプロトコル（ident・ident_regex の acl と ident_lookup_access）、キャッシュを個別に消す purge ツールも7系で外れました。Ident の設定が残っていると7系では起動できないため、6系からの移行で最初に引っかかりやすい項目です。purge の代わりは、PURGE メソッドを localhost にだけ許可して curl -XPURGE --proxy http://127.0.0.1:3128 URL で消す方法がリリースノートで案内されています。

挙動の変更もあります。collapsed_forwarding で束ねたリクエストへの応答は再検証せず新鮮なものとして扱うようになり、quick_abort_pct は応答の大きさに関係なく適用されるようになりました。7.6では、HTTP/1.1 で Transfer-Encoding: identity を使うリクエストを拒否する変更も入っています。

2026年のセキュリティ勧告と更新を急ぐべき構成

2026年に公開された勧告は8件で、9月12日には3件がまとめて出ました（Squidのセキュリティ勧告一覧）。

重大度はSQUID-2026:1がCritical、SQUID-2026:2とSQUID-2026:6がHighです。SQUID-2026:7 は cache_peer へ利用者のBasic認証情報を渡している構成だけが対象で、勧告には該当の有無を確かめるコマンドが載っています。

squid -k parse 2>&1 | grep -E "cache_peer.*login=(\*:|PASS)" || echo "not vulnerable"

多段構成で親プロキシへ認証を引き継いでいる環境は、このコマンドで行が出たら7.7へ上げるか、ディストリビューションの修正版を当てる優先度を上げてください。

WindowsでSquidを使う方法

Squid開発チームはビルド済みのバイナリを配っておらず、Windows向けは第三者の提供に頼る形です。公式wikiのWindowsのページが案内しているのは Diladele 社による Squid 4 の64ビットMSIで、上流が唯一サポートする7系とは3世代離れています。

業務で使うなら、WindowsのホストにSquidを直接入れるより、Linuxの仮想マシンやコンテナで7系を動かし、Windows側はプロキシの設定先としてそのアドレスと3128番を指定する構成をおすすめします。この記事の検証も、macOS上のコンテナで debian:testing を起動して行いました。

Squidを採用する条件と他の手段に任せる場面

Squidが向く条件と自前運用に必要な体制

Squidを選ぶ理由が立つのは、宛先ドメイン単位の許可リストを自社の裁量で維持したい、誰がどこへ接続したかのログを自社の保管ルールで持ちたい、という要件がある場合です。そのうえで、squid.confを読み書きできる担当者が社内か委託先に常にいることが前提になります。

担当者を置けないなら採用は見送ります。評価順序で意味が変わる設定ファイルは、担当者が替わると放置されやすく、古い許可リストとサポートの切れた版だけが残ります。2026年だけで8件の勧告が出ている以上、版を追えない体制での運用は危険です。統制のために置いた仕組みが管理されずに残る失敗は、踏み台サーバーの採用判断でも同じ形で起きます。

NATゲートウェイやnginx・HAProxyに任せる場面

外部へ出る経路が欲しいだけなら、クラウドのNATゲートウェイで足ります。宛先の制限もマネージドなファイアウォールのドメインフィルタで実現でき、ソフトウェアの版の追随は事業者側に任せられます。ただしAWS Network Firewallでも、使うアベイラビリティーゾーンごとのエンドポイント配置と経路の設計は利用者側で行います。オンプレミスのSquidを仮想マシンごとクラウドへ移すと、1台が落ちれば外向き通信が全停止する単一障害点も一緒に運ぶことになります。どこまでをクラウドの機能へ寄せるかの線引きを含めて相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援で対応しています。

公開サイトの前段を新規構築し、主な要件が負荷分散やTLS終端であれば、nginxやHAProxyを優先します。その領域ではHAProxyやnginxが標準で、設定例も運用の知見も厚く蓄積されています。

よくある質問

Squidは無料で使えますか？

GNU GPLバージョン2以降で公開されているオープンソースのため、ライセンス費用はかかりません。費用はサーバー代と運用の工数です。許可リストの更新と版の追随は自社の負担になるので、商用のプロキシ製品やマネージドサービスとは、担当者の工数を含めた総額で比べます。

Squidの読み方と名前の由来は何ですか？

「スクイッド」と読み、英語でイカを意味します。HTTPのほか、HTTPSのトンネル（CONNECT）やFTPも中継できるプロキシです。

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

Debian・Ubuntu・RHEL系のパッケージでは /etc/squid/squid.conf です。Debian・Ubuntuでは /etc/squid/conf.d/ の下の .conf も include で読まれます。ソースからビルドした場合は指定した prefix の下になるため、squid -k parse の出力の先頭に出る「Processing Configuration File」の行で実際のパスを確かめるのが確実です。

SquidでHTTPSの通信内容をログに残せますか？

squid-openssl などOpenSSL版のSquidで ssl_bump の bump を使い復号すれば、URLのパスまで記録できます。復号しない場合に残るのは CONNECT の行で、接続先のホスト名とポート、転送量までです。監査の要件が接続先の把握までなら、復号せずに peek と splice で足ります。

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

得意な向きが逆です。Squidは社内から外部への通信を中継するフォワードプロキシ、nginxやHAProxyは外部から自社サーバーへの通信を受けるリバースプロキシやロードバランサーが主な用途です。

関連記事

• プロキシとVPNの違いを安全性で比較｜仕組み・種類・設定と企業での選び方
• リバースプロキシとは？仕組み・フォワードプロキシとの違いと導入判断を実装目線で解説
• HAProxyとは：L4/L7ロードバランサーの仕組みと設定・nginxとの違いを実装目線で解説
• curlエラーコード一覧｜公式87件の意味と6・7・28・35・60の対処
• 踏み台サーバーとは？仕組み・SSH多段接続・AWS構築と採用判断【2026年版】