フォワードプロキシ

概要

フォワードプロキシは、クライアント（利用者側）の代理として外部のサーバへ接続する中継サーバです。社内のPCがインターネット上のWebサイトを見るとき、直接接続する代わりにいったんプロキシサーバへリクエストを送り、プロキシが本人に代わって外のサーバと通信して結果を持ち帰る — この「行きの通信をまとめて代理する門番」がフォワードプロキシです。「プロキシ（proxy）」は代理人という意味で、単に「プロキシサーバ」と言えば通常こちらを指します。

企業や学校のネットワークで「プロキシ設定をしないと外に出られない」という経験をしたことがあれば、それがまさにフォワードプロキシです。外部サーバから見ると、通信の送信元はプロキシサーバであり、その後ろにいる個々のクライアントは見えません。この「クライアント側に立ち、クライアントを隠す」という向きが、サーバ側に立つリバースプロキシとの決定的な違いです。

なぜ生まれたか

インターネットが組織に普及し始めた1990年代、管理者には2つの悩みがありました。1つはセキュリティと統制です。社内の全PCが自由に外部と通信できると、業務に関係ないサイトへのアクセスもマルウェアの通信も見分けがつかず、「誰がいつどこに接続したか」を把握するすべがありません。もう1つは回線の細さです。当時の対外回線は高価で遅く、社員100人が同じニュースサイトの同じ画像を100回ダウンロードするのは明らかな無駄でした。

そこで、外向きの通信をすべて1か所の中継サーバに集約するという発想が生まれました。出口が1つになれば、アクセスの記録・許可・拒否をそこで一括して行え、一度取得したコンテンツをキャッシュして2人目以降には手元から返せます。「通信の代理」という単純な仕組みが、統制・節約・匿名化という複数の課題を同時に解決したのです。

詳細

リバースプロキシとの向きの対比

フォワードプロキシとリバースプロキシは、どちらも「間に立って通信を中継するサーバ」ですが、誰の代理として、何を隠すかが正反対です。フォワードプロキシは組織の内側・クライアントの手前に立ち、「うちの社員がどこへアクセスするか」を統制しながらクライアントの素性を外部から隠します。一方リバースプロキシはサービス提供者側の入口に立ち、「誰がうちのサーバに来るか」を受け付けながら背後のサーバ構成を利用者から隠します。設定するのも、フォワードプロキシはクライアント側（ブラウザやOSのプロキシ設定）、リバースプロキシはサーバ側で、利用者は存在にすら気づきません。

出口を1つに絞ることで得られる統制

フォワードプロキシの最大の実務的価値は、外向き通信の「関所」になれることです。全クライアントの通信がプロキシを通るため、アクセスログの一元記録、URLフィルタリング（業務外サイトや危険サイトのブロック）、認証による利用者の特定が1か所で実現します。ファイアウォールがIPアドレスやポートといった低いレイヤで通信を許可・遮断するのに対し、プロキシはHTTPを理解した上で「どのURLに」「どんな内容を」といったアプリケーション層の判断ができます。実際の企業ネットワークでは、ファイアウォールで「外向き通信はプロキシ経由のみ許可」と絞った上で、プロキシ側で細かいポリシーを適用する組み合わせが定番です。この構成はマルウェア対策としても効きます。感染したPCが攻撃者のサーバへ直接通信しようとしても、プロキシを通らない通信は出口で遮断され、プロキシのログに不審な接続先の痕跡が残るからです。

キャッシュと帯域の節約

もう1つの古典的な役割がキャッシュです。プロキシは中継したレスポンスを手元に保存し、別のクライアントが同じリソースを要求したときにはオリジンサーバへ行かずに返します。回線が細かった時代にはこれが導入の主目的で、代表的な実装であるSquidはもともとキャッシュサーバとして発展しました。現在は対外回線が太くなり、HTTPS化でプロキシが中身を読めない通信が大半になったため、キャッシュ目的の存在感は薄れています。なお「Webサイトを速くするキャッシュ」の役割は、今日ではサーバ側に置くリバースプロキシやCDNが主に担っています。

HTTPSとCONNECTメソッド

HTTPS通信の中継には工夫が要ります。通信内容はTLSで暗号化されているため、プロキシは中身を読んだり書き換えたりできません。そこでHTTPには CONNECT というメソッドが用意されており、クライアントは「このホストの443番ポートへのトンネルを開いてほしい」とプロキシに依頼し、以降プロキシは暗号化されたバイト列をそのまま素通しします。この場合プロキシに見えるのは接続先ホスト名だけで、URLのパスや内容は見えません。より深い検査をしたい企業では、プロキシがTLSをいったん終端して再暗号化する「TLSインスペクション（中間者復号）」を行うこともありますが、これには全クライアントへの独自証明書の配布が必要で、プライバシーと証明書検証の無効化リスクをめぐる議論がつきまといます。

匿名化と落とし穴

外部サーバから見える送信元がプロキシになるという性質は、匿名化にも使われます。公開プロキシを経由して身元を隠す、あるいは接続元の国を変えて地域制限を回避するといった用途です（複数の中継を重ねて匿名性を高める Tor はこの発想の発展形です）。ただしプロキシ運用者にはすべての通信が見えるため、素性の知れない公開プロキシの利用はむしろ危険です。また、暗号化とトンネリングによって通信全体を保護するVPNとは、「アプリケーション層の代理」か「ネットワーク層のトンネル」かという点で仕組みが異なります。運用面の定番の落とし穴としては、プロキシ必須の社内環境でCLIツールやコンテナが外に出られない問題（HTTP_PROXY 環境変数の設定漏れ）、プロキシ自体が単一障害点・性能ボトルネックになる問題があり、近年はクラウド型のセキュアWebゲートウェイ（SWG）へ置き換えてゼロトラスト構成の一部とする流れが進んでいます。