この記事の要点

リバースプロキシは「サーバ側」に立つ代理サーバで、外部からの要求をいったん受け取り、後ろのバックエンドサーバへ振り分ける クライアントから見ると 1 台のサーバに見えるが、実際には複数のバックエンドが裏に隠れている (バックエンド隠蔽) SSL/TLS 終端 (HTTPS の復号) をリバースプロキシで一括処理し、バックエンドは平文 HTTP で楽に運用できる 複数バックエンドへ要求を分散する負荷分散、応答のキャッシュ、WAF (Web アプリケーションファイアウォール) などの機能を集約できる 代表的な実装は nginx と Apache HTTP Server。クラウドの ALB なども実体はリバースプロキシ

概要

リバースプロキシ (reverse proxy) とは、サーバ側に立ち、Web サーバ群 (バックエンド) の代理として外部からの要求を受け付ける中継サーバです。クライアントはリバースプロキシのアドレスへアクセスし、リバースプロキシが裏側のアプリケーションサーバへ要求を転送して、その応答を返します。利用者からは「1 台の Web サーバ」に見えますが、実際にはその後ろに複数のサーバが隠れていることが多く、これをバックエンド隠蔽と呼びます。親項目の 負荷分散・プロキシ・CDN を参照してください。

フォワードプロキシが「クライアントの代理」であるのに対し、リバースプロキシは「サーバの代理」です。立つ位置が逆 (reverse) なのでこの名があります。現代の Web 構成ではほぼ必須の要素で、nginx・Apache HTTP Server・HAProxy、クラウドのロードバランサ (ALB 等) はいずれもリバースプロキシの一種です。

仕組み

外部からの要求はまずリバースプロキシに届きます。リバースプロキシは要求の内容 (ホスト名・パス・ヘッダ) を見て、どのバックエンドへ渡すかを決定し、自分が改めてバックエンドへ接続して応答を受け取り、クライアントへ返します。この中継点に各種機能を集約できるのが強みです。

• SSL/TLS 終端 (SSL 終端): HTTPS の暗号化・復号をリバースプロキシでまとめて処理する。バックエンドは平文 HTTP で動かせるため、証明書管理が 1 か所で済み、暗号処理の負荷も集約できる。詳細は HTTPS を参照。
• 負荷分散: 同じ役割のバックエンドを複数並べ、要求を振り分けて 1 台あたりの負荷を下げる。詳しくは ロードバランサ を参照。
• キャッシュ: 静的ファイルや変化の少ない応答を保存し、バックエンドに行かずに即座に返す。
• WAF / セキュリティ: 不正な要求パターンを遮断し、バックエンドの IP・構成を外部から隠す。
• ルーティング: パスやホスト名ごとに別のバックエンド (API サーバ・静的配信・管理画面など) へ振り分ける。

クライアントの本来の IP はバックエンドからは「プロキシの IP」に見えてしまうため、元の IP は X-Forwarded-For ヘッダなどで引き継ぎます。具体的な設定は nginxリバースプロキシ設定 を参照してください。

設定・実用例

nginx をリバースプロキシとして使い、HTTPS で受けてバックエンド (127.0.0.1:3000 のアプリ) へ転送する最小例です。SSL をここで終端し、バックエンドには平文で渡します。

server {
    listen 443 ssl;
    server_name www.example.com;

    # SSL 終端 (証明書はここで一括管理)
    ssl_certificate     /etc/nginx/ssl/example.crt;
    ssl_certificate_key /etc/nginx/ssl/example.key;

    location / {
        # バックエンドへ転送
        proxy_pass http://127.0.0.1:3000;

        # クライアントの本来の情報を引き継ぐ
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Apache の場合は mod_proxy を用い、同様の転送を ProxyPass で記述します。

# Apache (mod_proxy / mod_proxy_http)
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/example.crt
    SSLCertificateKeyFile /etc/ssl/example.key

    ProxyPreserveHost On
    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

主な用途

• SSL 終端の集約: 証明書管理と暗号処理を 1 か所にまとめ、バックエンドを単純化する。
• 負荷分散: 複数のアプリサーバへ要求を分散し、スケールアウトと可用性を確保する。
• バックエンド隠蔽: 内部サーバの IP・構成・台数を外部から隠し、攻撃面を減らす。
• キャッシュ・圧縮: 静的応答をキャッシュし、gzip 圧縮などをまとめて行ってバックエンドを軽くする。
• パスベースルーティング: /api はアプリ、/static は静的配信、というように振り分ける。

主なリバースプロキシ実装の比較

実装	特徴	得意分野
nginx	軽量・高同時接続・設定が簡潔	静的配信 + リバプロ + L7 LB
Apache (mod_proxy)	機能豊富・モジュール拡張が容易	既存 Apache 資産との統合
HAProxy	高性能な L4/L7 ロードバランサ	大規模な負荷分散・TCP 中継
クラウド LB (ALB 等)	マネージドで自動スケール	クラウド上のスケーラブル構成

注意点

• クライアント IP の引き継ぎ漏れ: X-Forwarded-For を設定しないと、バックエンドのアクセスログがすべてプロキシの IP になる。アプリ側も信頼するヘッダを正しく設定する必要がある。
• 単一障害点: 全要求が通る要のため、リバースプロキシ自体を冗長化しないと全体が止まる。
• X-Forwarded-For の偽装: 外部から直接届く環境では X-Forwarded-For をクライアントが詐称できる。信頼できるプロキシの値だけ採用する設計にする。
• SSL 終端後の内部通信: プロキシ〜バックエンド間が平文だと、内部ネットワークを盗聴されると危険。ゾーンによっては内部も TLS 化する。
• タイムアウトとバッファ: 長時間処理やストリーミングでは proxy_read_timeout やバッファ設定を調整しないと途切れる。

関連リンク

• 負荷分散・プロキシ・CDN
• フォワードプロキシ
• nginxリバースプロキシ設定
• ロードバランサ
• HTTPS
• Apache HTTP Server