
結論:リバースプロキシは「サーバーの手前の受付係」
リバースプロキシとは、インターネットからのアクセスを、本来のサーバーの代わりに受け付け、適切なサーバーへ取り次ぐ仕組みです。利用者から見ると、取り次ぎ役が本体のように見えるため、奥にあるサーバーの存在を意識することはありません。
役割をひとことでまとめると、次の4つです。
- アクセスを複数のサーバーへ振り分ける(負荷分散)
- よく使われる内容を手元に持って、素早く返す(キャッシュ)
- 暗号化(HTTPS)の処理をまとめて引き受ける
- 奥のサーバーを外部から隠し、攻撃から守る
もう少し詳しく:リバースプロキシは何をしているのか
リバースプロキシとは、利用者からのアクセスを直接、目的のサーバーに届けるのではなく、間に入って代わりに取り次ぐ役割を持つ、サーバー(またはその仕組み)のことです。利用者からは、まるでその取り次ぎ役自身が本体であるかのように見える点が特徴です。
「プロキシ」と「リバース」プロキシの違い
似た言葉に「プロキシ(順プロキシ)」がありますが、役割の向きが逆になります。
- プロキシ(順プロキシ):利用者側に置かれ、利用者の代わりに外部のサーバーへアクセスを取り次ぐ仕組み
- リバースプロキシ:サーバー側に置かれ、外部からのアクセスを、サーバーの代わりに受け付けて取り次ぐ仕組み
「誰の代わりに動いているか」の向きが逆であることから、「リバース(逆)」プロキシと呼ばれています。

会社の受付係だと考えると分かりやすい

リバースプロキシの役割は、オフィスの受付係に例えるとイメージしやすくなります。来訪者(利用者)は、直接それぞれの担当部署(奥にある本来のサーバー)に押しかけるのではなく、まず受付(リバースプロキシ)で用件を伝えます。受付は、内容に応じて適切な部署へ取り次いだり、あるいは受付だけで対応できる簡単な用件(よくある質問など)は、その場で回答して済ませたりします。
リバースプロキシが担う主な役割
| 役割 |
内容 |
| 負荷分散 |
複数あるサーバーへ、アクセスを均等に振り分ける |
| キャッシュ |
よくアクセスされる内容を手元に保存し、奥のサーバーへの負荷を減らす |
| セキュリティ |
奥にある本来のサーバーの情報を外部から隠し、直接の攻撃対象にされにくくする |
| 通信の暗号化処理 |
暗号化(HTTPS)に関する処理をまとめて引き受け、奥のサーバーの負担を減らす |
なぜ本体のサーバーを直接公開しないのか
本来のサーバーを直接インターネットにさらしてしまうと、そのサーバーの構成や弱点が外部から把握されやすくなり、攻撃の標的にされるリスクが高まります。リバースプロキシを間に挟むことで、外部からは取り次ぎ役だけが見える状態にし、本来のサーバーを安全な場所に隠しておくことができます。
具体的にどんなソフトが使われているのか
リバースプロキシは概念だけの話ではなく、実際に動かすための専用ソフトウェアがあります。代表的なのが「Nginx(エンジンエックス)」や「Apache」で、多くのWebサービスがこれらをリバースプロキシとして本来のサーバーの手前に配置しています。クラウド事業者が提供するロードバランサーサービスも、内部的には同じ「取り次ぎ役」の発想で動いていることが多く、クラウドとは何かの記事で触れた「見えない場所にある会社のコンピューター」の中で、こうした取り次ぎの仕組みが常に働いています。
DNSとの関係
利用者がブラウザにアドレスを入力してからサイトが表示されるまでの間には、住所を調べる「DNS」という仕組みも関わっています。DNSが「どのサーバーに向かえばよいか」という道案内を担い、リバースプロキシが「実際に来た人をどう振り分けるか」という受付の役割を担う、という関係にあります。DNSの仕組みについては別の記事で解説していますので、あわせて読むとアクセスの流れ全体がつながって理解できます。
HTTPS化との関わり
ブラウザのアドレスバーに表示される鍵マークでおなじみの「SSL/TLS」による暗号化も、リバースプロキシがまとめて引き受けているケースが多くあります。奥にある本来のサーバーが1台1台で暗号化の処理を行うのではなく、手前のリバースプロキシが窓口として暗号化・復号をまとめて担当することで、奥のサーバー側の負荷を減らせるという利点があります。SSL/TLSそのものの仕組みはこちらの記事で解説しています。
攻撃から本体を守る「盾」としての役割
近年増えている、大量のアクセスを送りつけてサーバーをダウンさせる攻撃に対しても、リバースプロキシは有効な盾になります。異常なアクセスパターンを手前の段階で検知し、本来のサーバーに到達する前に遮断することで、被害を最小限に抑えられます。また、特定のサービスが不調になった際に、その影響を全体に広げないための「サーキットブレーカー」という設計思想と組み合わせて使われることも多く、両者は縁の下でシステムの安定稼働を支える、似た役割を持つ技術と言えます。詳しくはサーキットブレーカーパターンの記事をご覧ください。
設定のイメージ:Nginxの例
実際のリバースプロキシは、Nginxなどのソフトウェアに、「どこから来たアクセスを、どこへ取り次ぐか」を設定して動かします。次は、「example.comへのアクセスを、同じマシンの3000番ポートで動いているアプリへ取り次ぐ」ごく基本的な設定の例です。
server {
listen 80;
server_name example.com;
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;
}
}
proxy_pass が「取り次ぎ先」の指定で、proxy_set_header の行は、元のアクセス元の情報(アクセスしてきたIPアドレスなど)を、奥のアプリに伝えるためのものです。取り次ぎをすると、奥のアプリから見たアクセス元は、そのままではリバースプロキシになってしまうため、こうした情報を渡す設定が重要になります。
複数のサーバーへ振り分けたい場合は、取り次ぎ先をまとめて書きます。
upstream app_servers {
server 10.0.0.11:3000;
server 10.0.0.12:3000;
}
server {
listen 80;
location / {
proxy_pass http://app_servers;
}
}
実際に公開する環境では、HTTPS化やセキュリティ設定が必要になります。設定を変更する前には、必ず元の設定ファイルのバックアップを取り、公式ドキュメントで最新の書き方を確認してください。
似た仕組みとの違い
| 仕組み |
主な役割 |
リバースプロキシとの違い |
| ロードバランサー |
アクセスを複数のサーバーへ振り分ける |
振り分けに特化。リバースプロキシが兼ねる場合もある |
| CDN |
世界各地の拠点から、コンテンツを近くへ届ける |
配信の分散が中心。仕組みはCDNとはで解説 |
| WAF |
Webアプリへの不正な通信を検知・遮断する |
防御に特化。リバースプロキシの位置に置かれることが多い |
| 順プロキシ |
利用者側から、外部へのアクセスを代行する |
向きが逆。社内ネットワークなどで使われる |
502・504エラーとリバースプロキシ
リバースプロキシを使っているサイトで、「502 Bad Gateway」や「504 Gateway Timeout」が表示されることがあります。これは、取り次ぎ役は動いているのに、奥のサーバーから正しい返事が来ない状態で、次のような原因が考えられます。
- 奥のアプリが停止している、または起動に失敗している
- 取り次ぎ先の指定(アドレスやポート番号)が間違っている
- 奥のアプリの処理に時間がかかり、待ち時間の上限を超えた
運営者は、まず奥のアプリが動いているか、取り次ぎ先の設定が正しいかを確認します。ステータスコードの全体像は、HTTPステータスコードの解説にまとめています。
縁の下でシステムを支えている技術
リバースプロキシは、利用者と本来のサーバーの間に立ち、アクセスの取り次ぎ・負荷分散・セキュリティ強化といった、縁の下の役割を担う仕組みです。普段は意識されることのない存在ですが、多くのWebサービスの安定稼働を、裏側で静かに支えています。
関連記事:ストラングラーパターンとは
関連記事:ロードバランサーとは/プロキシサーバーとは
関連記事:L4ロードバランサーとL7ロードバランサーの違い