フォワードプロキシ
Forward Proxy ・ ふぉわーどぷろきし
クライアントの代理で外部へ接続する中継サーバ。組織の出口で記録・制限・キャッシュを担う。
✦ 30秒で試す — 航海社内から見たサイトには、社員ではなく門番の住所が残るプロキシの記録に残るのは？予想してみる概要
フォワードプロキシは、クライアント（利用者側）の代理として外部のサーバへ接続する中継サーバです。社内の PC がインターネット上の Web サイトを見るとき、直接接続する代わりにいったんプロキシへリクエストを送り、プロキシが本人に代わって外のサーバと通信して結果を持ち帰ります。この「行きの通信をまとめて代理する門番」がフォワードプロキシです。「プロキシ（proxy）」は代理人という意味で、単に「プロキシサーバ」と言えばふつうはこちらを指します。
企業や学校のネットワークで「プロキシ設定をしないと外に出られない」という経験をしたことがあれば、それがまさにフォワードプロキシです。外部のサーバから見ると、通信の送信元はプロキシであり、その後ろにいる個々のクライアントは見えません。この「クライアント側に立ち、クライアントを隠す」という向きが、サーバ側に立つリバースプロキシとの決定的な違いです。
なぜ生まれたか
インターネットが組織に普及し始めた1990年代、管理者には2つの悩みがありました。1つはセキュリティと統制です。社内の全 PC が自由に外部と通信できると、業務に関係ないサイトへのアクセスもマルウェアの通信も見分けがつかず、「誰がいつどこに接続したか」を把握する手段がありません。もう1つは回線の細さです。当時の対外回線は高価で遅く、社員100人が同じニュースサイトの同じ画像を100回ダウンロードするのは明らかな無駄でした。
そこで、外向きの通信をすべて1か所の中継サーバに集める発想が生まれました。出口が1つになれば、アクセスの記録・許可・拒否をそこで一括して行え、一度取得したコンテンツをキャッシュして2人目以降には手元から返せます。CERN の httpd（1994年ごろ）がプロキシ機能を備え、その後キャッシュ専用に鍛えられた Squid が広く使われました。「通信の代理」という単純な仕組みが、統制・節約・匿名化という複数の課題を同時に解いたのです。
詳細
リバースプロキシとの向きの対比
フォワードプロキシとリバースプロキシは、どちらも「間に立って通信を中継するサーバ」ですが、誰の代理として何を隠すかが正反対です。フォワードプロキシは組織の内側、クライアントの手前に立ち、「うちの社員がどこへアクセスするか」を統制しながら、クライアントの素性を外部から隠します。一方リバースプロキシはサービス提供者側の入口に立ち、「誰がうちのサーバに来るか」を受け付けながら、背後のサーバ構成を利用者から隠します。設定する場所も逆で、フォワードプロキシはクライアント側（ブラウザや OS のプロキシ設定）、リバースプロキシはサーバ側で、利用者はその存在にすら気づきません。
明示プロキシと透過プロキシ
クライアントがプロキシを使う方法は2通りあります。1つは明示プロキシで、ブラウザや OS に「proxy.example.co.jp の 8080 番を使う」と設定し、クライアント自身がプロキシへ話しかけます。このときクライアントは、リクエスト行に GET http://example.com/news HTTP/1.1 のように URL を丸ごと書いて「この URL を取ってきて」と頼みます（直接接続なら GET /news とパスだけを書きます）。
もう1つは透過プロキシ（インターセプトプロキシ）で、クライアントには何も設定せず、ネットワークの出口の機器が外向きの 80 番の通信を横取りしてプロキシへ回します。設定を配らなくてよい反面、クライアントはプロキシの存在を知らないので、プロキシ側で認証を求めることが難しく、HTTPS の通信は中身が暗号化されているため宛先のホスト名（TLS の SNI）くらいしか見えません。
明示プロキシの設定を1台ずつ手で配るのは大変なので、自動設定の仕組みがあります。PAC（Proxy Auto-Config）ファイルは、FindProxyForURL(url, host) という JavaScript の関数を1つ書いたファイルで、「社内のホストなら DIRECT（直接）、それ以外は PROXY proxy:8080」のように URL ごとに経路を返します。その PAC ファイルの場所を DHCP や DNS で自動的に見つけさせるのが WPAD（Web Proxy Auto-Discovery）です。ただし WPAD は、攻撃者が「wpad」という名前を先に名乗ると通信を丸ごと自分に向けさせられるという弱点が繰り返し指摘されており、使うなら PAC の URL を明示的に配るほうが安全です。
出口を1つに絞ることで得られる統制
フォワードプロキシの最大の実務的価値は、外向き通信の「関所」になれることです。全クライアントの通信がプロキシを通るので、アクセスログの一元的な記録、URL フィルタリング（業務外のサイトや危険なサイトのブロック）、認証による利用者の特定が1か所で実現します。ファイアウォールが IPアドレスやポート番号といった低いレイヤで通信を許可・遮断するのに対し、プロキシは HTTP を理解したうえで「どの URL に」「どんな内容を」というアプリケーション層の判断ができます。
実際の企業ネットワークでは、ファイアウォールで「外向き通信はプロキシ経由だけ許可」と絞ったうえで、プロキシ側で細かいポリシーを適用する組み合わせが定番です。この構成はマルウェア対策にも効きます。感染した PC が攻撃者のサーバへ直接通信しようとしても、プロキシを通らない通信は出口で遮断され、プロキシのログに不審な接続先の痕跡が残るからです。
キャッシュと帯域の節約
もう1つの古典的な役割がキャッシュです。プロキシは中継した応答を手元に保存し、別のクライアントが同じリソースを求めたときにはオリジンサーバへ行かずに返します。回線が細かった時代にはこれが導入の主目的でした。現在は対外回線が太くなり、HTTPS 化でプロキシが中身を読めない通信が大半になったため、キャッシュ目的の存在感は薄れています。「Web サイトを速くするキャッシュ」の役割は、今日ではサーバ側に置くリバースプロキシや CDN が主に担っています。
HTTPS と CONNECT メソッド
HTTPS の通信は TLS で暗号化されているため、プロキシは中身を読むことも書き換えることもできません。そこで HTTP には CONNECT というメソッドが用意されていて、クライアントは「このホストの 443 番へのトンネルを開いてほしい」とプロキシに頼み、以降プロキシは暗号化されたバイト列をそのまま素通しします。
この場合、プロキシに見えるのは接続先のホスト名と通信量だけで、URL のパスや内容は見えません。より深い検査をしたい組織では、プロキシが TLS をいったん終端して再暗号化する「TLS インスペクション（中間者型の復号）」を行うこともあります。これには全クライアントへ組織独自のルート証明書を配る必要があり、プロキシが証明書の検証を肩代わりするぶん、そこに不備があれば利用者は偽のサイトを見抜けなくなります。プライバシーとの兼ね合いも含め、導入には慎重な判断が要ります。
匿名化と落とし穴
外部のサーバから見える送信元がプロキシになるという性質は、匿名化にも使われます。公開プロキシを経由して身元を隠す、接続元の国を変えて地域制限を回避する、といった用途です（複数の中継を重ねて匿名性を高める Tor は、この発想の発展形です）。ただしプロキシの運用者にはすべての通信が見えるので、素性の知れない公開プロキシを使うのはむしろ危険です。また、通信全体をトンネルに包む VPN とは、「アプリケーション層の代理」か「ネットワーク層のトンネル」かという点で仕組みが異なります。
運用面の定番の落とし穴は、プロキシ必須の社内環境で CLI ツールや コンテナが外に出られない問題です。ブラウザは OS のプロキシ設定を読みますが、多くのコマンドや言語のライブラリは HTTP_PROXY・HTTPS_PROXY・NO_PROXY の環境変数しか見ず、コンテナの中にはホストの設定が引き継がれません。プロキシ自体が単一障害点や性能のボトルネックになる問題もあり、近年はクラウド型のセキュア Web ゲートウェイ（SWG）へ置き換えて、ゼロトラスト構成の一部とする流れが進んでいます。
試問
会社の出口にあるフォワードプロキシが、社員の PC から外の HTTPS のサイトへの通信を中継しています。プロキシは CONNECT（「このホストの 443 番へトンネルを開いて」という頼み）を受けてトンネルを張り、あとは暗号化されたバイト列を中継するだけです。TLS を復号する仕組み（TLS インスペクション）は入れていません。
この HTTPS の通信について、プロキシに見えるものと見えないものを仕分けよ
項目を選んでから、入れる箱を選びます