IT用語集 2023/10/16

リバースプロキシとは？わかりやすく10分で解説

コラム

Webサービスを安定して運用するうえで、「サーバを守りつつ、表示も速くしたい」「アクセスが増えても落ちない構成にしたい」といった要件は避けて通れません。そこで登場するのがリバースプロキシです。リバースプロキシは“Webサーバの手前”で通信を受け止め、転送・制御・最適化を担うことで、可用性とセキュリティの両方に効く設計を取りやすくします。

本記事では、リバースプロキシの定義とフォワードプロキシとの違いを押さえたうえで、代表的な用途（負荷分散・キャッシュ・TLS終端・WAF連携など）と、導入時に誤解しやすい注意点（IP隠蔽の限界、DoS対策の前提、キャッシュの落とし穴）まで、運用目線で整理します。

リバースプロキシとは？

リバースプロキシについて解説します。Web上の多くの通信を仲介するこの仕組みの概念、設置場所、他の類似システムとの違い、一般的な用途を順に掘り下げます。

リバースプロキシのイメージ

リバースプロキシの定義

リバースプロキシは、インターネット側（クライアント）とWebサーバ側（オリジンサーバ）の間に配置され、クライアントからのリクエストを受け取って内部のWebサーバへ転送する仕組みです。クライアントから見ると、実際のWebサーバの代わりにリバースプロキシが“窓口”になります。

目的は大きく分けて、可用性の向上（負荷分散、冗長化、障害切り離し）と、運用の最適化（TLS終端、キャッシュ、圧縮、ルーティング制御）、そしてセキュリティ強化（WAF連携、アクセス制御、オリジン露出の低減）です。ただし「置くだけで安全になる」わけではなく、どの機能を使うか・どのように設定するかで効果は大きく変わります。

リバースプロキシの基本

リバースプロキシは一般的に、公開Webサーバの前段（DMZやクラウドの入口）に設置されます。基本の流れは次の通りです。

クライアントは、ドメイン名に対してHTTP/HTTPSでアクセスする
リバースプロキシがリクエストを受け取る（必要に応じて認証、ルール判定、WAF検査などを行う）
リバースプロキシが内部のWebサーバへ転送する（パスやホスト名で振り分ける場合もある）
Webサーバのレスポンスを受け取り、必要に応じてキャッシュ・圧縮してクライアントへ返す

この“窓口の一本化”により、Webサーバ側を直接インターネットにさらす範囲を減らしつつ、運用上必要な制御を前段でまとめて実装できます。

リバースプロキシとフォワードプロキシの違い

リバースプロキシとフォワードプロキシは、どちらも「代理（proxy）」ですが、代理する対象が異なります。

フォワードプロキシ：社内端末など“クライアント側”の代理。端末の代わりに外部へアクセスし、閲覧制御やログ取得、匿名化、マルウェア対策などに使われます。
リバースプロキシ：“サーバ側”の代理。Webサーバの代わりに外部からのアクセスを受け、内部へ転送し、負荷分散やWAF連携などを担います。

ひと言で言うと、フォワードプロキシはクライアントを守るための中継点、リバースプロキシはサーバ（サービス提供側）を守り、運用を成立させるための中継点です。

リバースプロキシの主な使い道

リバースプロキシは「中継」だけでなく、前段に置くからこそ価値が出る機能があります。代表的な使い道は次の通りです。

キャッシュ：静的コンテンツやキャッシュ可能なレスポンスを保持し、オリジンサーバへの問い合わせを減らして表示を高速化します。
負荷分散：複数台のWebサーバへリクエストを分配し、アクセス集中や障害時の影響を抑えます。
セキュリティ制御の集約：WAF連携、IP制限、認証、レート制限などを入口で一元化し、オリジンの露出を減らします。

加えて、実務ではTLS終端（証明書運用の集約）、圧縮（gzip/br）、HTTPヘッダの正規化、パス／ホストベースのルーティングなどが組み合わされることが多く、リバースプロキシは「入口の制御点」として設計されます。

リバースプロキシと情報セキュリティ

リバースプロキシは、Webサーバとクライアント間の通信を中継するだけでなく、入口での制御を通じてセキュリティ対策を実装しやすくします。ただし、リバースプロキシ単体が万能な防壁になるわけではありません。効果が出るのは、想定する脅威に合わせて機能と設定を選べている場合です。

リバースプロキシによるセキュリティ強化

リバースプロキシがセキュリティに寄与する代表例は、オリジンサーバへの直接到達を減らすことです。入口を一本化できると、アクセス制御や検査を“そこで必ず通す”設計にできます。

また、製品や構成によっては、TLS終端（証明書・暗号設定を入口に集約）や、WAF機能（またはWAF連携）、レート制限、Bot対策などを同じ場所で扱えます。結果として、オリジンサーバ側はアプリケーション処理に集中しやすくなり、対策の適用漏れも減らしやすくなります。

IPアドレスの隠蔽

リバースプロキシを前段に置くと、クライアントからはリバースプロキシのIPアドレスが見えるため、結果としてオリジンサーバのIPアドレスを“表に出さない”構成を取りやすくなります。

ただし、ここは誤解が起きやすい点です。DNS設定やネットワーク設計、FWルールが不十分だと、攻撃者が何らかの経路でオリジンを特定し、直接叩けることがあります。IP隠蔽の効果を高めるには、

オリジンをインターネットから到達できないネットワークに置く（またはFWで入口以外を遮断する）
オリジンへのアクセスを「リバースプロキシからのみ許可」する
管理系ポートや別系統の公開を最小化する

といった“構成としての閉じ方”がセットで必要です。

Webアプリケーションファイアウォール（WAF）機能

リバースプロキシにはWAF機能を持つもの、または外部WAFと連携しやすいものがあります。WAFは、SQLインジェクションやXSSなどWebアプリケーション層（L7）を狙う攻撃のパターンに対し、検知・遮断を行う役割を担います。

ただしWAFも万能ではありません。誤検知（正規の通信を止める）や検知漏れ（アプリ固有の脆弱性）もあり得るため、WAFは「最後の砦」ではなく、アプリの脆弱性対策、認証設計、ログ監視などと組み合わせて運用するのが基本です。

DoS／DDoS攻撃からの保護

リバースプロキシは、レート制限や接続制御、キャッシュによって、一定範囲でDoS（大量リクエストによるサービス妨害）への耐性を高められます。ただし、回線帯域を埋めるような大規模DDoSは、入口サーバだけで受け止め切れないことがあります。

実務では、CDNやDDoS保護サービス、回線事業者の対策、Anycastなどの仕組みと組み合わせ、「入口に到達する前に落とす」設計を検討します。リバースプロキシは、その中のアプリ層の制御点として位置づけると現実的です。

リバースプロキシの負荷分散機能

リバースプロキシは、1台以上のWebサーバ（バックエンド）の前に配置され、クライアントからのリクエストを適切なサーバに分散できます。これが負荷分散（ロードバランシング）で、性能と可用性を両立するための基本設計です。

負荷分散とリバースプロキシの関係性

リバースプロキシが受け取ったリクエストを複数のWebサーバへ振り分けることで、特定サーバへの集中を避けます。サーバの台数を増やして処理能力を上げられるため、アクセス増にも対応しやすくなります。

さらに、ヘルスチェック（死活監視）と組み合わせれば、障害が起きたサーバを自動的に振り分け対象から外し、サービスを継続しやすくなります。ここが、単なる“中継”ではなく“可用性の仕組み”として効く部分です。

リバースプロキシによる負荷分散のメリット

負荷分散のメリットは、単に速くなるだけではありません。

性能の平準化：特定サーバの高負荷を避け、応答遅延やタイムアウトを減らす
可用性の向上：サーバ障害が起きても切り離して継続しやすい
メンテナンス性：ローリング更新（順次切り替え）がしやすくなる
入口制御の統一：認証やWAFなどを入口に集約しやすい

一方で、セッション維持（ログイン状態など）が必要なアプリでは、スティッキーセッションやセッション共有（Redisなど）をどうするかが論点になります。負荷分散は“振り分ければ終わり”ではなく、アプリの状態管理とセットで設計します。

リバースプロキシによる負荷分散の実現

負荷分散方式にはいくつかあり、要件によって使い分けます。

ラウンドロビン：順番に振り分ける。構成が単純で分かりやすい
最小接続数（Least Connections）：接続数が少ないサーバへ振る。処理時間が偏る場合に有効
重み付け（Weighted）：性能差があるサーバに配分を合わせる
ハッシュベース：クライアントIPやCookieで振り先を固定し、セッション維持に寄せる

また、Webアプリの特性によっては、L4（TCP）で分散するのか、L7（HTTP）でパスやホスト単位に振るのかも重要です。たとえば「/api はAPIサーバへ」「/static は静的配信へ」のような分岐はL7のほうが得意です。

負荷分散とセキュリティ

負荷分散は、結果としてセキュリティにも寄与します。入口が一本化されるため、アクセス制御や監視を集約でき、異常トラフィックの検知もしやすくなります。

ただし「分散しているから安全」というわけではありません。攻撃トラフィックも分散されるだけで、総量が増えれば全体が苦しくなります。負荷分散は、可用性を上げる仕組みとして設計し、DDoS対策は別レイヤ（CDN／回線対策）と組み合わせるのが基本です。

リバースプロキシのキャッシュ機能とその利点

リバースプロキシは、条件が合えばキャッシュによって大きくパフォーマンスを改善できます。一方で、キャッシュは“正しく使わないと事故る”機能でもあります。何をキャッシュすべきか、何をキャッシュしてはいけないかを押さえておきましょう。

リバースプロキシにおけるキャッシュの概念

キャッシュとは、一度取得したレスポンス（HTML、画像、CSS、JSONなど）を一時保存し、同じ条件のリクエストが来たときにオリジンサーバへ問い合わせずに返す仕組みです。オリジンへのリクエスト数が減るため、CPUやDB負荷を抑えられ、ピーク耐性も上がります。

ただし、キャッシュの可否や有効期間は、HTTPのキャッシュ制御（Cache-Control、Expires、Varyなど）や、リバースプロキシ側のポリシーで決まります。設計の基本は「キャッシュして良いものだけを、意図してキャッシュする」です。

キャッシュによる表示速度の向上

キャッシュが効くと、応答は速くなりやすいです。特に、画像・CSS・JSなどの静的コンテンツ、または同一内容を多数のユーザーに返すページは効果が大きく、バックエンドのスパイクを吸収できます。

一方、動的ページやユーザーごとに内容が変わるレスポンスを不用意にキャッシュすると、古い情報が出たり、別ユーザーの内容が混ざったりします。速度向上の裏側には、必ず“正しさ”の設計が必要です。

キャッシュとセキュリティ

キャッシュは、結果としてオリジンへの到達回数を減らし、入口での制御を効かせやすくします。一定条件下ではDoSの緩和にも役立ちます。

ただしセキュリティ観点では、キャッシュしてはいけない情報（個人情報、認証後ページ、管理画面、CSRFトークンを含むレスポンスなど）を明確に分離し、Cache-Control: no-store 等で制御することが重要です。キャッシュは“攻撃を減らす”より先に、“漏えいを増やさない”ことが優先です。

キャッシュの活用方法

キャッシュを効果的に使うには、次のような設計が現実的です。

静的と動的の分離：静的資産は長めにキャッシュ、動的は原則キャッシュしない
パージ（削除）手段の用意：更新時にキャッシュを確実に捨てられる仕組みを持つ
キャッシュキーの設計：Host、パス、クエリ、Cookieの扱いを明確にする
バイパス条件：ログイン中や特定ヘッダがある場合はキャッシュしない

適切に設計できれば、キャッシュはWebサーバのパフォーマンスと可用性に強く効きます。逆に曖昧なまま導入すると、“速いが間違う”状態になりやすいので注意が必要です。

リバースプロキシの設定と性能向上

リバースプロキシの効果は、設定で大きく変わります。ここでは、現場で差が出やすい設定ポイント、モニタリング、障害時の設計を整理します。

設定のポイント

リバースプロキシ設定の核は、「入口で何を終端し、何をバックエンドへ渡すか」を明確にすることです。代表的な論点は次の通りです。

TLS（HTTPS）：入口で終端するか、バックエンドまで暗号化するか（再暗号化／mTLSの要否）
転送ヘッダ：X-Forwarded-For や Forwarded をどう扱い、クライアントIPをどう引き継ぐか
タイムアウト：接続・読み取り・書き込みのタイムアウトを、アプリ特性に合わせる
上限・防御：同時接続数、リクエストサイズ、レート制限などで入口を守る
ログ：アクセスログとエラーログを、追跡できる粒度で出す（相関IDなど）

「HTTPSにしたから安全」ではなく、暗号設定・証明書更新・ログ追跡まで含めて運用できる形にすることが重要です。

パフォーマンス改善のために

性能改善では、キャッシュだけでなく、入口の処理を“軽く保つ”ことが効きます。たとえば、圧縮の適用範囲、Keep-Alive設定、HTTP/2・HTTP/3の取り扱い、バックエンドへの接続再利用などが影響します。

また、負荷分散では「振り分け方式」だけでなく、ヘルスチェックの間隔や判定条件、障害検知から切り離しまでの時間、復帰の条件まで含めて設計すると、実運用の事故が減ります。

モニタリングによる性能評価

リバースプロキシは入口なので、モニタリングの価値が高い領域です。最低限、

リクエスト数、レイテンシ（p95/p99）、ステータスコード（4xx/5xx）
バックエンド別の応答時間、エラー率、ヘルスチェック結果
レート制限・WAF検知・ブロック数などのセキュリティ指標

を継続的に見られるようにします。障害は「入口で起きているように見えるが、原因はバックエンド」というケースも多いため、入口とバックエンドを同じ観測軸で追えることが重要です。

障害対応策

リバースプロキシ自体が落ちると入口が止まるため、冗長化は基本です。一般的には複数台構成＋フェイルオーバー、またはクラウドのマネージドLBと組み合わせて単一障害点をなくします。

復旧プロセスとしては、設定変更のロールバック手順、証明書更新失敗時の手順、バックエンド切り離しと復帰の手順を定義しておくと、障害対応のスピードが上がります。

データセンター間通信のセキュリティ

「データセンター間通信」と一口に言っても、用途はさまざまです。リバースプロキシは本来、インターネットからのHTTP/HTTPS（Web/API）アクセスの入口として使われることが多い仕組みです。そのため、データセンター間の通信全般（DBレプリケーションやストレージ同期など）を守る万能ツールとして捉えると、設計がずれやすくなります。

一方で、データセンター間でWeb/APIを提供し合うケース（社内向けAPI、B2B API、マイクロサービス間通信など）では、リバースプロキシ（またはAPIゲートウェイ）が入口制御点として有効です。ここでは、その前提を置いたうえで、関連する論点を整理します。