プロキシは、クライアント (アプリケーションなど) と移行先サーバー (バックエンド API など) の間に配置される中間サーバーです。 アプリケーションが要求を送信すると、プロキシは最初に要求を受け取ります。 その後、プロキシは、要求をターゲット サーバーに転送したり、変更したり、ブロックしたり、応答を直接返したりできます。
つまり、プロキシは、通信を仲介するためにクライアントまたはサーバーの代わりに機能します。
プロキシのしくみ
プロキシは、受信要求を受信し、次の 1 つ以上のアクションを実行することで、HTTP レベル (または他のアプリケーション プロトコル) で動作します。
- 要求をターゲット サーバーに転送し、応答をクライアントにリレーします。
- 転送前にヘッダー、URL、またはペイロードを変更する。
- をインターセプトし、ターゲット サーバーに接続せずにローカルで要求に応答します。
- ルールまたはアクセス ポリシーに基づいて要求を拒否する。
クライアントの観点からは、単に URL に要求を送信するだけです。 プロキシは、バックグラウンドで他のすべてを処理します。 パターンはクライアントからプロキシを通ってターゲットサーバーへです。
このパターンでは、セキュリティ、可観測性、パフォーマンス、およびテスト可能性を向上させるために使用できるコントロールと抽象化のレイヤーが導入されています。
プロキシの種類
プロキシにはさまざまな種類があります。 それぞれは、システム アーキテクチャの特定の役割に適しています。
プロキシの転送
前方プロキシは クライアントの前に配置されます。 アプリケーションが要求を行うと、プロキシが経由され、転送するかどうかと転送方法が決定されます。 転送プロキシは、次の場合に一般的に使用されます。
- 外部リソースへのアクセスを制御します。
- クライアント トラフィックを匿名化します。
- 監視のために送信トラフィックをログに記録します。
- コンテンツのフィルター処理または変換を適用します。
リバース プロキシ
リバース プロキシは 、サーバーの前に配置されます。 クライアントは、基になるバックエンド インフラストラクチャを認識されません。 リバース プロキシは受信要求を受信し、複数のバックエンド サーバーのいずれかに転送します。 リバース プロキシは、次の場合に一般的に使用されます。
- 複数のサービス間でトラフィックを負荷分散します。
- バックエンドの負荷を軽減するために、キャッシュされた応答を提供します。
- TLS/SSL 接続を終了します。
- パブリック インターネットから内部サービスの詳細を非表示にします。
透過的なプロキシ
透過的なプロキシは、クライアントがそれを使用するように明示的に構成されずにトラフィックをインターセプトします。 この種類は、ポリシーを適用したり使用状況を監視したりするために、企業またはインターネット サービス プロバイダー環境で使用されます。
プロキシがアプリケーション開発者にとって重要な理由
多くの場合、インフラストラクチャまたはネットワーク チームがプロキシを管理します。 ただし、プロキシは、特に開発環境およびテスト環境でのアプリケーションの動作に直接影響します。 ここでは、日常業務に影響を与える実用的な方法をいくつか紹介します。
デバッグと監視
プロキシは、HTTP トラフィックをキャプチャして検査できます。 Dev Proxy、Fiddler、Proxyman、Charles Proxy、mitmproxy などのツールは、ローカル 転送プロキシとして機能します。 それらを通じてアプリケーションを実行することで、要求と応答を分析し、エラーを見つけ、ヘッダーや認証トークンを検証することができます。
API ゲートウェイとルーティング
多くの運用システムでは、アプリケーションのバックエンドへのトラフィックは、API ゲートウェイまたはリバース プロキシ (NGINX など) または Azure API Management などのクラウドネイティブ サービスを介してルーティングされます。 これらのプロキシは、ルーティング、認証、レート制限などを処理します。
API を設計したり、分散サービスを構築したりする場合は、プロキシがヘッダー ( X-Forwarded-For
など)、タイムアウト、要求サイズの制限にどのように影響するかを理解する必要があります。
CORS とローカル開発
ローカル開発時、特に Web アプリケーションでは、ブラウザーから API を呼び出すときにクロスオリジン リソース共有 (CORS) の制限が発生する可能性があります。 開発プロキシは、CORS 制限をバイパスするためにヘッダーを書き換えながら、要求をターゲット API に転送できます。 CORS 要求を書き換える開発者ツールの一般的な例は、Express や ASP.NET Core などのフレームワークで vite
、webpack-dev-server
、またはカスタム プロキシ ミドルウェアです。
サービスの仮想化とテスト
プロキシはバックエンド API をシミュレートできます。 この機能は、実際のサービスが使用できない、不安定な、またはテスト中に使用するコストが高い場合に便利です。 応答をインターセプトしてモック化することで、タイムアウト、エラー、形式が正しくないデータなど、さまざまなシナリオでアプリケーションの動作をテストできます。
開発プロキシやカスタム プロキシの実装などのツールは、統合テストやエンド ツー エンド テストでこの目的でよく使用されます。
認証とセキュリティ
プロキシは、多くの場合、アプリケーションのセキュリティ保護の最前線です。 アクセス制御を適用したり、認証ヘッダーを挿入したり、TLS/SSL 接続を終了したりすることができます。 開発者は、アプリケーションがプロキシの背後にある場合の動作と、認証または ID 情報を伝達するヘッダーにアクセスする方法を認識することが重要です。
ヘッダーとプロキシに関する一般的な考慮事項
要求がプロキシを通過すると、重要なメタデータを保持するために特定のヘッダーが追加または変更されます。 例えば:
-
X-Forwarded-For
: クライアントの元の IP アドレスを示します。 -
X-Forwarded-Proto
: 元のプロトコル (HTTP または HTTPS) を示します。 -
X-Forwarded-Host
: クライアントによって要求された元のホストを示します。
アプリケーションがリバース プロキシの背後で実行されている場合は、これらのヘッダーを正しく信頼して解釈するようにフレームワークまたはプラットフォームが構成されていることを確認します。
開発およびテスト用の前方プロキシとしての開発プロキシ
開発プロキシは、アプリケーションから任意のターゲット サーバーへの要求をインターセプトして変更するために使用できる転送プロキシです。 開発プロキシを使用すると、次のことができます。
- アプリが API エラーにどのように応答するかを確認します。
- アプリで API レートの制限を処理する方法を確認します。
- アプリが低速 API を処理する方法を確認します。
- コード行を記述することなく、モック API をすばやく立ち上げる。
- API の使用方法に関するコンテキスト ガイダンスを使用して、アプリを改善します。
次のステップ
Dev Proxy