【比較】プロキシとゲートウェイの違い¶

概要¶

「プロキシ（proxy）」も「ゲートウェイ（gateway）」も、通信の途中に立つ中継者である点では共通しますが、誰の代理として、何のために立つかが異なります。プロキシは「誰かの代理」が語源で、HTTP の世界では大きく 2 方向あります。フォワードプロキシはクライアント側に立ち、社内 PC 群の代わりに外部へリクエストを送る代理です（RFC 9110 は「クライアントが選ぶメッセージ転送エージェント」と定義）。リバースプロキシはサーバー側に立ち、外部から見ると本物のサーバーに見える窓口です。RFC 9110 はこの後者を gateway と定義し、「リバースプロキシ」はその別名だと明記しています。つまり HTTP 仕様の文脈では「リバースプロキシ＝（HTTP）ゲートウェイ」です。

一方「ゲートウェイ」という語は文脈で意味が変わります。(1) 上記の HTTP ゲートウェイ（リバースプロキシ）、(2) マイクロサービスのAPI ゲートウェイ（全クライアントの単一の入口として、ルーティング・認証・レート制限・レスポンス集約などを担う L7 のエッジ機能）、(3) ネットワークゲートウェイ（異なる伝送プロトコルの 2 つのネットワークを接続し、必要ならプロトコル変換する節点。デフォルトゲートウェイなど）の 3 つは別物です。本記事は「プロキシは誰の代理か（向き）」と「ゲートウェイという語の 3 つの意味」を整理するのが目的です。なお、クライアント/サーバー間の中継で負荷分散とリクエスト中継のどちらを主目的とするかという軸はロードバランサーとリバースプロキシの違いで扱っており、本記事は「代理の向き」と「ゲートウェイ概念」に焦点を絞るため、両記事は補完関係にあります。

例えるなら：代理人の「立ち位置」¶

フォワードプロキシは「買い物の代理人」です。あなた（クライアント）が「これを買ってきて」と頼むと、代理人があなたの代わりに店へ出向きます。店からはあなたの顔は見えず、代理人しか見えません（クライアントの匿名化）。リバースプロキシ（＝HTTP ゲートウェイ）は会社の「総合受付」です。外部の来訪者は受付としか話さず、奥にいる担当部署（バックエンド）の存在や配置は見えません（サーバーの隠蔽）。API ゲートウェイは受付に加えて「コンシェルジュ」で、用件を振り分け（ルーティング）、本人確認（認証）し、混雑時は入場制限（レート制限）し、複数部署の回答をまとめて 1 枚にして返します（集約）。ネットワークゲートウェイは「国境の通訳付き関所」で、言語（プロトコル）の違う 2 つの国（ネットワーク）の間で言葉を訳しながら通します。比喩は立ち位置の理解に有効ですが、実装上は 1 つのソフトウェア（Nginx, Envoy など）が複数の役割を兼ねる点に注意してください。

詳細比較¶

項目	フォワードプロキシ	リバースプロキシ（＝HTTPゲートウェイ）	APIゲートウェイ	ネットワークゲートウェイ
誰の代理か	クライアント（の代理）	サーバー（の代理・代表）	サーバー群（の単一の入口）	ネットワーク（の接続点）
置かれる場所	クライアント側（社内出口など）	サーバー側（公開境界）	サービス群の前面（エッジ）	2 つのネットワークの境界
隠すもの	クライアントの素性・IP	バックエンドサーバーの素性・構成	内部サービスの分割構造	（隠蔽が目的ではない）
主な役割	外向きアクセスの代理・制御（フィルタ・キャッシュ・匿名化）	外向き接続のオリジンサーバーとして振る舞い内部へ転送（RFC 9110）	ルーティング・認証・レート制限・レスポンス集約・プロトコル変換	異プロトコル網の相互接続・プロトコル変換・経路の出口
動作レイヤー	主に L7（HTTP）／L4 トンネル	主に L7（HTTP）	L7（アプリケーション）	任意（L2〜L7。プロトコル変換のため複数層に跨る）
典型例	社内 Web フィルタ、Squid、Tor	Nginx/Envoy をサーバー前段に、CDN	Amazon API Gateway、Kong、Spring Cloud Gateway	デフォルトゲートウェイ（ルーター）、VoIP/IoT プロトコル変換装置
クライアントの認識	クライアントは代理を意図的に設定して使う	クライアントは普通のサーバーだと思っている	クライアントは単一の API だと思っている	通常は経路上の存在として意識されない

RFC 9110（HTTP セマンティクス）は中継者を、クライアントが選ぶ「proxy（メッセージ転送エージェント）」と、外向き接続に対してオリジンサーバーとして振る舞い受信要求を内向きに転送する「gateway」に分け、後者を「reverse proxy とも呼ぶ」と明記しています。MDN も「フォワードプロキシはクライアントの代理として動作し、リバースプロキシはサーバーの素性を隠す」と同じ向きで説明します。API ゲートウェイは microservices.io が「全クライアントの単一の入口」と定義し、ルーティング／集約（fan-out）／プロトコル変換／認可などのエッジ機能を担うとしています。ネットワークゲートウェイは Wikipedia（telecommunications）が「異なる伝送プロトコルの 2 ネットワークを接続する節点で、ルーター/スイッチと異なり複数プロトコルで通信し OSI の任意の層で動作しうる」と定義します。

よくある誤解¶

「フォワードプロキシとリバースプロキシは同じ proxy なので役割も似ている」は誤り。 共通するのは「中継する」ことだけで、代理の向きが正反対です。フォワードプロキシはクライアントの代理で外へ出ていき（クライアントを隠す）、リバースプロキシはサーバーの代理で外から受ける（サーバーを隠す）。RFC 9110 は前者を proxy、後者を gateway と別概念として定義しており、MDN も「リバースプロキシはフォワードプロキシの逆をする」と明記しています。
「ゲートウェイといえばネットワークの出口（デフォルトゲートウェイ）のことだ」は一面的で誤解を招く。 ネットワークゲートウェイは確かに一つの意味ですが、HTTP 仕様の文脈では「gateway＝リバースプロキシ」（RFC 9110）であり、マイクロサービスの文脈では「API ゲートウェイ」（単一入口・L7 エッジ機能）を指します。同じ語が層も役割も違う 3 つを指すため、文脈を確認せずに 1 つの意味で断定するのは誤りです。
「API ゲートウェイはただのリバースプロキシ（言い換えにすぎない）」は不正確。 API ゲートウェイは確かにリバースプロキシ的にリクエストを転送しますが、microservices.io が挙げるように複数サービスへの fan-out とレスポンス集約、クライアント種別ごとの API（Backends for Frontends）、認可・レート制限といったアプリケーション寄りの責務を持ちます。「素のリバースプロキシ＝転送・キャッシュ・SSL 終端中心」に対し、API ゲートウェイは API 合成まで踏み込む点が異なります。
「フォワードプロキシを通せば必ず匿名になる」は誤り。 フォワードプロキシは接続元 IP をプロキシのものに置き換えられますが、X-Forwarded-For 等のヘッダを付与する透過型もあり、匿名性は設定次第です。MDN も Tor のように複数プロキシを連鎖させて初めて高い匿名性が得られる例を挙げており、「プロキシ＝即匿名」ではありません。

実務での選び分け¶

社内 PC 群の外向きアクセスを制御・フィルタ・キャッシュしたい → フォワードプロキシ（出口を一本化し、URL フィルタや監査ログを集約）。
公開サーバーの素性を隠し、SSL 終端・キャッシュ・負荷分散の窓口を作りたい → リバースプロキシ（＝HTTP ゲートウェイ）。負荷分散が主目的か中継が主目的かの整理はロードバランサーとリバースプロキシの違いを参照。
多数のマイクロサービスを単一エンドポイントに集約し、認証・レート制限・レスポンス合成を一元化したい → API ゲートウェイ。ただしゲートウェイが肥大化（万能化）すると単一障害点・ボトルネックになるため、認可など横断関心の薄いラッパーに保つ。
異なるプロトコルのネットワーク同士をつなぐ／LAN の外への出口が必要 → ネットワークゲートウェイ（多くはルーターがデフォルトゲートウェイを兼ねる。VoIP・IoT などプロトコル変換が要るときは専用ゲートウェイ）。
語の指す対象を最初に確認する → 「ゲートウェイ」と聞いたら HTTP（リバースプロキシ）／API（マイクロサービス入口）／ネットワーク（節点）のどれかを必ず文脈で特定する。混同したまま設計議論を進めない。

ひとことまとめ¶

プロキシは「誰の代理か（向き）」で分かれ、フォワードプロキシはクライアントの代理（クライアントを隠す）、リバースプロキシはサーバーの代理（サーバーを隠す＝RFC 9110 の gateway）です。「ゲートウェイ」は文脈依存の語で、HTTP では「リバースプロキシ」、マイクロサービスでは「単一入口の L7 エッジ（API ゲートウェイ）」、ネットワークでは「異プロトコル網の接続節点」を指します。

出典・参考¶

RFC 9110: HTTP Semantics — Section 3.7 Intermediaries — proxy は「クライアントが選ぶメッセージ転送エージェント」、gateway は「外向き接続のオリジンサーバーとして振る舞い受信要求を内向きに転送する中継者」で「reverse proxy とも呼ぶ」と定義
Proxy servers and tunneling — MDN Web Docs — フォワードプロキシ／リバースプロキシの定義、「フォワードプロキシはクライアントの代理として動作し、リバースプロキシはサーバーの素性を隠す」、Tor の匿名化の例
Pattern: API Gateway / Backends for Frontends — microservices.io — API ゲートウェイは「全クライアントの単一の入口」で、ルーティング・複数サービスへの fan-out とレスポンス集約・プロトコル変換・認可、クライアント種別ごとの API（BFF）を担う
Gateway (telecommunications) — Wikipedia — ネットワークゲートウェイは「異なる伝送プロトコルの 2 ネットワークを接続する節点」で、ルーター/スイッチと異なり複数プロトコルで通信し OSI の任意の層で動作しうる
ロードバランサーとリバースプロキシの違い — クライアント/サーバー間中継で「負荷分散が主目的」か「リクエスト中継が主目的」かの整理（本記事と補完関係）