とことこロゴス
リバースプロキシ
サービスを提供するサーバの代理として外部からの要求を受け付け、処理先へ中継して応答を返すプロキシである。負荷分散やTLSの終端、キャッシュなどの役割も担える。
イマシルちゃんの解説
リバースプロキシは、Webサービスへの要求を代理で受け付けるサーバだよ。
ブラウザから届いた要求を、実際に処理する背後のサーバへ中継するんだ。
戻ってきた応答もリバースプロキシを通してブラウザへ返すから、利用者は奥の機器を意識せずにアクセスできるよ。
たとえば複数の処理先へ要求を振り分ければ、アクセスの集中にも対応しやすくなるんだ。
さらに通信経路を制限すれば、外部から奥の機器へ直接接続させずにサービスを公開できるよ。
この解説はわかりやすかったですか？
より深い解説
定義
リバースプロキシは、外部のクライアントからの要求を、内部のWebサーバなどの代わりに受け付け、適切な内部のサーバに転送し、その応答をクライアントに返すサーバである。クライアントから見ると、リバースプロキシがサーバそのものに見える。通常はDMZに置く。
主な役割
| 役割 | 内容 |
|---|---|
| 内部のサーバの保護 | 内部のサーバのアドレスを外部に見せず、外部からの直接の接続を受けない。ファイアウォールでは、インターネットからはリバースプロキシへの通信だけを許可し、内部のサーバへはリバースプロキシからの通信だけを許可する |
| 負荷分散 | 複数のサーバに要求を振り分ける（ロードバランサの役割） |
| TLSの終端 | HTTPSの暗号化・復号をまとめて行い、内部のサーバの負荷を減らす。証明書の管理も一か所で済む |
| 認証 | 内部のサーバに届く前に、利用者を認証する |
| キャッシュ・圧縮 | 静的なコンテンツを返し、応答を速くする |
| WAF | 不正な要求（SQLインジェクションなど）を検査して遮断する |
使われ方の例
| 例 | 内容 |
|---|---|
| 社外からの業務サーバの利用 | テレワーク中のPCが、DMZのリバースプロキシを経由して、社内の業務サーバに接続する。リバースプロキシで利用者を認証する |
| Webサービスの公開 | 複数のアプリケーションサーバを、1つのドメイン名の後ろにまとめる |
| CDN | 世界中に置いた、リバースプロキシのような働きをするキャッシュサーバ |
一台のHTTPサーバで、静的な画像やHTMLは自身のファイルから配信し、動的な処理は背後のアプリケーションサーバへ中継する構成もある。後者の中継がリバースプロキシの働きであり、すべてのコンテンツを別サーバから取り寄せる必要はない。
同じ接続先で複数のサイトを扱う
複数のドメイン名を同じリバースプロキシのIPアドレスへ対応付けても、要求されたサイト名に応じて別の内部サーバへ転送できる。HTTP/1.1ではHostヘッダー、HTTP/2では:authorityという疑似ヘッダーフィールドが、要求先のホスト名を示す。
例えばshop.example.netとhelp.example.netを同じアドレスへ向け、前者を販売用サーバ、後者を案内用サーバへ中継する。URLのパスを条件にして転送先を分ける構成もある。これはアプリケーション層の情報に基づく振り分けである。
HTTPSでこれらのフィールドを読むには、通常はリバースプロキシでTLSを終端する。端末との暗号化を終端した後、内部へ平文HTTPで送るか、再びTLSで暗号化するかは別に設計する。TLSのSNIで接続先名を選ぶ処理と、復号後にHTTPの内容で要求を振り分ける処理も区別する。
フォワードプロキシとの比較
| フォワードプロキシ | リバースプロキシ | |
|---|---|---|
| 誰の代理か | クライアントの代理 | サーバの代理 |
| 通信の向き | 内部 → 外部 | 外部 → 内部 |
| 端末の設定 | 必要（PACファイルなど） | 不要（DNSでリバースプロキシのアドレスを引かせる） |
同じソフトウェア（nginx、Apache HTTP Server、Squidなど）を、設定によってどちらとしても使えることが多い。フォワードプロキシとして使っていたサーバを、設定を変えてリバースプロキシとして使い直す場合は、ファイアウォールの許可ルールも、通信の向きに合わせて見直す必要がある。
直接接続を防ぐ効果と通信の保護
外部からはリバースプロキシだけに接続させ、背後のWebサーバへは直接到達できないようにすると、公開する接続先と許可する経路を限定できる。ただし、中継があるだけで通信路が暗号化されたり、すべての不正な要求が遮断されたりするわけではない。
盗聴や通信途中の改ざんにはTLSなどを用いる。アプリケーションの脆弱性を突く要求が中継される可能性もあるため、Webサーバ自体の修正や、必要に応じたWAFの検査も併用する。直接接続の防止と、コンテンツの改ざんを全面的に防ぐことは同義ではない。