Squid 経由で接続できないときは、まず Squid の access.log に「そのリクエストが届いているか」と「どの結果コードで終わったか」を確認するのが近道です。届いていなければクライアント側かネットワーク、届いて TCP_DENIED なら Squid のアクセス制御、届いて接続エラーなら Squid から先の経路が原因です。この記事では、ログの読み方を先に説明し、起こりやすい原因の順に確かめ方と直し方を並べます。WebSocket が Squid を通らない場合の考え方も最後に扱います。設定を変える前には squid.conf を複製しておいてください。
まず access.log を見る
多くのディストリビューションでは、ログは /var/log/squid/access.log、設定は /etc/squid/squid.conf にあります。クライアントから接続を試しながら、ログを流して見ます。
sudo tail -f /var/log/squid/access.log既定の書式では、1行に時刻、処理時間、クライアント IP、結果コード/HTTP ステータス、サイズ、メソッド、URL などが並びます。注目するのは「結果コード/ステータス」の部分です。
| ログの例 | 意味 | 見る場所 |
|---|---|---|
| TCP_DENIED/403 | Squid のアクセス制御で拒否 | http_access の並び |
| TCP_DENIED/407 | プロキシ認証が必要 | auth_param とクライアントの認証設定 |
| TCP_TUNNEL/200 | CONNECT のトンネル確立 | 成功（HTTPS 通信） |
| TCP_MISS/503 など | 転送先に接続できない | DNS、外向きの経路、ファイアウォール |
| ログに出ない | Squid まで届いていない | クライアント設定、ポート、ファイアウォール |
結果コードの名前は Squid の版によって細かく違うことがあります。名前の細部より、DENIED、TUNNEL、MISS といった語の意味で読んでください。
切り分けにはクライアント側から curl を使うのが手軽です。-x でプロキシを指定し、-v で Squid とのやり取りを表示します。
curl -v -x http://10.0.0.5:3128 https://wordpress.org/ -o /dev/null原因1：Squid まで届いていない
access.log に何も出ない場合です。
- Squid が起動しているか：
systemctl status squid - 待ち受けているポートとアドレス：
sudo ss -tlnp | grep squid。http_portの設定と、クライアントが指定しているポートが一致しているかを確認します。 - ファイアウォール：Squid サーバーの ufw・firewalld、クラウドのセキュリティグループで、クライアントからのポート（既定では 3128）が許可されているか。
- クライアントのプロキシ設定：ブラウザの設定や環境変数
http_proxy・https_proxyが正しいホストとポートを向いているか。
curl が「Connection refused」なら待ち受けていない、応答が無いまま時間切れになるならファイアウォールで落ちている、と見当を付けられます。
原因2：TCP_DENIED/403（アクセス制御で拒否）
最も多い原因です。ブラウザには Squid の「Access Denied」系のエラーページが表示されます。
Squid の http_access は上から順に評価され、最初に一致した行で許可・拒否が決まります。既定の設定は最後が http_access deny all になっているので、許可したい送信元の行がそれより前に無いと拒否されます。
acl officenet src 192.168.10.0/24
http_access allow officenet
http_access deny all確認するポイントは次のとおりです。
- 送信元の ACL に、実際のクライアント IP が含まれているか（access.log の IP で確かめる）
- 許可の行が
deny allより前にあるか - HTTPS で 443 以外のポートへ CONNECT していないか。既定では
http_access deny CONNECT !SSL_portsがあり、443 以外への CONNECT は拒否されます - 宛先ドメインで絞っている場合、
dstdomainの書き方（先頭の.の有無でサブドメインを含むかが変わる）
直したら構文を確認してから設定を読み直させます。
sudo squid -k parse
sudo squid -k reconfigure原因3：TCP_DENIED/407（認証が通らない）
プロキシ認証を設定している場合、認証情報が送られていないか、間違っていると 407 になります。クライアント側で認証情報を設定しているか、パスワードファイルのパスや権限が Squid から読める状態かを確認します。
curl なら --proxy-user で試せますが、パスワードをコマンドラインに直接書くとシェルの履歴やプロセス一覧に残ります。検証用の一時アカウントを使い、終わったら削除してください。WordPress から認証付きプロキシを使う場合も、wp-config.php に書いた認証情報がバックアップやリポジトリに含まれないよう扱いに注意が必要です。
原因4：Squid から先へ接続できない
ログには届いていて、503 などの接続エラーになる場合は、Squid サーバー自身が外へ出られていません。ブラウザには接続失敗や DNS 解決失敗を示すエラーページが出ます。
- Squid サーバー上で、プロキシを使わずに
curl -sv https://wordpress.org/ -o /dev/nullが通るか - 名前解決できるか：
dig wordpress.org。Squid のdns_nameserversを設定している場合はその DNS が応答するか - 外向きのファイアウォールやクラウドの送信ルールで、80・443 が許可されているか
- IPv6 の経路が無い環境で、IPv6 アドレスへ接続しようとして失敗していないか（cache.log に接続先アドレスが出ます）
詳しい理由は /var/log/squid/cache.log に出ることが多いので、access.log とあわせて確認します。
原因5：WebSocket が通らない
Squid 経由で WebSocket が切れる、またはつながらない場合は、通信の種類で考え方が変わります。
wss://（TLS 付き）の場合、プロキシを経由するクライアントは CONNECT でトンネルを作り、その中で WebSocket をやり取りします。Squid から見ると普通の HTTPS と同じで、ログには TCP_TUNNEL として出ます。つながらないときは、宛先ポートが SSL_ports に含まれているか（443 以外のポートを使うサービスに注意）と、http_access で宛先が許可されているかを確認します。
ws://（平文）の場合、ブラウザによってはこれも CONNECT で通そうとしますが、通常の HTTP リクエストとして Upgrade ヘッダー付きで送られると、Squid の版と設定によっては Upgrade が転送されません。新しめの Squid には HTTP Upgrade の転送を許可する設定（http_upgrade_request_protocols）がありますが、対応する版や書式は使っている版のドキュメントで確認してください。実務上は、wss:// に切り替えてトンネルで通すほうが問題が起きにくく、通信も暗号化されます。
長時間つながったあとに切れる場合は、Squid のタイムアウト（read_timeout や、CONNECT トンネルのアイドル時間に関わる設定）や、途中のロードバランサー・NAT のアイドルタイムアウトが原因のことがあります。アプリ側で定期的に ping/pong を送り、アイドル状態にしないのが効果的です。
原因6：WordPress からの通信だけ失敗する
サーバー上の curl では通るのに、WordPress のプラグイン更新や外部 API 連携だけ失敗する場合は、WordPress のプロキシ設定を確認します。wp-config.php の WP_PROXY_HOST・WP_PROXY_PORT が正しいか、自サイト宛てを WP_PROXY_BYPASS_HOSTS で除外しているかを見ます。除外していないと WP-Cron などのループバック通信まで Squid に流れ、許可されずに失敗します。管理画面の「サイトヘルス」で、ループバックリクエストや REST API の確認結果を見ると手がかりになります。
直したあとの確認
squid -k parse で構文を確かめてから squid -k reconfigure で読み直させ、curl と access.log で結果コードが期待どおりかを見ます。設定の書式やログの細部は版によって異なります（2026年10月現在）。本番の Squid を変える前に、検証用の環境で同じ設定を試してください。
まとめ
- access.log に届いているか、どの結果コードかで、クライアント側・Squid の制御・Squid から先のどこが原因かを分けます。
- 403 は http_access の順序と ACL、407 は認証、接続エラーは Squid サーバーの DNS と外向き経路を確認します。
- WebSocket は wss:// を CONNECT で通すのが扱いやすく、長時間接続は ping/pong とタイムアウトの見直しで切断を防ぎます。
- WordPress からの通信は WP_PROXY_ 系の定数と自サイトの除外を確認します。
- 変更前に squid.conf を複製し、構文確認を通してから反映します。