Zenn
◀️

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

2025/02/11に公開
AWS
nginx
proxy
tech

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

Reverse Proxy (リバースプロキシ) とは何か？

リバースプロキシの概要

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

リバースプロキシを導入するメリット

  1. セキュリティ強化

    • アプリケーションサーバが直接外部に晒されないため、攻撃リスクを減らしやすい。

  2. 負荷分散 (ロードバランシング)

    • 複数のサーバへリクエストを振り分け、高負荷に耐えられる構成を組める。

  3. キャッシュ機能の活用

    • リバースプロキシ側で静的リソースや同じレスポンスをキャッシュし、バックエンドサーバへの負担を減らす。

  4. SSL 終端 (オフロード)

    • リバースプロキシで SSL/TLS 通信を終端し、バックエンドとは平文通信で行うことで、アプリケーションサーバの負荷を減らす。

リバースプロキシの類似技術としての AWS ALB

AWS では、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) 側で行う。

リバースプロキシ用ソフトウェアとしての Nginx

Nginx はもともと 高性能な 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 連携やバックエンドサーバ非公開化) を強化しやすく、可用性 (負荷分散) や パフォーマンス (キャッシュ) の最適化が可能です。

システム構築の際は、要件に合わせて

  • どこで負荷分散するか
  • どこでキャッシュするか
  • どうセキュリティを確保するか

を明確化すると、設計と運用がスムーズに進むでしょう。

Discussion