「リバースプロキシを入れるメリットを説明できますか？」と面接で聞かれて、「えっと、負荷分散…」で止まってしまう。現場でも nginx の設定ファイルに proxy_pass と書いてあるのに、なぜサーバーの前にもう1台いるのか分からない。プロキシとリバースプロキシは名前が似ているので、どちらがどちらかも混ざりやすいところです。
この記事では、まず「誰の代わりに、どちら向きの通信を受けるか」で2つを分けます。次に、リバースプロキシを前に置くと何ができるか、逆に何が増えるかを並べ、nginx と Apache の短い設定例、AWS で同じ役をするサービスとの対応までつなげます。最後に、面接で30秒で答える形にまとめます。
この記事の結論
- プロキシとは、誰かの代わりに通信を受けて、代わりに相手へ送り直す中継役のサーバーです。
- フォワードプロキシは利用者の側に立ち、社内から外へ出る通信の出口になります。
- リバースプロキシはサーバーの側に立ち、外から入ってくる通信の入口になります。
- リバースプロキシを置くと、TLS の終端・振り分け・キャッシュ・入口の集約を1か所で持てます。
- その代わり、止まる場所が1つ増え、送信元 IP の受け渡しなどの設定が要ります。メリットは構成次第です。
プロキシとは何か？ 誰の代わりに立つかで2つに分かれる
プロキシ（proxy）は英語で「代理」です。通信の世界では、誰かの代わりに通信を受け取り、代わりに相手へ送り直す中継役のサーバーを指します。
たとえるなら「代理人」と「受付」
会社にたとえると分かりやすくなります。
- 代理人: 社員が外の会社に何かを頼むとき、直接行かずに総務の代理人に頼む。代理人が社員の代わりに外へ出向き、結果を持ち帰る。外の会社から見えるのは代理人だけです。
- 受付: 外から来たお客さんは、まず受付に用件を伝える。受付が社内の担当者に取り次ぎ、返事をお客さんに返す。お客さんから見えるのは受付だけで、社内の誰が対応したかは分かりません。
代理人にあたるのがフォワードプロキシ、受付にあたるのがリバースプロキシです。
正確な用語に戻すと
Apache HTTP Server の公式ドキュメント（mod_proxy）は、2つを次のように説明しています。フォワードプロキシは、利用者（クライアント）と目的のサーバー（オリジンサーバー）の間に立つ中間のサーバーで、利用者は「このサーバーの中身が欲しい」とプロキシに頼み、プロキシが代わりに取ってきて返します。利用者の側で、使うように設定しておく必要があります。 典型的な用途は、ファイアウォールで外に出られない社内の端末にインターネットへの出口を用意することです。
一方のリバースプロキシ（ゲートウェイとも呼ばれます）は、利用者からは普通の Web サーバーに見えます。利用者は特別な設定をせず、いつもどおり URL にアクセスするだけです。受け取ったリバースプロキシが、後ろにいる本当のサーバーに取り次ぎます。
| 観点 | フォワードプロキシ | リバースプロキシ |
|---|---|---|
| 誰の代わりか | 利用者（クライアント）の代わり | サーバーの代わり |
| 置く場所 | 利用者の側（社内ネットワークの出口） | サーバーの側（サービスの入口） |
| 受ける通信の向き | 内から外へ出ていく通信 | 外から入ってくる通信 |
| 利用者の設定 | 要る（ブラウザや OS に代理先を書く） | 要らない（普通のサイトに見える） |
| 主な用途 | 閲覧の制限・記録・外向きのキャッシュ | TLS の終端・振り分け・キャッシュ・入口の集約 |
| 隠れるもの | 外から見て、どの社員がアクセスしたか | 利用者から見て、後ろにどんなサーバーがあるか |
違いは「誰の代わりに、どちら向きの通信を受けるか」の1点で、ソフトウェアの種類ではありません。nginx も Apache も、設定次第でどちらの役にもなれます。
WHO IT WORKS FOR誰の代わりか
フォワードは利用者の代理、リバースはサーバーの代理
フォワードプロキシ
内から外へ出る通信の出口
- 利用者の側に置く社内 → インターネット
- 利用者が設定して使うブラウザや OS に代理先を書く
- 外向きの通信を絞る閲覧の制限・記録・キャッシュ
リバースプロキシ
外から入る通信の入口
- サーバーの側に置くインターネット → 自社のサーバー
- 利用者は意識しない普通の Web サイトに見える
- 内向きの通信を捌く暗号化の終端・振り分け・キャッシュ
CHECK 1ここまでの確認
フォワードプロキシとリバースプロキシを分ける一番の軸はどれ?
答えと解説
答え: 2. 誰の代わりに立ち、どちら向きの通信を受けるか
同じ nginx や Apache がどちらにもなれます。利用者の側で外向きの通信を代わりに出すのがフォワード、サーバーの側で外からの通信を代わりに受けるのがリバースです。「プロキシとは何か」の章を読み直してください。
リバースプロキシを前に置くと何ができるのか？
リバースプロキシの価値は、入口を1つに絞れることにあります。利用者が話す相手は前の1台だけになるので、入口でやりたいことをそこに集められます。HTTP と HTTPS の流れ（名前を引き、つなぎ、中身をもらう）は前提の記事で見たとおりで、リバースプロキシはその「つなぐ相手」の位置に立ちます。
READ ALSO — 未経験向け・段1 入口
HTTP と HTTPS の仕組み｜ブラウザが1ページを開くまでに何が起きているか
ONE FRONT DOOR入口を1つに絞る
利用者が話すのは前の1台だけ。後ろは見えない
-
利用者
https://example.com に接続
-
リバースプロキシ
TLS を解き、パスを見る
-
アプリサーバー
空いている1台が処理
-
返事
プロキシ経由で利用者へ
1. TLS の終端
HTTPS の暗号を解く処理（TLS の終端）を、前の1台に寄せられます。証明書を置く場所と更新する場所が1か所になり、後ろのアプリサーバーは暗号の処理から離れて本来の仕事に集中できます。プロキシと後ろの間を暗号化し直すかどうかは、社内の要件で決めます。
2. 負荷分散と振り分け
後ろに同じアプリを複数台並べ、通信を順番に配れます（負荷分散）。nginx の公式ドキュメントでは、後ろのサーバーが複数あるとき、既定では重み付きのラウンドロビン（順番に回す方式）で配ると説明されています。さらに、URL のパス（/api/ はこちら、/images/ はあちら）やホスト名（shop.example.com と blog.example.com）を見て、行き先を変えることもできます。
3. キャッシュと圧縮、静的ファイルの配信
一度返した応答を手元に取っておき、同じ要求には後ろに聞かずに返せます（キャッシュ）。応答を圧縮して転送量を減らしたり、画像や CSS のような変わらないファイルをプロキシが直接返したりすることで、アプリサーバーの負担を軽くできます。
4. 後ろのサーバーを外に見せない
外から見えるのはプロキシだけなので、アプリサーバーはインターネットから直接つながらない場所に置けます。入口が1つなら、守る場所も見張る場所も1つです。
5. アクセス制御とレート制限の置き場所
特定の IP アドレスだけを通す、短い時間に大量の要求を送ってくる相手を絞る（レート制限）といった「入口での判断」を、アプリに手を入れずに置けます。
6. アプリを止めずに入れ替える
後ろのサーバーを1台ずつ振り分け先から外し、更新して戻す、という入れ替えができます。利用者から見える入口は変わらないので、後ろで何が起きていても URL はそのままです。
CHECK 2ここまでの確認
リバースプロキシで TLS を終端すると、何が楽になる?
答えと解説
答え: 1. 証明書の置き場所と更新を前の1台にまとめられる
暗号を解く役を入口に寄せるので、証明書を後ろのサーバー1台ずつに置かずに済みます。暗号化が要らなくなるわけではありません。「前に置くと何ができるのか」の章に戻ってください。
nginx と Apache ではどう書くのか？
長い手順は公式ドキュメントに任せて、ここでは「どのディレクティブ（設定の命令）が何の役か」だけ見ます。
nginx: upstream と proxy_pass
# 後ろのアプリサーバーの組（ngx_http_upstream_module）
upstream app_servers {
server 10.0.1.11:8080;
server 10.0.1.12:8080;
}
server {
listen 80;
server_name example.com;
location / {
# 受けた要求を組に渡す（ngx_http_proxy_module）
proxy_pass http://app_servers;
# 後ろに伝えたい情報をヘッダーで付ける
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
upstreamは後ろのサーバーの組に名前を付けるもの、proxy_passは「この場所に来た要求をどこへ渡すか」です。proxy_set_headerは後ろへ渡すヘッダーを決めます。公式ドキュメントでは、何も書かないとHostはproxy_passに書いた側の名前（$proxy_host）に置き換わるとされています。元のホスト名をアプリで使うならHost $hostを明示します。$proxy_add_x_forwarded_forは、届いたX-Forwarded-Forに接続元のアドレス（$remote_addr）をカンマ区切りで足した値です。
HTTPS で受けるなら、ここに証明書の設定（ngx_http_ssl_module）を足します。この部分は公式ドキュメントで確認してください。
Apache: ProxyPass と ProxyPassReverse
# mod_proxy と mod_proxy_http を読み込んでおく
ProxyRequests Off
ProxyPass "/app/" "http://10.0.1.11:8080/"
ProxyPassReverse "/app/" "http://10.0.1.11:8080/"
ProxyPassは「/app/に来た要求を後ろのサーバーに渡す」という対応付けです。複数台に配るなら mod_proxy_balancer の組（Balancer group）を行き先にします。ProxyPassReverseは、後ろのサーバーが返したリダイレクト（Location:ヘッダー）の行き先を、後ろのアドレスではなくプロキシのアドレスに書き換えます。これが無いと、利用者が後ろのサーバーの住所へ飛ばされてしまいます。ProxyRequestsはフォワードプロキシの機能を有効にする設定です。公式ドキュメントは、誰でも使える状態のプロキシ（オープンプロキシ）は危険だとして、リバースプロキシとして使うときは通常オフにするよう書いています。- Apache はリバースプロキシとして取り次ぐとき、
X-Forwarded-For・X-Forwarded-Host・X-Forwarded-Serverを後ろへ付けて渡します。
| 役割 | nginx | Apache（mod_proxy） |
|---|---|---|
| 後ろへ渡す | proxy_pass |
ProxyPass |
| 後ろの組を決める | upstream |
Balancer group（mod_proxy_balancer） |
| 後ろへ渡すヘッダー | proxy_set_header で明示 |
X-Forwarded-* を自動で付ける |
| リダイレクト先の書き換え | proxy_redirect |
ProxyPassReverse |
置くことで増えるものは何か？ デメリットになる場面
リバースプロキシは「置けば得をする部品」ではありません。1段増やすことで増えるものがあり、構成によってはそちらが大きくなります。
TRADE-OFF1段増やす損得
できることが増える分、止まる場所も1つ増える
置いて得るもの
- TLS の終端を1か所に
- 振り分けと負荷分散
- キャッシュ・圧縮
- 後ろを外に見せない
増えるもの
- 単一障害点（冗長化が要る）
- 1段分の遅延と設定
- 送信元 IP の受け渡し
支点は構成（台数・規模・要件）
単一障害点になる
入口を1つに絞るということは、その1台が止まればサービス全体が止まるということです。リバースプロキシを1台だけ置くと、後ろを何台に増やしても入口が単一障害点になります。本番ではプロキシ自体を複数台にし、その前で切り替える仕組みが要ります。
1段分の遅延と設定の複雑さ
通信が1回多く中継されるので、その分の時間がかかります。設定ファイルも1つ増え、障害のときに「プロキシで止まったのか、後ろで止まったのか」を切り分ける手間が増えます。ログも2か所を見比べることになります。
送信元 IP が後ろに見えなくなる
後ろのアプリサーバーから見ると、接続してくる相手はいつもプロキシです。何もしなければ、アプリのログに残る送信元はプロキシのアドレスばかりになります。そこで、元の利用者のアドレスをヘッダーで伝えます。
- 慣習として広く使われてきたのが
X-Forwarded-For（元の送信元）、X-Forwarded-Proto（利用者が HTTP と HTTPS のどちらで来たか）などのX-Forwarded-*です。 - これを1つにまとめて標準化したのが RFC 7239 の
Forwardedヘッダーで、for（送信元）・by（受けたプロキシ）・host（元の Host）・proto（元のプロトコル）を1行で表せます。
注意したいのは、これらのヘッダーは利用者が自分で書き足せることです。AWS の ALB のドキュメントも、X-Forwarded-For の値は安全に管理された自分たちの仕組みが足したものだけを信用するよう注意しています。アプリ側では「どのプロキシが足した値までを信じるか」を決めておきます。
キャッシュの事故
キャッシュは効くと速い反面、返してはいけないものまで返す事故を起こします。ログインした人ごとに中身が変わるページを共有のキャッシュに載せると、別の人の画面が他人に見えてしまうことがあります。キャッシュしてよい応答を絞り、個人ごとのページは載せない設定から始めます。
リバースプロキシで起きやすい事故
- プロキシを1台だけにして、入口ごと止まる
- 送信元 IP を伝えず、アプリのログやアクセス制限がプロキシのアドレスで判断される
- 利用者が書いた
X-Forwarded-Forをそのまま信じて、送信元を偽られる - ログインした人ごとのページを共有のキャッシュに載せ、他人の画面が見える
CHECK 3ここまでの確認
リバースプロキシを入れたあと、アプリのログに残る送信元 IP がどれもプロキシのアドレスになった。まず見直すのはどこ?
答えと解説
答え: 3. 送信元を伝えるヘッダー（X-Forwarded-For など）の付け方と読み方
後ろのサーバーから見ると、接続してくる相手はプロキシです。元の利用者のアドレスはヘッダーで渡し、アプリ側で読む必要があります。「置くことで増えるもの」の章を読み直してください。
AWS では何がリバースプロキシの役をするのか？
AWS では、自分で nginx を立てなくても、同じ役を受け持つマネージドなサービスがあります。構成図で「前に置いてあるもの」を読むときの対応として覚えておくと便利です。
| リバースプロキシの役割 | AWS で受け持つ主なサービス |
|---|---|
| 振り分け（パス・ホスト名）と負荷分散 | ALB（Application Load Balancer。Elastic Load Balancing の1種類） |
| TLS の終端 | ALB の HTTPS リスナー、CloudFront |
| キャッシュと静的ファイルの配信 | Amazon CloudFront |
| 後ろを外に見せない・入口を1つに絞る | ALB や CloudFront を入口にし、後ろを直接公開しない |
ALB は、URL のパスやホスト名を見て行き先を変えられ、元の送信元を X-Forwarded-For、利用者が使ったプロトコルを X-Forwarded-Proto に入れて後ろへ渡します。nginx で proxy_set_header を書いていた部分を、AWS 側が受け持つ形です。
READ ALSO — 学習中向け・段2 構成
Elastic Load Balancing とは何か｜ALB・NLB・GWLB の違いとヘルスチェック、複数 AZ
CloudFront は、世界各地の拠点（エッジ）で応答をキャッシュし、オリジン（元のサーバー）の前に立ちます。キャッシュを主役にしたリバースプロキシと捉えると、ALB との違いが整理しやすくなります。
READ ALSO — 学習中向け・段2 構成
Amazon CloudFront とは何か｜エッジ・オリジン・キャッシュ・OAC の関係を1本で
混同しやすい: NAT ゲートウェイはプロキシではない
VPC の構成図には、プライベートサブネットから外へ出る道として NAT ゲートウェイがよく出てきます。「中の端末の代わりに外へ出る」という点がフォワードプロキシに似ていますが、別物です。NAT ゲートウェイは、プライベートサブネットのインスタンスが VPC の外へ接続できるように送信元のアドレスを付け替える仕組みで、外から中へ接続を始めることはできません。HTTP の中身を読んで振り分けたりキャッシュしたりはしません。アドレスを付け替えるのが NAT、通信を受け取って代わりに送り直すのがプロキシと分けておくと混ざりません。
面接で「メリットは？」と聞かれたらどう答えるか？
最後に、ここまでの話を30秒に縮めます。ポイントは、先に「何者か」を一言で言い、次にメリットを2〜3個、最後に「代わりに増えるもの」を添えることです。メリットだけを並べるより、損得の両方を言えるほうが、仕組みを分かっている答えになります。
30秒の答え方
- リバースプロキシは、サーバーの前に立って外からの通信を代わりに受け、後ろのサーバーに取り次ぐ入口です。
- 入口を1つに絞れるので、TLS の終端・複数台への振り分け・キャッシュ・アクセス制限をアプリの外の1か所で持てます。後ろのサーバーを外に見せずに済みます。
- 代わりに、そこが単一障害点になるので冗長化が要り、送信元 IP をヘッダーで伝えるといった設定も増えます。
- どこまで得になるかは構成次第で、AWS なら ALB や CloudFront がマネージドな形で同じ役を担います。
「フォワードプロキシとの違いは？」と重ねて聞かれたら、「フォワードは利用者の側に立って外へ出る通信の出口、リバースはサーバーの側に立って入ってくる通信の入口です」と、向きで答えれば十分です。次は、AWS でこの役を担う ALB（Elastic Load Balancing）と CloudFront を、それぞれの記事で確かめてください。
参照ソース
- Module ngx_http_proxy_module（nginx 公式ドキュメント） —
proxy_pass・proxy_set_headerの働き、Hostの既定値（$proxy_host）、$proxy_add_x_forwarded_forの中身の根拠（2026-09-29 時点の記載） - Module ngx_http_upstream_module（nginx 公式ドキュメント） —
upstreamの組と、既定の配り方が重み付きラウンドロビンであることの根拠（2026-09-29 時点の記載） - mod_proxy（Apache HTTP Server 2.4 公式ドキュメント） — フォワードプロキシとリバースプロキシ（ゲートウェイ）の定義、
ProxyPass・ProxyPassReverse・ProxyRequestsの役割、オープンプロキシの危険、X-Forwarded-*の付与の根拠（2.4 系、2026-09-29 時点の記載） - RFC 7239: Forwarded HTTP Extension（IETF） —
Forwardedヘッダーとfor・by・host・protoの意味の根拠（2014年6月発行） - HTTP headers and Application Load Balancers（AWS 公式ドキュメント） — ALB が
X-Forwarded-For・X-Forwarded-Protoを付けて渡すこと、X-Forwarded-Forを信用するときの注意の根拠（2026-09-29 時点の記載） - Listener rules for your Application Load Balancer（AWS 公式ドキュメント） — ALB がリスナーのルールでホスト名（host-header）やパス（path-pattern）を条件に振り分けることの根拠（2026-09-29 時点の記載）
- What is Amazon CloudFront?（AWS 公式ドキュメント） — CloudFront がエッジでキャッシュし、オリジンの前に立つことの根拠（2026-09-29 時点の記載）
- NAT gateways（Amazon VPC 公式ドキュメント） — NAT ゲートウェイがプライベートサブネットから外への接続のためにアドレスを付け替え、外からの接続は受けないことの根拠（2026-09-29 時点の記載）
