この記事の要点

フォワードプロキシは「クライアント側」に立つ代理サーバで、内部の利用者に代わって外部 (インターネット) へアクセスする 社内→外部のアクセスを一元的に通過させるため、URL フィルタリング・アクセスログ取得・認証といった出口制御に使われる 同じコンテンツへのアクセスをキャッシュして帯域を節約したり、送信元 IP を隠して匿名化したりする用途もある 代表的な実装は Apache HTTP Server と並ぶ定番である Squid。HTTP/HTTPS のプロキシとして広く使われる クライアント側はブラウザや OS にプロキシサーバのアドレスを設定する必要があり、利用者が代理の存在を意識する点がリバースプロキシとの大きな違い

概要

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

「プロキシ (proxy)」は代理人の意味で、フォワードプロキシは誰のための代理か = クライアントのための代理です。これに対し、サーバの代理として振る舞うのがリバースプロキシで、両者は立つ位置と目的が正反対です。フォワードプロキシは主に外向き通信の制御・最適化・匿名化のために使われます。

仕組み

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

• 要求の受付: クライアントはブラウザや OS のプロキシ設定で「プロキシのアドレス:ポート」を指定し、すべての外向き要求をプロキシへ送る。
• ポリシー判定: プロキシは宛先 URL・カテゴリ・利用者認証を確認し、許可/拒否を決める (URL フィルタリング)。
• 代理アクセス: 許可された要求についてはプロキシ自身が外部サーバへ接続する。外部から見える送信元 IP はプロキシのものになる (匿名化)。
• キャッシュ: 取得した静的コンテンツをプロキシに保存し、次回以降は外部へ出ずに手元から返すことで帯域と応答時間を削減する。

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

設定・実用例

代表的なフォワードプロキシ実装である Squid の最小設定例です。社内 LAN (192.168.0.0/16) からのアクセスのみ許可し、3128 番ポートで待ち受けます。

# /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

クライアント側 (Linux) では環境変数でプロキシを指定して動作確認できます。

# シェルにプロキシを設定して 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 reconfigure で再読み込みします。設定ファイル全般の扱いは conf（.conf） も参考になります。

主な用途

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

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

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

注意点

• 単一障害点になりやすい: 全員の外向き通信が集中するため、プロキシが落ちると社内全体が外部へアクセスできなくなる。冗長化が望ましい。
• HTTPS の中身は基本見えない: CONNECT トンネルでは暗号化されているため URL の一部とドメインしか分からない。中身検査には SSL インスペクション (証明書配布) が必要で、プライバシー・運用上の配慮が要る。
• オープンプロキシの危険: アクセス元を絞らず誰でも使える状態にすると、第三者の踏み台として悪用される。必ず接続元 IP や認証で制限する。
• キャッシュの鮮度: キャッシュ TTL を長くしすぎると古いコンテンツを返してしまう。動的コンテンツはキャッシュ対象から外す。
• クライアント設定の徹底: プロキシ設定をすり抜ける直接通信を許すと出口制御が無効化される。ファイアウォールでプロキシ以外の外向き通信を塞ぐのが定石。

関連リンク

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