プロキシとリバースプロキシの違いについて

プロキシは、クライアントとサーバーの間に入り、通信を代理・中継する仕組みの総称です。

大きく分けると、クライアント側の通信を代理する「フォワードプロキシ」と、サーバー側の通信を代理する「リバースプロキシ」があります。

• フォワードプロキシ：利用者や端末の代理として外部サービスへ接続する
• リバースプロキシ：Webサーバーやアプリケーションサーバーの代理として外部からのアクセスを受ける

最も簡潔に整理すると、フォワードプロキシは利用者側の代理人、リバースプロキシはWebサイトやアプリケーション側の代理人です。

フォワードプロキシとは

フォワードプロキシは、利用者の端末とインターネットの間に置かれる仕組みです。

利用者がWebサイトやクラウドサービスへアクセスする際、直接接続するのではなく、フォワードプロキシを経由して外部へ接続します。

企業や学校などでは、利用者の外部アクセスを管理する目的で導入されることがあります。

主な用途

フォワードプロキシには、次のような用途があります。

• 危険なWebサイトや不適切なサイトへのアクセス制限
• マルウェア配布サイトやフィッシングサイトの遮断
• 利用者の外部アクセスログの取得
• 業務に関係のないサービスへのアクセス制御
• SaaSやクラウドサービスの利用状況の可視化
• ファイルのアップロードやダウンロードの監視
• 通信量の把握
• 社内ポリシーに違反する通信の検知

たとえば、社内ネットワークから動画サイト、ファイル共有サービス、外部ストレージ、危険なドメインなどへのアクセスを制限する場合に利用されます。

HTTPS通信の内容を常に確認できるわけではない

フォワードプロキシを経由していても、HTTPS通信の中身を常に確認できるとは限りません。

通常のHTTPS通信では、ブラウザと接続先のWebサイトの間で通信が暗号化されます。

この場合、プロキシは接続先のドメイン、通信日時、通信量などを把握できても、ページ本文、フォーム入力内容、詳細なURLパス、アップロードファイルの内容まで確認できないことがあります。

一方で、企業が端末に専用の証明書を配布し、TLS復号やSSLインスペクションを行う構成では、暗号化された通信の内容を検査できる場合があります。

このような構成では、次のような内容まで制御対象にできることがあります。

• 詳細なURL
• HTTPヘッダー
• アップロード・ダウンロードされるファイル
• SaaS上での操作の一部
• マルウェアや不正なスクリプトの兆候
• 情報漏えいにつながるファイル送信

ただし、TLS復号はプライバシー、法務、端末管理、証明書運用などの観点で慎重な設計が必要です。

IPアドレスを隠せるとは限らない

フォワードプロキシを経由すると、外部サイトからはプロキシのIPアドレスがアクセス元として見える場合があります。

ただし、これは完全な匿名化を意味しません。

プロキシの運営者や社内管理者は、利用者の接続元、認証ユーザー、アクセス日時、アクセス先、通信量などをログとして把握できる可能性があります。

また、外部サイト側も、Cookie、ログイン情報、ブラウザ情報、端末情報、行動履歴などを使って利用者を識別できる場合があります。

そのため、フォワードプロキシは、外部サイトに対して利用者のネットワーク情報を直接見せない構成にできることがある仕組みであり、完全に匿名になる仕組みではありません。

プライベートIPとグローバルIPは区別する

社内PCや家庭内PCでは、192.168.x.x や 10.x.x.x のようなプライベートIPアドレスが使われることがあります。

これらはインターネット上で直接使われるIPアドレスではありません。

外部のWebサイトから見えるのは、通常、次のいずれかです。

• ルーターやNAT後のグローバルIPアドレス
• 企業ネットワークの出口IPアドレス
• フォワードプロキシのグローバルIPアドレス
• VPNやクラウド型セキュリティサービスの出口IPアドレス

端末内部で使われるIPアドレスと、外部サイトから見えるIPアドレスは別のものとして考える必要があります。

リバースプロキシとは

リバースプロキシは、WebサイトやWebアプリケーションの前に配置され、外部からのアクセスを受け取ってから、内部のWebサーバーやアプリケーションサーバーへ転送する仕組みです。

利用者はWebサイトへアクセスしているつもりでも、実際には最初にリバースプロキシへ接続し、その後に適切なバックエンドサーバーへリクエストが渡されます。

Webサイトやサービスの運用では、リバースプロキシがインターネットからの入口になる構成が一般的です。

主な用途

リバースプロキシには、次のような役割があります。

• 複数サーバーへの負荷分散
• HTTPS通信の受付
• TLS証明書の管理
• 静的ファイルの高速配信
• ページやAPIレスポンスのキャッシュ
• URLやサブドメインごとの振り分け
• レート制限
• IPアドレスによるアクセス制限
• WAFとの連携
• Bot対策
• DDoS対策との連携
• オリジンサーバーのIPアドレスや構成の保護

たとえば、同じドメインでも、URLのパスやサブドメインに応じて別のアプリケーションへ振り分けることができます。

• コーポレートサイト
• ECサイト
• 管理画面
• API
• メディアサイト
• ランディングページ配信基盤
• 会員向けサービス

これらを利用者からは一つのサービスのように見せながら、裏側では別々のサーバーやアプリケーションで運用できます。

TLS終端と内部通信

リバースプロキシでは、外部からのHTTPS通信を最初に受け取り、TLSの暗号化・復号処理を担当する構成があります。

この仕組みはTLS終端、またはSSL終端と呼ばれます。

TLS終端を行うと、証明書管理や暗号化処理をリバースプロキシ側に集約できます。

アプリケーションサーバーごとに証明書設定を行う必要がなくなり、設定や運用を統一しやすくなります。

バックエンドをHTTPにする場合とHTTPSにする場合

リバースプロキシからバックエンドサーバーへの通信は、HTTPにする場合とHTTPSにする場合があります。

内部ネットワークが十分に分離・保護されている場合は、リバースプロキシでTLSを終端し、バックエンドへはHTTPで転送する構成も使われます。

一方で、次のような条件では、バックエンドまでHTTPSを維持する設計がよく採用されます。

• クラウド上で複数ネットワークや複数アカウントをまたぐ
• Kubernetesやコンテナ環境で通信経路が複雑
• 個人情報や決済情報を扱う
• 監査・コンプライアンス要件が厳しい
• 複数リージョンや複数拠点にまたがる
• ゼロトラストを前提とした設計を採用する

内部通信をHTTPにするかHTTPSにするかは、ネットワーク構成、データの重要性、運用体制、セキュリティ要件を踏まえて決める必要があります。

X-Forwarded-For などのIPヘッダー

リバースプロキシやCDN、ロードバランサーを経由すると、アプリケーションサーバーから見える接続元IPアドレスは、実際の利用者のIPアドレスではなく、リバースプロキシやロードバランサーのIPアドレスになります。

そのため、元のクライアントIPやアクセス時のプロトコル情報をバックエンドへ伝えるために、次のようなHTTPヘッダーが使われます。

• X-Forwarded-For
• X-Forwarded-Proto
• X-Forwarded-Host
• Forwarded

これらの情報は、アクセスログ、IP制限、レート制限、不正アクセス検知、HTTPS判定、リダイレクト処理などで利用されます。

ヘッダーを無条件に信頼してはいけない

X-Forwarded-For などのヘッダーは、クライアントが任意の値を付けて送信できる場合があります。

そのため、アプリケーションが受け取ったヘッダーを無条件に本物の利用者情報として扱うと、IP制限やアクセス制御を回避されるおそれがあります。

安全に扱うには、次のような設計が必要です。

• 信頼するCDN、ロードバランサー、リバースプロキシを明確にする
• 信頼済みの中継サーバーから付与されたヘッダーだけを利用する
• 外部から直接届くヘッダーを削除または上書きする
• アプリケーション側で信頼プロキシの設定を行う
• IPアドレスだけを認証の根拠にしない

特にCDN、ロードバランサー、Webサーバー、アプリケーションサーバーが多段構成になっている場合は、どの層がどのヘッダーを追加し、どこまでを信頼するのかを明確にする必要があります。

CDNとリバースプロキシの関係

CDNは、画像、JavaScript、CSS、HTML、動画などを利用者に近い場所から配信する仕組みです。

多くのCDNは、利用者からのアクセスを受け取り、キャッシュ、画像最適化、WAF、Bot対策、DDoS対策、ルール処理などを行ったうえで、必要に応じてオリジンサーバーへリクエストを転送します。

このような構成では、CDNは分散配置されたリバースプロキシとして機能します。

CDNとリバースプロキシは完全に同じではない

CDNはコンテンツを分散配信する仕組み全体を指し、リバースプロキシはサーバー側の代理として通信を中継する役割を指します。

そのため、両者は近い関係にありますが、完全に同義ではありません。

CDNを使っていても、設定によってはDNSだけを利用しており、CDN事業者がすべてのHTTP通信を中継していないこともあります。

より正確には、次のように整理できます。

• CDNのプロキシ機能が有効な場合、CDNはリバースプロキシとして動作することが多い
• CDNはキャッシュ、セキュリティ、画像最適化、エッジ処理などを含む広い概念
• リバースプロキシは、通信の受付・転送・制御を担う役割に焦点を当てた概念

WAFとの関係

WAFは、Webアプリケーションへの不正なリクエストを検知・遮断するための仕組みです。

リバースプロキシやCDNの前段にWAFを配置することで、SQLインジェクション、クロスサイトスクリプティング、不正なボットアクセス、異常なリクエストなどを検知・制御できる場合があります。

WAFだけで安全になるわけではない

WAFは有効な防御層ですが、アプリケーションの脆弱性を完全に解決するものではありません。

安全性を確保するには、次のような対策も必要です。

• 入力値の検証
• 出力時のエスケープ
• 適切な認可設計
• SQLプレースホルダーの利用
• ライブラリやミドルウェアの更新
• 管理画面のアクセス制限
• 多要素認証
• 脆弱性診断
• アクセスログの監視
• インシデント対応手順の整備

WAFはあくまで多層防御の一部として考える必要があります。

キャッシュと高速化

リバースプロキシやCDNは、静的ファイルやキャッシュ可能なページを保存し、バックエンドサーバーへ毎回アクセスしなくても応答できるようにします。

これにより、アプリケーションサーバーやデータベースの負荷を減らし、ページ表示速度やアクセス集中時の安定性を改善できます。

キャッシュと相性がよいコンテンツには、次のようなものがあります。

• 画像
• CSS
• JavaScript
• フォント
• 公開記事
• 商品一覧ページ
• カテゴリページ
• ランディングページ
• キャッシュ可能なAPIレスポンス

個別表示や認証ページのキャッシュに注意する

ログイン状態、会員情報、購入履歴、カート、地域別表示、ユーザーごとの価格、A/Bテスト、Cookie依存の表示などを共有キャッシュに保存すると、情報漏えいや表示不具合につながる可能性があります。

想定される問題には、次のようなものがあります。

• 別の利用者の情報が表示される
• ログイン後の画面が他人に見える
• カート内容が混在する
• A/Bテストの表示パターンが固定される
• 広告用ランディングページの内容が意図せず他の利用者にも表示される
• 地域別・端末別コンテンツが正しく切り替わらない
• 割引やクーポン情報が誤って配信される
• 修正済みのページではなく古いページが表示され続ける

キャッシュを活用する際は、Cookie、認証状態、クエリパラメータ、Cache-Control、キャッシュキー、パージ方法などを設計する必要があります。

Webサイト運用とマーケティングへの影響

リバースプロキシやCDNの設定は、表示速度、広告計測、コンバージョン、セキュリティに影響します。

表示速度とコンバージョンへの影響

ページ表示が遅いと、広告流入や各種導線から訪れた利用者が離脱しやすくなります。

適切なキャッシュ、圧縮、画像最適化、静的ファイル配信、TLS処理、負荷分散などにより、次のような改善につながる可能性があります。

• 離脱率の低下
• ランディングページのコンバージョン率改善
• 商品ページの閲覧継続率向上
• モバイル環境での体験向上
• アクセス集中時の安定化
• サーバー応答時間の短縮

計測・広告タグへの影響

CDNやリバースプロキシのキャッシュ、リダイレクト、HTML最適化、セキュリティ設定は、広告計測や解析タグにも影響する場合があります。

注意が必要な例としては、次のようなものがあります。

• URLパラメータがリダイレクトで失われる
• UTMパラメータが正しく引き継がれない
• GTMや解析タグの読み込みが意図せず変わる
• コンバージョンタグの発火条件が崩れる
• Cookieを使った計測が不安定になる
• A/Bテストの判定結果がキャッシュされる
• Bot対策が広告審査や外部ツールを誤検知する
• 管理画面やプレビュー環境が誤ってキャッシュされる

速度改善と計測精度は切り離せないため、設定変更後は広告タグ、解析、フォーム送信、コンバージョン計測、リダイレクトをまとめて確認する必要があります。

まとめ

フォワードプロキシは、利用者や端末が外部サービスへアクセスする際の代理として使われます。

主な目的は、外部アクセスの管理、ログ取得、危険サイトの遮断、SaaS利用の統制、情報漏えい対策です。

リバースプロキシは、Webサイトやアプリケーションの前に置かれ、外部からのアクセスを受けてバックエンドへ振り分けます。

主な目的は、負荷分散、TLS終端、キャッシュ、ルーティング、セキュリティ対策、オリジンサーバーの保護です。

実務では、CDN、WAF、ロードバランサー、リバースプロキシ、アプリケーションサーバーが複数段に組み合わされることがあります。

その際は、特に次の点を明確にすることが重要です。

• HTTPS通信のどこまでを復号・検査するか
• 元のクライアントIPをどのヘッダーで扱うか
• どのプロキシやCDNを信頼するか
• どのコンテンツをキャッシュするか
• 認証済みページや個別表示をキャッシュ対象から除外できているか
• リダイレクト、広告計測、フォーム送信などに影響が出ていないか

以上、プロキシとリバースプロキシの違いについてでした。

最後までお読みいただき、ありがとうございました。