利用者側の中継と、各ツールの設定は別々に確認します。親の比較ページから来た場合は、下のSquidの許可順と「クライアントのプロキシ設定」を使い分けてください。旧親にあったツール別の説明を本ページへ整理しています。

この記事の要点

フォワードプロキシは「クライアント側」に立つ代理サーバで、内部の利用者に代わって外部 (インターネット) へアクセスする 社内→外部のアクセスを一元的に通過させるため、URL フィルタリング・アクセスログ取得・認証といった出口制御に使われる 保存が許可された応答をキャッシュできる。中継先のIPが見えることと、利用者の匿名性が保証されることは別 代表的な実装は Apache HTTP Server と並ぶ定番である Squid。HTTP/HTTPS のプロキシとして広く使われる 明示型ではツールやOSでプロキシを指定する。自動設定や透過型もあり、全アプリが同じ設定を継承するとは限らない

概要

フォワードプロキシ (forward proxy) とは、クライアント (利用者) 側に立ち、内部のクライアントに代わって外部のサーバへアクセスする中継サーバです。社内 LAN の PC が直接インターネットへ出るのではなく、いったんプロキシへ要求を送り、プロキシが代理で目的のサイトへアクセスして、その結果をクライアントへ返します。利用者と外部の間に「出口の関所」を置くイメージで、企業ネットワークの境界に置かれることが多い仕組みです。親項目の 負荷分散・プロキシ・CDN を参照してください。

「プロキシ (proxy)」は代理人の意味で、フォワードプロキシは誰のための代理か = クライアントのための代理です。これに対し、サーバの代理として振る舞うのがリバースプロキシで、両者は立つ位置と目的が正反対です。フォワードプロキシは主に外向き通信の中継・制御に使います。認証・ログ・転送ヘッダー・接続先の識別子が残るため、匿名性を前提にしません。

仕組み

クライアントは「このサイトを見たい」という HTTP 要求を、目的サイトではなくフォワードプロキシ宛に送ります。プロキシは要求内容 (宛先 URL、認証情報など) を検査し、ポリシー上許可されていれば自分が改めて外部サーバへ接続して応答を取得し、それをクライアントへ転送します。流れを整理すると次のようになります。

• 要求の受付: クライアントはブラウザや OS のプロキシ設定でプロキシを指定します。適用するアプリ・プロトコル、NO_PROXYやPACによる除外によって実際の経路が変わります。
• ポリシー判定: プロキシは宛先 URL・カテゴリ・利用者認証を確認し、許可/拒否を決める (URL フィルタリング)。
• 代理アクセス: 許可された要求についてはプロキシ自身が外部サーバへ接続する。接続先から見えるTCPの送信元は中継先のものになりますが、元のIP等を転送する設定もあり匿名化の保証ではありません。
• キャッシュ: 保存可否・キー・鮮度・要求条件が合う応答を再利用します。HTTPSのCONNECTトンネル内の本文が自動でキャッシュされるわけではありません。

HTTPS の場合、暗号化されたトンネルを通すために CONNECT メソッドが使われ、プロキシは中身を見ずに TCP を中継します (中身まで検査するには SSL インスペクション用の証明書配布が別途必要です)。HTTP の基礎は HTTP、暗号化は HTTPS を参照してください。

設定・実用例

旧設定はそのまま適用しません：次の例はSSL_ports / Safe_portsを定義するだけで拒否に使っておらず、広いlocalnet許可が先に一致します。CONNECTの許可先ポートを制限できていません。待受アドレス・認証・管理機能/宛先制限・キャッシュ領域の権限も未設計です。記録として残し、直後の限定例と区別します。

# /etc/squid/squid.conf の例
http_port 3128

# 社内ネットワークを定義
acl localnet src 192.168.0.0/16

# 接続を許可するポートを限定 (CONNECT は 443 のみなど)
acl SSL_ports port 443
acl Safe_ports port 80 443 21

# localnet からのアクセスを許可、それ以外は拒否
http_access allow localnet
http_access deny all

# キャッシュ領域 (10GB)
cache_dir ufs /var/spool/squid 10000 16 256

# アクセスログ (出口監査に利用)
access_log /var/log/squid/access.log squid

loopback限定・キャッシュなしの確認用設定

以下はSquid 6/7系の構文を前提にした学習用です。127.0.0.1だけで受け、宛先のlocalhost/link-localと管理要求を拒否し、許可より前にポートを検査します。LAN公開・ユーザー認証・TLS検査を実装する完成設定ではありません。許可する送信元や待受を広げる変更は、ネットワーク/到達先の制限と一緒に管理者が設計してください。

# Review template: loopback only, no authentication or TLS inspection.
http_port 127.0.0.1:3128
acl permitted_clients src 127.0.0.1/32
acl SSL_ports port 443
acl Safe_ports port 80 443

# Order matters: defining an ACL does not enforce it.
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny manager
http_access deny to_localhost
http_access deny to_linklocal
http_access allow permitted_clients
http_access deny all

cache deny all
access_log stdio:/tmp/cwiki-squid-access.log
cache_log /tmp/cwiki-squid-cache.log
pid_filename /tmp/cwiki-squid.pid
visible_hostname cwiki-proxy-fixture

次の旧クライアント例の注意：exportは後続の子プロセスにも残ります。URL内のuser:passは履歴・プロセス情報・ログへ漏れ得るので実資格情報に置き換えて使いません。パスワードのURLエンコードも暗号化ではありません。下の一時指定と認証の説明を参照してください。

# シェルにプロキシを設定して curl で外部アクセス
export http_proxy=http://proxy.example.com:3128
export https_proxy=http://proxy.example.com:3128
curl -I https://www.example.com/

# 認証付きプロキシの場合
curl -x http://user:pass@proxy.example.com:3128 -I https://www.example.com/

設定反映は診断とは別作業です。対象版と実際の起動設定を確認し、squid -k parse -f 対象設定ファイルで構文を調べてから、承認済みの手順で反映・疎通・アクセス拒否・ログを確認します。構文成功だけで安全な経路や無停止は保証されません。設定ファイル全般の扱いは conf（.conf） も参考になります。

クライアントのプロキシ設定

以前の親記事にあったツール別の説明を、利用者側のフォワードプロキシへ整理しています。ブラウザで通ってもCLI・sudo・サービス・コンテナで同じ設定が使われるとは限りません。設定を保存する前に、対象プロセスが読む設定と現在の値、直接通信してよい宛先、承認された認証方式を確認します。以下のexample.comは説明用で、実在する社内設定ではありません。

環境変数とNO_PROXY

環境変数には大文字/小文字があり、優先順位・除外先の形式はツール依存です。curlは大小文字を区別する環境のHTTP用では大文字HTTP_PROXYを採用せず、小文字http_proxyを使います。Windows等では環境変数名の大小文字が区別されない点も確認します。NO_PROXYの先頭ドット・CIDR・ワイルドカードを全ツール共通の規則と考えず、使う版で一致/不一致の宛先を確かめます。全除外の指定をエラー回避のために付けると、必要なプロキシを迂回し得ます。

HTTPS_PROXYの値がhttp://で始まる場合もあります。これはクライアントからプロキシへの接続方式で、通常のHTTPS宛先はCONNECTの内側でTLSを使います。https://のプロキシはプロキシ自身へのTLSも別途確認します。OS設定へ永続化する操作と、一時指定を分離します。Windowsのプロセス環境変数とユーザー/マシンの永続設定も別で、既存の値を記録せず上書きしません。

# One command only; no saved configuration and no real credentials.
# Replace the proxy and approved destination for an authorized network test.
curl --proxy http://proxy.example.com:3128 --noproxy '' \
  --connect-timeout 5 --max-time 15 --head https://www.example.com/

# Bash/zsh: variables apply only to this command, not to later commands.
http_proxy=http://proxy.example.com:3128 \
https_proxy=http://proxy.example.com:3128 \
no_proxy=localhost,127.0.0.1 \
curl --connect-timeout 5 --max-time 15 --head https://www.example.com/

npm：一時指定とTLS検証

proxy / https-proxy / noproxyとregistry、ユーザー/プロジェクトの.npmrcや環境変数の優先順位を確認します。次のpingは指定中のregistryへ通信するので、宛先とアクセス権を先に確認してください。既存の.npmrcを作り直したり、registryを無関係な値へ変更したりしません。TLSエラーのためにstrict-ssl=falseを指定するのは避け、承認されたCAと信頼設定・対象ホスト・時刻等を調べます。--ignore-scriptsは通信やツール自体を安全にする指定ではありません。

# Read effective values; redact private proxy URLs before sharing output.
npm config get proxy
npm config get https-proxy
npm config get noproxy
npm config get registry
npm config get strict-ssl

# One invocation; no .npmrc overwrite or saved registry/proxy changes.
# --ignore-scripts avoids package scripts, not every network/third-party risk.
npm --proxy=http://proxy.example.com:3128 \
  --https-proxy=http://proxy.example.com:3128 \
  --strict-ssl=true --ignore-scripts ping
# ping contacts the configured registry; it does not install/publish packages.

Git：HTTPの設定とSSHの設定を分ける

HTTPSのremoteでもhttp.proxyが対象です。https.proxyを対応する標準設定と仮定しません。既存のhttp.<URL>.proxyやremote別の設定、環境変数、設定元も確認します。下は読取と一時設定の解析だけで、remoteへ接続しません。-cはそのGit起動だけに適用されます。実際の接続テストでは許可されたremoteと操作を選び、全ユーザーへ影響する--globalやTLS検証停止を初手にしません。

# Run inside the intended repository; values and origins can contain secrets.
git config --show-origin --show-scope --get-urlmatch http.proxy https://example.com/repo.git

# Configuration parsing only: no global/local writes and no network request.
git -c http.proxy=http://proxy.example.com:3128 \
  config --get-urlmatch http.proxy https://example.com/repo.git

SSH形式のremoteは別の接続経路です。ProxyJumpはSSHの踏み台、HTTP CONNECTプロキシには承認された対応コマンド等が必要で、同じ設定を流用できません。既存の.ssh/configを追記/上書きする前に、実際のHost規則と利用先が対応する接続方式を確認します。

APT / DNF：設定断片とパッケージ操作を分ける

次のAPT例は対象設定へマージする断片で、書込みコマンドではありません。Acquire::http::ProxyとAcquire::https::Proxyを確認し、既存のhost別設定や自動判定を消しません。apt-configでの読取にも秘密値が含まれ得ます。プロキシを確認する目的でupgrade・配布元変更・sudo -Eによる広い環境引継ぎを行いません。

// Fragment for review, not an instruction to overwrite /etc files.
Acquire::http::Proxy "http://proxy.example.com:3128";
Acquire::https::Proxy "http://proxy.example.com:3128";

DNFは採用する世代とrepo別設定を確認します。以下はDNF4系のmain断片で、無条件の末尾追記や古いyum.confの手順へ置き換えません。proxy_username / proxy_password等の秘密値を共有設定や履歴へ平文で置くかは別の管理判断で、下の例には含めていません。DNF5の設定や各OSの実配布元はその版の資料を確認してください。

# Fragment for the intended DNF4 [main] section; merge, do not append blindly.
[main]
proxy=http://proxy.example.com:3128

curl / Wget：保存設定を壊さずに試す

curlの-x/--proxyは明示指定ですが、NO_PROXYによる除外も確認します。--noproxy ''はcurlで除外を空にする一時指定で、組織の経路方針を無視してよいという意味ではありません。接続timeoutと全体の上限も別です。Wgetは自身の設定/対応版を調べ、.wgetrcを上書きせずに一回だけ指定できます。下は--spiderで宛先を確認する例で、認証やHTTPSの全面的な成功保証ではありません。

# One invocation; no .wgetrc overwrite. Head-like checking may differ by server.
wget --spider --timeout=15 --tries=1 \
  -e use_proxy=yes \
  -e http_proxy=http://proxy.example.com:3128 \
  -e https_proxy=http://proxy.example.com:3128 \
  https://www.example.com/

Docker：daemon・ビルド・コンテナは別設定

pull等でregistryへ接続するDocker daemon、RUN中に通信するビルド環境、起動後のコンテナで必要な経路を分けます。Docker CLIのconfig.jsonのproxiesは主に新しいビルド/コンテナへ渡す設定で、daemonの通信設定の代用ではありません。Docker Desktopでは専用設定を確認し、Linuxのsystemd例をそのまま適用しません。

proxyの環境変数はコンテナ設定から読める場合があり、URLへ資格情報を書けば秘密値になります。ビルド引数・ENV・イメージ層へ秘密値を残さず、既存config.jsonの認証/contextsを失わないようにマージ方法を検討します。daemonの再起動は他コンテナへ影響し得るため、診断の一部として実行しません。

認証・特殊文字・CA

URLのユーザー名/パスワード部分で特殊文字を使う場合は、その成分に合うpercent-encodingが必要ですが、エンコードは暗号化でも履歴対策でもありません。URL全体をまとめてエンコードせず、平文の秘密値をシェル引数・ログ・画面共有へ出さない認証方法を管理者と選びます。HTTPのプロキシ認証と宛先サイトの認証も別です。401と407を混同せず、TLSの検証停止や無条件のCA追加で通そうとしません。

PAC：PROXY行を一つ抜くだけではない

PACのFindProxyForURLはurl/host等でDIRECTや複数のプロキシ候補を返すプログラムです。1行だけ抜き出すと、社内宛先の直接通信・宛先別の中継・フォールバックの条件を失い得ます。CLIの対応は実ツールで確認し、ブラウザのPACが自動適用されると推測しません。不明なPACを実行せず、管理者が用意したCLI用の明示設定や対応ツールを使います。

つながらない場合の確認順

ブラウザやIDEだけ成功する場合も、CLIと同じ経路とは限りません。VS Code公式のネットワーク説明では本体がChromiumのシステム設定を利用しますが、拡張・内蔵Git・起動したCLIの通信は別に確認します。古いhttp.proxy設定だけで全経路が統一されると考えず、採用版の対応と実際のプロセスを調べます。

1. 対象プロセスの設定元と有効値、大小文字・除外先・PACの適用を調べる。出力は共有前に伏せる。
2. プロキシ名の名前解決・接続ポート・接続拒否/timeoutを分ける。TCP接続成功だけでHTTP許可や認証の成功とは判断しない。
3. 403等のポリシー拒否、407のプロキシ認証、宛先からの応答をログと時刻で照合する。
4. CONNECT後のTLS・CA/ホスト名・宛先アプリの認証を別に調べる。外部のIP確認サービスへ社内情報を送ることを診断の必須手順にしない。
5. 変更する場合は対象範囲を絞り、元の設定へ戻せることと、許可すべき/拒否すべき両方の要求を確認する。

主な用途

• アクセス制御 (URL フィルタリング): 業務に無関係なサイトや危険なサイトへの接続を一元的にブロックする。
• アクセスログの取得: 誰がいつどこへアクセスしたかを記録し、監査・インシデント調査に使う。
• 帯域の節約: よくアクセスされる静的コンテンツをキャッシュし、外向き回線の負荷を下げる。
• 接続元の集約: 接続先に見えるIPの集約と、利用者や通信内容の秘匿は別。認証・Cookie・ログ・転送情報等で識別され得ます。
• 認証ゲートウェイ: 外部アクセス時にユーザ認証を必須化し、未認証の通信を遮断する。

フォワードプロキシとリバースプロキシの比較

観点	フォワードプロキシ	リバースプロキシ
立つ位置	クライアント側	サーバ側
代理する対象	クライアント (利用者)	サーバ (バックエンド)
主目的	出口制御・キャッシュ・匿名化	負荷分散・SSL 終端・バックエンド隠蔽
クライアントの設定	明示型は指定する。自動設定/透過型は別	不要 (利用者は意識しない)
代表実装	Squid	nginx / Apache / HAProxy

注意点

• 単一障害点になりやすい: 全員の外向き通信が集中するため、プロキシが落ちると社内全体が外部へアクセスできなくなる。冗長化が望ましい。
• HTTPS の中身は基本見えない: 通常のCONNECTでは接続先host:portを指定します。TLS内のpath・query・本文をそのまま読めるわけではありません。TLS検査はCAの信頼・端末方針・認可を含む別設計で、証明書配布だけで安全/利用許可になるものではありません。
• オープンプロキシの危険: アクセス元を絞らず誰でも使える状態にすると、第三者の踏み台として悪用される。必ず接続元 IP や認証で制限する。
• キャッシュの鮮度: キャッシュ TTL を長くしすぎると古いコンテンツを返してしまう。個人別の応答は共有してよいかを先に判断し、動的/静的の名前だけで保存可否を決めません。
• クライアント設定の徹底: プロキシ設定をすり抜ける直接通信を許すと出口制御が無効化される。必要な直接通信や他プロトコルへの影響を調査し、出口制御の方針は管理者が別途設計します。診断のために一括遮断しません。

関連リンク

• 負荷分散・プロキシ・CDN
• リバースプロキシ
• HTTP
• HTTPS
• conf（.conf）

公式資料と確認範囲

2026年10月26日確認：Squidの許可/拒否・ACL・待受、curlのproxy/noproxy/TLS、npmのproxy/strict-ssl、Gitのhttp.proxy、APT設定、DNF4設定、Wget、Docker daemon・コンテナ/ビルド、PACの条件分岐。構文と隔離検体の検査は、実組織の認証・CA/TLS検査・PAC配布・OSサービス変更・全ツールの全版の成功保証ではありません。

成分の構文はURIのuserinfo、SSHとの違いはOpenSSHのProxyJump/ProxyCommand、registry診断はnpm pingも確認してください。