◀️

リバースプロキシを理解する。

2025/02/11に公開

AWS

nginx

proxy

tech

本記事では、リバースプロキシの概要を整理しながら、類似領域の技術であるAWS ALB や Nginx といったソフトウェアについて、そして Web サーバーソフトウェアとリバースプロキシの技術的な差分についても説明します。

さらに、ロードバランサにおける L4/L7 の違いなども深掘りしていきます。

 Reverse Proxy (リバースプロキシ) とは何か？
 リバースプロキシの概要
リバースプロキシとは、クライアント (ブラウザなど) からのリクエストを受け取り、内部のアプリケーションサーバや他のWebサーバ へ転送して、その結果をクライアントに返す仕組みです。
よく混同される Forward Proxy (フォワードプロキシ) は、クライアントが外部のサーバへアクセスする際に代理として振る舞うものですが、リバースプロキシはサーバ側の代理という点が異なります。

 リバースプロキシを導入するメリットセキュリティ強化
アプリケーションサーバが直接外部に晒されないため、攻撃リスクを減らしやすい。
負荷分散 (ロードバランシング)
複数のサーバへリクエストを振り分け、高負荷に耐えられる構成を組める。
キャッシュ機能の活用
リバースプロキシ側で静的リソースや同じレスポンスをキャッシュし、バックエンドサーバへの負担を減らす。
SSL 終端 (オフロード)
リバースプロキシで SSL/TLS 通信を終端し、バックエンドとは平文通信で行うことで、アプリケーションサーバの負荷を減らす。

 リバースプロキシの類似技術としての AWS ALBAWS では、ALB (Application Load Balancer) がリバースプロキシと類似の機能を提供します。
レイヤー7 ロードバランサ

ALB は HTTP/HTTPS レベルで動作し、パスベースやホストベースでのリクエスト振り分けが可能。

これは、リバースプロキシが行う 「クライアント → プロキシ → バックエンド」 という仕組みと同じ役割を果たします。
SSL 終端機能

ALB が SSL を一括で管理・処理し、バックエンドとの通信は HTTP で行うことが可能。

証明書更新などを ALB 側だけで済ませる利点があります。
制限事項

キャッシュ機能や細かいヘッダ書き換えなど、Nginx やその他リバースプロキシソフトウェアが持つ高度な機能は備えていない。
ログフォーマットを自由に変更できないなど、マネージドサービス特有の制限があります。
総じて、AWS 上では ALB が「リバースプロキシ的役割」を担える ため、アプリケーションサーバを直接外部に晒す必要がなくなり、セキュリティ・可用性を高められるメリットがあります。

 ALB と Nginx の使い分けALB でも大抵のリバースプロキシ機能(SSL 終端、パスベース振り分けなど)は実現できますが、以下のような要件がある場合は Nginx 等のリバースプロキシを併用することが多いです。

ログフォーマットを自由に変更したい
ALB のアクセスログは標準形式で S3 に出力される。細かくカスタマイズしてリアルタイム分析を行いたい場合、Nginx 側でカスタムログを生成する手法がよく使われる。


複雑なリライトやヘッダ操作を行いたい
特定クッキーが含まれるリクエストを別サーバに振り分ける、レスポンスヘッダを動的に書き換えるなど、ALB 単体では難しい制御を行うシーンがある。


キャッシュ機能を前段で持たせたい
ALB はバックエンドからのレスポンスをキャッシュできないので、短期的なキャッシュを活用し負荷軽減を図りたいなら Nginx(または Varnish) 側で行う。


 リバースプロキシ用ソフトウェアとしての NginxNginx はもともと 高性能な Web サーバソフトウェアとして開発されましたが、リバースプロキシとしても広く使われる豊富な機能を備えています。

高性能・非同期処理

イベントドリブン構造を採用しており、高い同時接続数をさばきやすい。

ロードバランシング機能

ラウンドロビンや最小接続数などのアルゴリズムをサポート。バックエンドのヘルスチェックも可能。

ヘッダ書き換え・リライト

proxy_pass ディレクティブや rewrite モジュールなど、細かい HTTP ヘッダや URI の操作がしやすい。

キャッシュ機能

静的リソースのほか、プロキシのレスポンスをキャッシュして高速化する設定ができる。

SSL 終端

証明書管理や HTTPS を Nginx が終端することで、バックエンドへの負担を減らす。
こうした豊富な機能により、Nginx は 「Web サーバ」兼「リバースプロキシソフトウェア」 として非常に人気があります。

Ruby on Rails のアプリケーションサーバ (Puma, Unicorn など) を使う場合も、前段に Nginx を置く構成がデファクトスタンダードとなっています。

 Web サーバーソフトウェアとリバースプロキシソフトウェアの技術的差分一般的に、Web サーバー用ソフトウェア と リバースプロキシ用ソフトウェア には以下のような相違点があります。


観点
Webサーバー用ソフトウェア
リバースプロキシ用ソフトウェア


主な目的

静的/動的コンテンツの直接配信
HTML/CSS/JS, CGI, PHP等
バックエンドへのプロキシ (ロードバランシング含む)

静的ファイルのホスティング
ネイティブにサポート (DocumentRootなど)
原則想定外 (バックエンドに任せる)

ロードバランシング機能
モジュール追加 (例: Apache mod_proxy) で部分的に対応

標準機能として強力にサポート (HAProxy, Nginx 等)

キャッシュ機能
簡易的 or オプションモジュール次第 (Nginx も可能)

高機能なキャッシュ(Varnish 等)

ヘッダ操作 / L7制御
一部は可能 (rewriteなど)

柔軟で高度(パス/ホストベース, ヘッダ書き換え 等)

ファイルシステムへのアクセス
直接ホスティングに利用 (DocumentRoot)
ほぼ無し (バックエンド側で管理)

拡張性 / プラグイン
Web サーバ寄り (CGI, PHP, FastCGI 等)
負荷分散や監視、認証強化などリバースプロキシ寄りの拡張


 まとめ純粋に「Web サーバ (静的ファイル配信)」が必要なら Apache や Nginx の Web サーバ機能が中心。
「アプリケーションサーバを裏に隠して、外部とのトラフィックを制御したい」場合はリバースプロキシの機能が主役となります。
Nginx や Apache は両機能をあわせ持ち、使い方次第で Web サーバにもリバースプロキシにもなれるため、モダンな環境では多用されています。

 L4 / L7 ロードバランサとリバースプロキシの違いリバースプロキシは主に L7 (アプリケーション層) でリクエストを処理します。一方、ロードバランサには L4 (トランスポート層) と L7 (アプリケーション層) の大きく 2 種類があります。

L4 ロードバランサ (例: AWS NLB, TCP レベルの HAProxy)
IP/ポートレベルで振り分ける
TCP/UDP ストリームを扱うため、HTTP ヘッダの解析やリライトはできない
高速かつシンプルで大容量トラフィックに向いている


L7 ロードバランサ (例: AWS ALB, HTTP レベルの HAProxy, Nginx)
HTTP/HTTPS の中身を見て振り分ける (パスベース、ホストベース、クッキーなど)
ヘッダ書き換えやキャッシュ、リライトといった高度な制御が可能
いわゆるリバースプロキシ的な機能と重なる部分が多い

リバースプロキシは「クライアントとバックエンドの中間で、HTTP のレイヤーで代理応答する」ため、実質 L7 ロードバランサの役割を果たすことになります。

 セキュリティ強化と WAF との連携リバースプロキシを置くことで 「攻撃対象を一元化しやすい」 という点は大きなメリットです。

具体的には、リバースプロキシ (Nginx / ALB) によって一括で外部からの通信を受け、その手前または内部で WAF (Web Application Firewall) を導入できます。

AWS WAF + ALB
ALB の前段で AWS WAF を設定することで、SQL インジェクションや XSS などの攻撃をフィルタリング。
ルールの更新を AWS WAF のコンソールから集中的に行える。


Nginx + ModSecurity
Nginx モジュールとして ModSecurity を組み込み、独自の WAF ルールを定義。
解析やレポートを Nginx のログと連携しやすい。

リバースプロキシがあることで、バックエンドサーバを非公開サブネットに置くなどのネットワークレベルのセキュリティ対策も行いやすくなります。

 実際の設定例
 Nginx のリバースプロキシ設定例 (Ruby on Rails + Puma)以下のように、バックエンドで Puma が UNIX ソケットを待ち受けしている場合、Nginx でそのソケットにトラフィックを転送できます。
upstream rails_app {
  server unix:///path/to/your_app.sock;
}

server {
  listen 80;
  server_name example.com;

  # HTTP→HTTPS リダイレクトをする場合は以下のように:
  # if ($scheme = http) {
  #   return 301 https://$host$request_uri;
  # }

  location / {
    proxy_pass http://rails_app;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    # 他にも必要に応じてヘッダ設定
  }
}

 ALB のターゲットグループ設定例ターゲットグループを作成し、ECS タスクなどのバックエンドを登録する。
ALB リスナー(80/443) でパスベースルーティングを設定し、例えば:
/api/* へのリクエストは ECS サービス A (ターゲットグループ A)
/web/* へのリクエストは ECS サービス B (ターゲットグループ B)

ヘルスチェック用パス (/health_check など) を用意し、200 OK を返すようにアプリケーションを実装する。

 まとめリバースプロキシは、クライアントとバックエンドサーバの間に入って通信を代理・制御する重要なコンポーネントです。

AWS ALB などの L7 ロードバランサも、リバースプロキシ的な働きを担えますが、ログフォーマットや複雑なリライト・キャッシュ機能といった高度な要件がある場合には、Nginx 等のリバースプロキシソフトウェアを併用するケースが多くなります。
また、リバースプロキシを置くことで セキュリティ (WAF 連携やバックエンドサーバ非公開化) を強化しやすく、可用性 (負荷分散) や パフォーマンス (キャッシュ) の最適化が可能です。
システム構築の際は、要件に合わせて
どこで負荷分散するか
どこでキャッシュするか
どうセキュリティを確保するか
を明確化すると、設計と運用がスムーズに進むでしょう。

観点	Webサーバー用ソフトウェア	リバースプロキシ用ソフトウェア
主な目的	静的/動的コンテンツの直接配信 HTML/CSS/JS, CGI, PHP等	バックエンドへのプロキシ (ロードバランシング含む)
静的ファイルのホスティング	ネイティブにサポート (DocumentRootなど)	原則想定外 (バックエンドに任せる)
ロードバランシング機能	モジュール追加 (例: Apache mod_proxy) で部分的に対応	標準機能として強力にサポート (HAProxy, Nginx 等)
キャッシュ機能	簡易的 or オプションモジュール次第 (Nginx も可能)	高機能なキャッシュ(Varnish 等)
ヘッダ操作 / L7制御	一部は可能 (rewriteなど)	柔軟で高度(パス/ホストベース, ヘッダ書き換え等)
ファイルシステムへのアクセス	直接ホスティングに利用 (DocumentRoot)	ほぼ無し (バックエンド側で管理)
拡張性 / プラグイン	Web サーバ寄り (CGI, PHP, FastCGI 等)	負荷分散や監視、認証強化などリバースプロキシ寄りの拡張

Discussion

ログインするとコメントできます