リバースプロキシとは、利用者からのリクエストをWebサーバーの前で受け取り、内部のサーバーへ中継する仕組みです。
Webサイトにアクセスした利用者は、実際のアプリサーバーへ直接つながっているように見えます。しかし裏側では、リバースプロキシが入口でリクエストを受け、適切な内部サーバーへ渡していることがあります。
リバースプロキシは、Webサービスの入口に立つ受付です。利用者からは受付だけが見え、奥にある複数のサーバーを直接意識しません。
この記事では、リバースプロキシの意味、フォワードプロキシとの違い、Webサーバーの前に置く理由、502/504エラーを見るときの考え方を初心者向けに整理します。
リバースプロキシはWebサーバー前の受付
MDNでは、プロキシサーバーをネットワークの間に入る中間のプログラムやコンピューターとして説明し、その中でリバースプロキシはインターネットからのリクエストを受け取り、内部ネットワークのサーバーへ転送するものとして整理されています。
つまりリバースプロキシは、利用者と内部サーバーの間に立ちます。利用者は https://example.com へアクセスし、リバースプロキシはその裏側で app:8080 や api:9000 のような内部サーバーへ中継します。
次の図では、リバースプロキシをWebサービスの受付として見てください。ブラウザ、受付、内部サーバーの3者を分けると役割が理解しやすくなります。
フォワードプロキシとの違い
プロキシには、フォワードプロキシとリバースプロキシがあります。違いは、誰の代わりに動くかです。
フォワードプロキシは、利用者側の代理としてインターネットへアクセスします。たとえば社内PCが外部サイトを見るときに、社内プロキシを経由するような構成です。
一方、リバースプロキシはサーバー側の代理です。インターネット上の利用者から見える入口になり、奥にあるWebサーバーやアプリサーバーへリクエストを渡します。
次の図では、プロキシが利用者側にいるのか、Webサイト側にいるのかを見てください。ここを間違えなければ、用語の混乱はかなり減ります。
| 種類 | 誰の前に立つか | 主な目的 |
|---|---|---|
| フォワードプロキシ | 利用者側 | 社内から外部サイトへ出る通信を中継する |
| リバースプロキシ | サーバー側 | 外部から来るリクエストを内部サーバーへ中継する |
1つの入口から複数サーバーへ振り分ける
リバースプロキシは、1つのURLを入口にして、裏側の複数サーバーへリクエストを振り分けられます。たとえば /app はWeb画面、/api はAPIサーバー、/static は画像やCSSのサーバーへ送る、といった構成です。
NGINXのリバースプロキシ設定でも、受け取ったリクエストを別のサーバーへ渡すために proxy_pass のような設定を使います。これは、入口で受けて、奥の処理先へ渡す代表的な考え方です。
次の図では、利用者には1つのURLだけが見えていても、裏側ではリクエストの行き先が分かれている様子を見てください。
location /api/ {
proxy_pass http://api_server:9000;
}
location /app/ {
proxy_pass http://app_server:8080;
}リバースプロキシを前に置く理由
リバースプロキシは、単にリクエストを中継するだけではありません。Webサービスの入口に置くことで、HTTPSの処理、セキュリティ対策、キャッシュ、負荷分散、ログ集約などをまとめて扱いやすくなります。
Cloudflareの解説でも、リバースプロキシはWebサーバーの前に置かれ、クライアントからのリクエストを中継する存在として説明されています。CDNやWAFのような仕組みも、利用者とオリジンサーバーの間に立つという意味ではリバースプロキシ的に働きます。
次の図では、リバースプロキシを前に置く理由をアイコンで見てください。受付、警備、案内、記録係のような複数の役割を持つと考えると分かりやすいです。
502・504エラーを見るときの考え方
リバースプロキシを使う構成では、502 Bad Gatewayや504 Gateway Timeoutを見ることがあります。これは、利用者のブラウザとリバースプロキシの間だけでなく、リバースプロキシと内部サーバーの間も確認する必要があるという合図です。
502は、入口のプロキシが奥のサーバーから有効な応答を得られなかったときに出ることがあります。504は、奥のサーバーからの応答が遅すぎる、または返ってこないときに見ることがあります。
次の図では、どこで詰まっているかを分けて見てください。リバースプロキシは動いているが、奥のアプリサーバーが止まっている、というケースもあります。
実際の配置イメージ
実際のWebサービスでは、DNS、CDN、WAF、リバースプロキシ、アプリサーバー、DBが段階的につながることがあります。すべてのサービスがこの構成になるわけではありませんが、外部と内部の境界にリバースプロキシが置かれることはよくあります。
次の図では、利用者のリクエストが外側から内側へ進む流れを見てください。リバースプロキシは、アプリの手前で入口を整理する位置にあります。
リバースプロキシでよくある誤解
リバースプロキシは、Webサーバーそのものではありません。Webサーバーとして静的ファイルを返すこともありますが、用語としては、利用者からのリクエストを内部サーバーへ中継する入口の役割を指します。
また、リバースプロキシを置くだけで安全になるわけでもありません。公開範囲、転送先、ヘッダー、TLS証明書、タイムアウト、ログ、WAF設定などを正しく設計する必要があります。
さらに、ロードバランサーやCDNと役割が重なることもあります。実際の製品では、リバースプロキシ、ロードバランシング、キャッシュ、WAFが1つのサービスにまとまっていることもあります。
既存記事とあわせて読む順番
リバースプロキシは、HTTP、URL、DNS、Web API、CORSの理解とつながっています。先に通信の基本用語を押さえると、どこでリクエストが中継されるのかを追いやすくなります。
- HTTPとは？HTTPSとは？
- DNSとは何か？
- APIとは？APIとWeb APIの違い
- CORSとは？Access-Control-Allow-Originの意味
- Webhookとは？APIとの違い
公式情報と確認先
仕様や実装で確認する場合は、MDNのプロキシ解説、NGINXのReverse Proxyドキュメント、Cloudflareのリバースプロキシ解説を確認します。製品ごとに設定名や挙動は異なるため、実装時は使う製品の公式ドキュメントを見てください。
- MDN: Proxy server
- MDN: Proxy servers and tunneling
- NGINX Reverse Proxy
- Cloudflare: What is a reverse proxy?
まとめ
リバースプロキシとは、利用者からのリクエストをWebサーバーの前で受け取り、内部サーバーへ中継する仕組みです。
リバースプロキシを理解すると、Webサービスの入口、CDN、WAF、ロードバランサー、502/504エラーの見方がつながります。まずは「Webサーバーの前に置く受付」として押さえましょう。