リバースプロキシとは｜ネットミリしら

リバースプロキシとは

リバースプロキシは、利用者からの要求を受け、内側のWebサーバーへ転送して応答を返す中継サーバーです。英語ではreverse proxy（リバース・プロキシ）と表します。

RFC 9110ではゲートウェイと逆プロキシを同じ役割の呼称として扱います。利用者からは公開サーバーに見えますが、内側では複数のバックエンドへ要求を振り分けられます。

一つの通信を素通しにするのではありません。利用者との接続を受け終え、別の接続をバックエンドへ作る二段構成です。

Client → Proxy公開接続を受ける

パブリックIP、TLS証明書、HTTPバージョン、クライアントタイムアウト、要求大きさなど外部向け条件を扱う。

Proxy decision転送先と規則を選ぶ

ホスト、パス、方式、ヘッダー、Cookieなどを見てバックエンドプール、キャッシュ、拒否、リダイレクトを決める。

Proxy → Backend内側へ新しく接続する

別のプロトコル・ポート・TLS・タイムアウトを使える。必要な情報だけヘッダーで引き渡す。

インターネット向け証明書を逆プロキシへ置き、HTTPSを復号して検査する構成をTLS termination（TLSターミネーション）と呼びます。バックエンド側もTLSにして再暗号化すれば、内側ネットワークでの盗聴や成り済ましを抑えられます。

ホスト名やURLパスにより、サイト、API、管理画面、画像配信を別バックエンドへ送れます。書換え後のパスと問い合わせがバックエンドの想定どおりかを試験します。

複数バックエンドへラウンドロビン、接続数、重み、ハッシュなどで分配できます。ヘルスチェックで異常ノードを候補から外します。ただしアプリケーションがローカルメモリーへセッションを持つ場合は、どのノードでも同じ状態を扱える設計か、固定割当が必要です。

逆プロキシは一台だけなら新しい単一障害点になります。複数化、設定配布、証明書更新、監視を含めて入口全体を設計します。

バックエンドから見える接続元はプロキシになるため、元のクライアント情報をForwardedやX-Forwarded-For、元のスキームをX-Forwarded-Protoなどで渡します。

クライアント自身も同名ヘッダーを送れます。公開入口で既存値を削除・正規化し、信頼するプロキシが追加した範囲だけをバックエンドが使います。そうしないとIP制限、HTTPS判定、URL生成、監査ログを偽装されます。

接続、ヘッダー待ち、本文送信、バックエンド応答、アイドルのタイムアウトを分けます。短すぎれば正常なアップロードや長い処理が切れ、長すぎれば遅い接続がリソースを占有します。要求本文と応答本文の上限も設定します。

bufferingは遅いクライアントからバックエンドを守る一方、ストリーミングやserver-sentイベントでは遅延になります。大容量ファイルはプロキシがディスクへ一時保存するか、バックエンドから直接配信するかを決めます。

バックエンドが接続直後に失敗したとき、別ノードへ再試行すると可用性を高められます。しかし送信済みの注文や決済を再試行すると、最初の処理が成功していた場合に二重実行されます。

GETなど安全な方式を中心にし、状態変更は冪等性鍵、アプリケーション側の重複防止、どの段階まで送ったかを考慮します。

WebSocketはHTTPからアップグレードした後、長時間の双方向接続になります。アップグレードヘッダー、アイドルタイムアウト、バックエンドへの固定、接続数上限を別に調整します。HTTP/2やHTTP/3を外側で受け、内側はHTTP/1.1にする構成もあります。

バックエンドのアドレスが利用者から見えにくくなっても、バックエンドポートがインターネットから直接到達できれば逆プロキシの認証や制限を迂回されます。ファイアウォールやプライベートネットワークで、プロキシからだけ接続可能にします。

逆プロキシを調べるときは、公開側の要求、プロキシが変えた内容、バックエンドへ渡った要求、戻り応答の四点を一つの要求IDで追います。