リバースプロキシ

リバースプロキシとは

リバースプロキシは、クライアントとバックエンドサーバーの間に位置し、リクエストを中継・制御するサーバーである。クライアントが知るのは公開されたプロキシのホスト名だけで、その裏に何台のサーバーがどう並んでいるかは見えない。自前で構築するなら Nginx や Envoy、AWS のマネージドサービスなら ALB と CloudFront が代表的な実装になる。

フォワードプロキシ vs リバースプロキシ

向きを決めるのは製品ではなく「誰がプロキシの存在を知っているか」である。フォワードプロキシはクライアント側に設定を入れて使う。ブラウザのプロキシ設定や HTTP_PROXY 環境変数でプロキシを指し、最終的な宛先はクライアントがリクエストの中で伝える。リバースプロキシは逆に、公開ドメインの DNS レコードがプロキシ自身を指す。クライアントは普通のサーバーへ接続したつもりでいて、どこへ転送されるかを知らないし選べない。同じ Nginx が設定次第でどちらにもなるため、ソフトウェア名では区別できない。

観点	フォワードプロキシ	リバースプロキシ
位置	クライアント側	サーバー側
目的	クライアントの匿名化	サーバーの保護
例	企業の Web フィルタ	CloudFront, Nginx

フォワード: クライアント → [プロキシ] → インターネット → サーバー
リバース:   クライアント → インターネット → [プロキシ] → サーバー

リバースプロキシの機能

経路上の 1 点に集約すると、バックエンドのコードを触らずに横断的な処理を差し込める。

機能	説明	AWS サービス
ロードバランシング	リクエストを複数サーバーに分散	ALB
TLS 終端	HTTPS を復号し、バックエンドへは HTTP で渡す	CloudFront, ALB
キャッシュ	レスポンスをキャッシュ	CloudFront
圧縮	gzip/brotli 圧縮	CloudFront
WAF	攻撃トラフィックをブロック	AWS WAF
パスルーティング	パスに応じてバックエンドを切り替え	CloudFront, ALB

CloudFront が /api/* を API Gateway に、それ以外を S3 にルーティング。クライアントからは 1 つのドメインに見える。

転送元情報の扱いと信頼境界

プロキシを挟むと、バックエンドから見た接続元はプロキシの IP になる。元のクライアント IP やプロトコルは X-Forwarded-For や X-Forwarded-Proto で引き継ぐのが慣例である。落とし穴は、これらが普通のリクエストヘッダーでしかなく、クライアント自身も付けて送れる点にある。ALB は既存の X-Forwarded-For を捨てずに観測した IP を末尾へ追記するため、カンマ区切りで値が複数並ぶとき信頼できるのは自分が挟んだプロキシが足した位置だけである。先頭を無条件に「本当のクライアント IP」として扱うと、IP 制限やレート制限をクライアント側から偽装できる穴になる。ヘッダー個別の挙動は TLS 終端 で詳しく扱う。

マネージドサービスへの置き換えと限界

マネージドサービスを使えば Nginx のプロセスを自前で運用せずに済む。ただし製品同士が 1 対 1 で対応するわけではなく、効く層が違う。

サービス	効く層	得意なこと
CloudFront	世界各地のエッジロケーション	キャッシュ配信、TLS 終端、クライアントに近い場所での受け止め
ALB	リージョン内の L7	ターゲットへの分散、パスとホストによる振り分け、ヘルスチェック
API Gateway	API 単位のファサード	認可、使用量プラン、リクエストの検証と変換

自前の Nginx でなければ届かない範囲も残る。アプリ都合で任意の TCP や UDP を中継する、リクエストボディを書き換える、独自モジュールに認証ロジックを埋め込むといった用途はマネージドの枠から外れる。上限値の差も選定に響く。API Gateway の統合タイムアウトは既定で 29 秒、これを超える設定はリージョナル REST API とプライベート REST API に限りクォータ引き上げで可能になる (2026 年 8 月時点)。長く待たせる処理や大きなアップロードを通すなら、上限に当たらない経路を選ぶか、そもそも非同期に切り替える。

選定はやりたいことから逆算する。レスポンスをキャッシュして配信を速くしたいなら CloudFront、EC2 や ECS のターゲットへ分散してヘルスチェックで切り離したいなら ALB、認可とスロットリングをアプリの外へ出したいなら API Gateway が起点になる。多段に重ねる構成も普通で、その場合はどの段で TLS を終端し、どの段が足したヘッダーを信頼するかを設計時に決めておく。決めずに始めると、後から IP 制限やリダイレクト URL の生成で辻褄が合わなくなる。