プロキシの仕組みを図にした。前と後ろで、守る相手が逆になる

• フォワード型は利用者を隠し、リバース型はサーバーを隠す
• 通すと元の利用者が分からなくなる
• それを伝えるためのヘッダーが決まっている

「プロキシ」という言葉が、文脈によって別のものを指すので分かりにくい。向きが違うだけなので、図にすると整理できる。

向きが逆になっている

フォワード型

MDNの説明では、フォワードプロキシはクライアント、またはクライアントの集団にサービスを提供する。

• 集団が使う帯域を減らし、制御する
• DNSやウェブページなどを保存して転送する
• 利用者の素性を隠せる

社内から外に出るときに1か所を通す構成が、この形にあたる。

リバース型

MDNの説明では、リバースプロキシはフォワードプロキシとは逆の動作をし、サーバーに代わって動く。サーバーの素性を隠せる。

主な使われ方として挙げられているのは次の3つだ。

• 負荷の分散 … 複数のウェブサーバーに負荷を分ける
• 静的な内容の保存 … 画像などを保存して、ウェブサーバーの負荷を軽くする
• 圧縮 … 内容を圧縮して、読み込み時間を短くする

レンタルサーバーやCDNで「キャッシュが効いている」と言うとき、この層のことを指している場合が多い。

配信の段で内容が変わることがある

圧縮や最適化が挟まると、サーバー上のファイルと、実際に届くものが一致しなくなる。直したのに反映されない、という現象の原因になりうる。

確かめるときは、ファイルではなく実際に配信されている内容を見る。手順は表示が遅い原因を、順番に調べた作業に書いた。

元の利用者が分からなくなる

プロキシを通すと、リクエストはプロキシのIPアドレスから来たように見える。MDNはこれが、デバッグ、統計、地域に応じた出し分けに影響すると説明している。

そこで、元の情報を伝えるヘッダーが定められている。

X- で始まるものは事実上の標準として広く使われている形で、Forwarded が標準として定められたもの、という関係になる。

実務で効く場面

• アクセス解析の記録が全部同じIPになる → X-Forwarded-For を見ていない
• httpsなのにhttp扱いになる → X-Forwarded-Proto を見ていない。リダイレクトが無限に繰り返されることがある
• 中継が挟まっているか知りたい → Via を見る。MDNによれば前後どちらのプロキシも付けるので、リクエストとレスポンスの両方に現れる

2番目は実際によく起きる。自分は暗号化された通信をしているつもりでも、プロキシから奥へは平文で渡っている構成だと、奥側は「httpで来た」と判断してしまう。

暗号化された通信を通すとき

プロキシの奥で暗号化された通信をするには、別の仕組みが要る。MDNはこれをHTTPトンネリングとして説明しており、CONNECT というメソッドを使う。上位のプロトコルで下位のプロトコルを運ぶ形になる。

ただしすべてのプロキシが対応しているわけではなく、特定のポートに限定している場合もあるとされている。

まとめ

• フォワード型は利用者側に立ち、利用者の素性を隠す
• リバース型はサーバー側に立ち、サーバーの素性を隠す
• リバース型の役割は、負荷の分散・静的な内容の保存・圧縮
• 通すと元の利用者が分からなくなるので、専用のヘッダーで伝える
• X-Forwarded-Proto を見落とすと、httpsがhttp扱いになる
• Via は前後どちらのプロキシも付ける

出典

• MDN「プロキシーサーバーとトンネリング」（フォワードとリバースの役割、転送用ヘッダー、Via、CONNECTによるトンネリング）

図は本記事のために作成したもの。本記事は2026年10月13日時点の内容に基づく。