フォワードプロキシは、外部リクエストを行うクライアントの代理として機能します。リバースプロキシは、内部リクエストを受け取るサーバーの代理として機能します。 フォワードプロキシとリバースプロキシの決定では、制御したいトラフィックが誰のものであるかを特定することから始めます：リクエストを行う人またはアプリケーション、またはそれを受け取るウェブサイトです。
両者は仲介者であり、両者ともリクエストを送信できます。彼らの名前は、アーキテクチャにおける役割を説明しており、セキュリティ、匿名性、またはパフォーマンスに関する約束ではありません。ウェブサイトゲートウェイは自動的に外部ブラウジングサービスになるわけではなく、フォワードプロキシを購入しても、あなたのアプリケーションが訪問者に公開されるわけではありません。
TL;DR
- クライアントが定義された外部ルートまたはアクセスポリシーを必要とする場合は、フォワードプロキシを使用します。
- 訪問者があなたが運営するアプリケーションへのエントリーポイントを必要とする場合は、リバースプロキシを使用します。
- 認証、暗号化、キャッシング、ログ記録は、プロキシラベルだけでなく、実際の設定に依存します。
- 両方の役割は1つのシステムに存在できますが、それぞれに異なる所有者、資格情報、障害モードがあります。
- 住宅用、ISP、またはデータセンターラベルはネットワーク提供を説明しますが、フォワードとリバースの区別を置き換えるものではありません。
1つの表での違い
| 質問 | フォワードプロキシ | リバースプロキシ |
|---|---|---|
| 誰の代理ですか？ | クライアントまたはクライアントのグループ | サーバーまたはサーバーのグループ |
| 典型的なリクエストパス | アプリケーション → プロキシ → 宛先 | 訪問者 → プロキシ → アプリケーション |
| 通常誰が選択しますか？ | クライアントオペレーターまたはネットワーク管理者 | ウェブサイトまたはサービスオペレーター |
| 即時の目標は何ですか？ | 外部アクセスを制御またはルーティングすること | 内部アクセスを受け取り、ルーティングすること |
| 典型的な認証の懸念 | このクライアントはプロキシを使用できますか？ | この訪問者はこのアプリケーションにアクセスできますか？ |
| 一般的な運用上の懸念 | エンドポイントアクセス、資格情報、外部ポリシー | 上流の健全性、ルーティング、証明書、オリジンアクセス |
| 自動的に提供しないものは何ですか？ | 自分のウェブサイトのための公共のエントリーポイント | 無関係なブラウザトラフィックのための異なる外部アイデンティティ |
これらは特定のソフトウェアパッケージに対する制限ではなく、典型的な役割です。能力のあるゲートウェイは複数の機能をサポートできますが、各機能には明示的な設定が必要です。MDNのプロキシサーバーの概要は、HTTPリクエストパスにおける転送仲介者とゲートウェイを区別しています。
フォワードプロキシの動作
認可されたリクエストを外部サービスに送信するレポートアプリケーションを想像してください。直接接続する代わりに、設定されたフォワードプロキシを介してリクエストを送信します。プロキシは次の接続を確立し、同じ論理パスを通じて応答を返します。
クライアントオペレーターは、中央集権的な外部ポリシー、制御されたネットワークルート、またはアプリケーションが宛先に到達するためのサポートされた方法を望むかもしれません。正確な結果は、プロトコル、クライアントのプロキシサポート、およびプロバイダーの設定に依存します。一部のアプリケーションには独自のプロキシ設定がありますが、他のアプリケーションはシステムまたは環境設定を継承します。
重要な運用上の質問は、意図されたアプリケーションが実際にプロキシを使用しているかどうかです。1つのツールで設定を変更しても、コンピュータ上のすべてのプロセスがそれに従うことを証明するものではありません。バックグラウンドサービス、ブラウザ、コマンドラインクライアントは異なる有効な設定を持つことがあります。
フォワードプロキシは、宛先が他の識別情報を見ないことを保証するものではありません。リクエストにはアカウント資格情報、クッキー、アプリケーションデータが含まれる場合があります。正当な技術的ニーズのためにルートを選択し、データ処理をネットワーク接続に使用されるアドレスとは別に評価してください。
例：スケジュールされたデータ統合
許可されたサプライヤーデータを毎朝取得する仮想統合を考えてみましょう。そのオペレーターは、リクエストが文書化されたエンドポイントを通過することを望んでいます。オペレーターは統合のHTTPクライアントを設定し、プロキシ資格情報をサプライヤーAPIトークンとは別に保存し、ルートとアプリケーションの動作を両方確認します。
プロキシ資格情報は、統合が仲介者を使用できるかどうかを示します。サプライヤートークンは、サプライヤーのデータを読み取ることができるかどうかを示します。機能するプロキシは、2番目の許可を付与しません。これらの責任を分けておくことで、認証の失敗を診断しやすくなります。
リバースプロキシの動作
次に、プライベートサービスポートでアプリケーションが実行されている公共のウェブサイトを想像してください。訪問者はウェブサイトの玄関に接続します。リバースプロキシはそのトラフィックを受け取り、設定された上流アプリケーションに転送し、次にアプリケーションの応答を返します。
ウェブサイトオペレーターは上流を選択し、エントリーポイントを制御します。設計によっては、リバースプロキシがTLS終端処理、サービス間のルーティング、バッファリング、または負荷分散を処理する場合があります。これらは設定された機能であり、すべてのデプロイメントに含まれると仮定すべき機能ではありません。
NGINXリバースプロキシのドキュメントは、proxy_passを使用して上流にリクエストを渡し、リクエストヘッダーを設定し、バッファリングを制御する方法を説明しています。このガイドは役割の選択に焦点を当てており、インストールや指示の詳細は、実際にデプロイするソフトウェアのドキュメントに属します。
リバースプロキシは、健康でないアプリケーションを健康にすることはできません。上流のデータベースが利用できない場合、その前に別のコンポーネントを置いても、欠落しているデータを復元することはできません。アーキテクチャがそのように設計されている場合にのみ、制御された障害応答を提供したり、別の健康なインスタンスにルーティングしたりできます。
例：1つのドメイン内の2つの内部アプリケーション
小さなチームがダッシュボードとドキュメンテーションサービスを運営していると仮定します。これは仮想設計であり、ベンチマークではありません。リバースプロキシは、定義された公共のエントリーポイントを提供し、設定されたホストまたはパスに従って適切なアプリケーションにリクエストを送信できます。
チームは、各アプリケーションに誰がアクセスできるか、証明書の更新方法、およびオリジンサービスが直接到達可能かどうかを決定する必要があります。整然としたドメイン構造は便利ですが、アクセス制御を置き換えるものではありません。期待される公共のルートと意図しない代替エントリーポイントの両方をテストしてください。
認証と信頼は各側で異なる
フォワードプロキシは、トラフィックを転送する前にユーザー名とパスワードを要求する場合があります。アプリケーションも独自の宛先資格情報を必要とする場合があります。設定、ログ、およびインシデントレポートでは、2つのアイデンティティを分けておいてください。
リバースプロキシでは、訪問者がアプリケーションまたはその前のアクセスレイヤーに対して認証を行う場合があります。アプリケーションは、どのヘッダーまたはアイデンティティ主張を信頼できるかを理解する必要があります。信頼できる境界なしに訪問者提供のアイデンティティヘッダーを受け入れることは、意図された制御を損なう可能性があります。
たとえば、アプリケーションはトラフィックがゲートウェイを通過した後に元の訪問者アドレスを記録したい場合があります。それには、意図的な信頼されたプロキシ設定が必要です。転送されたヘッダーを単に読み取ることは、その内容が権威あるものであることを確立するものではありません。アプリケーションとゲートウェイの設定は、どのコンポーネントがそれを供給することを許可されているかについて合意する必要があります。
いずれの設計においても、ルーティング設定を変更できる人を定義してください。プロキシ管理者は、リクエストがどこに行くか、仲介者を通過する情報が何であるかに影響を与えることができます。その権限を意味のある運用上の許可として扱い、無害な便利設定として扱わないでください。
どちらのプロキシも自動的にすべてを暗号化しますか？
いいえ。接続を別々に特定してください。クライアントからプロキシへの接続と、プロキシから宛先または上流への接続がある場合があります。1つの接続での暗号化は、他の接続での暗号化を確立するものではありません。
HTTPSを終端するリバースプロキシの場合、アプリケーションへの接続もTLSを必要とするかどうかを決定し、関連する証明書と信頼設定を確認してください。フォワードプロキシの場合、宛先URLをプロキシエンドポイントに到達するために使用されるプロトコルから区別してください。
これらの選択をアーキテクチャ記録に書き留めてください。暗号化がどこで始まり、どこで終わるかを説明せずに、全ルートを「安全」とラベル付けする図は避けてください。役立つレビューは、各仲介者が何を観察できるか、資格情報がどこを移動するか、どの当事者が信頼設定を管理するかを尋ねます。
実用的な選択プロセス
1. リクエストを平易な言葉で書く
「私たちの作業者が外部APIを呼び出す」または「顧客が私たちのダッシュボードを開く」といった文を使用します。リクエスターと宛先を名付けます。この小さな演習は、製品比較を開始する前に、プロキシの区別の関連する側面を特定することが通常です。
要件が「プロキシが必要」とだけ言っている場合、何を変更する必要があるかを尋ねてください：外部ルーティング、内部アプリケーションアクセス、認証、またはトラフィック管理。それらの目標は異なるコンポーネントを必要とする場合があります。
2. 制御する境界を特定する
クライアント、中介者、宛先をリストします。あなたのチームが運営するシステムと、他の組織に属するシステムをマークします。サードパーティのウェブサイトに対する管理権限を前提としたソリューションを設計しないでください。
あなたが所有するアプリケーションの場合、内部ゲートウェイを選択し、オリジンを設定できます。サードパーティAPIの場合、あなたはクライアントとその認可されたルートを制御しますが、APIのアカウント権限と使用ルールはその境界の外に残ります。
3. 必要なプロトコルと動作を定義する
アプリケーションプロトコル、認証方法、リクエストサイズ、ストリーミング動作、および期待される接続期間を含めます。成功した短いページリクエストは、長期間のストリームや大きなアップロードが正しく動作することを証明するものではありません。
代表的な認可テストを使用し、クライアントバージョンを記録します。「プロキシ」という言葉を、すべてのプロトコルや認証メカニズムが機能する証拠として扱わないでください。互換性は完全な接続パスの特性です。
4. 各障害にオーナーを割り当てる
クライアント設定、プロキシの可用性、アプリケーションの健全性、および証明書の更新を確認する人を決定します。サポートスタッフに、プロキシ認証の失敗と上流アプリケーションの失敗を区別するための十分な情報を提供します。
また、ルーティング変更を無効にするか、元に戻す方法を決定します。可逆的な設定は、誰もが障害中に発見する文書化されていない依存関係よりもはるかに操作しやすいです。
5. 実際の結果を確認する
フォワードプロキシの場合、意図されたアプリケーションが選択されたルートに従い、実際のタスクを完了することをテストします。リバースプロキシの場合、公共のホスト名、ルーティング、認証、および期待される上流の動作をテストします。意図しない直接アクセスが、設計上必要な場所で制限されていることを確認してください。
結果を1つの成功したリクエストのスクリーンショットではなく、小さな受け入れ記録として保持します。通常の動作、1つの制御された失敗、および回復ステップを含めます。これにより、将来の変更のための参照が作成されます。
システムは両方を使用できますか？
はい。ウェブアプリケーションはリバースプロキシを介して訪問者を受け入れつつ、バックグラウンドワーカーが認可された外部統合のためにフォワードプロキシを使用することがあります。これらは別々のリクエストパスであり、コンポーネントが同じインフラストラクチャで実行されている場合でも同様です。
それらの資格情報、ログ、および設定名を区別してください。「プロキシパスワード」は、デプロイメントに複数の仲介者が含まれている場合、曖昧な秘密ラベルです。サービスと目的を特定し、秘密そのものを明らかにしない名前を好みます。
また、障害の独立性を考慮してください。外部プロキシが利用できない場合、公共アプリケーションは利用可能であり続けるべきですか、それともスケジュールされた統合が一時停止しますか？内部ゲートウェイが失敗した場合、オペレーターは回復コンソールにまだアクセスできますか？これらの質問は、1つのコンポーネントが無関係な作業の依存関係になってしまったかどうかを明らかにします。
ホスティングとプロキシ製品の適合
サーバーはソフトウェアを実行する場所を提供します。フォワーディングサービスは、互換性のあるクライアントにリクエストのルートを提供します。これらは組み合わせることができますが、どちらも自動的に他を含むわけではありません。既存のVPSと住宅用プロキシの比較は、その区別を拡大します。
アプリケーションやゲートウェイをホスティングする場合、Cloud VPSのランタイムとメンテナンスの責任を評価します。NGINX Proxy Managerを選択する場合、既存のNGINX Proxy Managerデプロイメントガイドがその別のインストールタスクをカバーしています。より広範なVPS管理ガイドは、基盤となるサーバーのメンテナンスに関連しています。
外部プロキシのISPまたはデータセンターの分類は異なる決定です。それは、あなたのウェブサイトがリバースプロキシを必要とするかどうかを教えてくれず、認証とアプリケーションアクセスを設定する必要を取り除くものではありません。まずアーキテクチャを選択し、その後特定の要件に対してネットワーク提供を評価してください。
FAQ
フォワードプロキシとリバースプロキシの主な違いは何ですか？
フォワードプロキシは外部リクエストを行うクライアントにサービスを提供し、リバースプロキシは内部リクエストを受け取るアプリケーションにサービスを提供します。どちらの側を運営しているか、どのトラフィックの動作を変更したいかを特定してから、ソフトウェアやサービスを選択してください。
リバースプロキシは私のブラウザの外部IPを変更できますか？
あなたのウェブサイトの前に存在するだけでは、そうではありません。それは、提供するアプリケーションに宛てられたリクエストを処理します。無関係なブラウザトラフィックを仲介者を介してルーティングするには、別のサポートされたフォワードプロキシまたはネットワーク設定が必要です。
リバースプロキシはロードバランサーと同じですか？
いいえ。ロードバランシングはリバースプロキシ設計の1つの可能な機能です。リバースプロキシは単一の上流に転送でき、ロードバランシングシステムは異なる方法で動作できます。ラベルから冗長性を仮定するのではなく、実際の設定を確認してください。
フォワードプロキシはリクエストを匿名にしますか？
その役割からはそのような保証はありません。アカウントログイン、クッキー、リクエストデータ、およびオペレーターのログは依然として重要です。送信される情報と保持される情報を評価し、あなたが実行することを許可されているアクセスのみにサービスを使用してください。
小さなウェブサイトに両方が必要ですか？
必ずしもそうではありません。アプリケーションの要件から始めてください。管理されたホスティングサービスがすでに内部エントリーポイントを処理している場合があり、通常の外部リクエストには追加のプロキシが必要ないかもしれません。文書化された要件を解決し、誰かがそれを維持できる場合にのみコンポーネントを追加してください。
透過的プロキシは第三の方向ですか？
いいえ。透過性は、特定のコンテキストでの傍受またはクライアントの認識がどのように機能するかを説明します。それは、仲介者がどのリクエストを提供するかとは別の次元です。すべてのプロキシラベルを競合するアーキテクチャとして扱うのではなく、トラフィックパスの正確な説明を使用してください。