ひとことで言うと
リバースプロキシは、利用者の前に立つ受付としてアクセスを受け取り、裏側のサーバーへ安全に取り次ぐ仕組みです。
たとえ話でもう少し詳しく
リバースプロキシは、オフィスの総合受付みたいな存在です。
- 来客はまず受付に行く
- 受付が要件を聞いて、営業・経理・サポートなど適切な部署へ案内する
- 来客からは「受付」しか見えない
Webでも同じで、利用者はリバースプロキシにアクセスします。 その後ろで、用途に応じて複数のアプリやサーバーへ振り分けます。
この構成だと、裏側サーバーを直接公開せずにすむため、構成変更や保守もしやすくなります。
よく出る場面・使いどころ
- 複数アプリを1つのドメイン配下で公開するとき
- HTTPS終端をまとめて証明書管理を簡単にしたいとき
- 裏側サーバーのIPや構成を外部に見せたくないとき
- メンテナンス時に一部だけ切り替えたいとき
実務で気にするポイント
- 転送ルールをシンプルに保つ
- パスやホストの条件が増えすぎると保守が難しくなる
- 元のクライアント情報を引き継ぐ
- ログ解析や制限で必要なヘッダー設定を忘れない
- タイムアウトとヘルスチェックを設計する
- 裏側が遅いときの挙動を先に決めておく
- ヘルスチェック の条件を決めて、不調な宛先へ流し続けないようにする
- 障害時の切り分け手順を用意する
- 受付側の問題か、裏側アプリの問題かを素早く分ける
注意: リバースプロキシは取り次ぎ役。アプリのバグやDB性能問題を直接解決する道具ではありません。