リバースプロキシ

たとえ話: 会社の受付

リバースプロキシは会社の受付です。外部からの来訪者(=クライアント)は、まず受付に来ます。受付は『どの社員(=内部サーバー)に取り次ぐか』を判断し、来訪者には社内の座席配置(=サーバーの内部構成)を一切見せません。怪しい来訪者は門前払い(IPブロック)し、混みすぎたら入場制限もします。

図を描画中...

クライアントから見えるのはプロキシのIPだけ。裏に何台サーバーがあるか、どんな構成かは隠されます。これがセキュリティと柔軟性を生みます。

リバースプロキシ vs フォワードプロキシ(混同注意)

• フォワードプロキシ: クライアント側に立ち、クライアントを代理する(社内から外部サイトへ出るときの代理)。
• リバースプロキシ: サーバー側に立ち、サーバーを代理する(外部からサーバーへ入るときの窓口)。

名前が似ていて紛らわしいですが、『誰の代理か』が真逆です。

ロードバランサーとの違い

機能が重なるので混乱しがちですが、主目的が違います。

	リバースプロキシ	ロードバランサー
主目的	窓口の一元化・保護・キャッシュ	複数サーバーへの負荷分散
サーバー1台でも有用?	はい(隠蔽・SSL・キャッシュの価値)	あまり(分散先がない)
典型ツール	NGINX	HAProxy / NGINX

NGINXやHAProxyは両方の役割を兼ねられるので、実際には『リバースプロキシ兼ロードバランサー』として使われることが多いです。

できること一覧

• セキュリティ(内部隠蔽、IPブラックリスト、接続数制限)
• SSL termination(暗号化処理の肩代わり)
• 圧縮(レスポンスを小さくして転送を速く)
• キャッシュ(同じリクエストへの応答を使い回す)
• 静的コンテンツ配信(画像などを直接返す)

つまずきポイント

• 「LBとリバースプロキシは同じものでは?」とよく混乱する。ツールが同じ(NGINX)でも、果たしている役割で呼び分ける。分散しているならLB的、窓口・保護しているならリバースプロキシ的。
• リバースプロキシも1台だと単一障害点。本番では冗長化する。

---

📊 図解

リバースプロキシ vs ロードバランサーの構成

図を描画中...