プロキシとは

プロキシは、クライアント (アプリケーションなど) と移行先サーバー (バックエンド 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 障害にどう対応するかをテストする

転送プロキシは、アプリが送信するすべての要求を確認するため、一部の要求には、転送する代わりにエラーで回答する可能性もあります: 500、Retry-After ヘッダーを含む 429 Too Many Requests、または 8 秒かかる応答。 アプリは実際の API URL を呼び出し続けるので、HTTP クライアント、SDK、再試行ポリシーなども含めて、本番環境で動作するときと同じ形でアプリをテストします。

API エラーをテストする他の方法と比較した場合:

開発およびテスト用の前方プロキシとしての開発プロキシ

Dev Proxy は、アプリケーションから選択した API への要求をインターセプトして変更するために、マシン上または CI で実行する転送プロキシです。 開発プロキシを使用すると、次のことができます。

• アプリが API エラーにどのように応答するかを確認します。
• アプリで API レートの制限とスロットリングがどのように処理されるかを確認します。
• アプリが低速 API を処理する方法を確認します。
• コードを 1 行も作成せずにモック API を構築します。
• API の使用方法に関する文脈に応じたガイダンスを利用できます。

アプリが呼び出す API で試すには、プリセットをダウンロードし、それを使用して Dev Proxy を起動してください。 たとえば、GitHubの場合:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

プリセットは、OpenAI (openai-throttling)、Anthropic (anthropic-throttling)、および Microsoft Graph の OneDrive エンドポイントと SharePoint エンドポイント (microsoft-graph-rate-limiting) でも使用できます。

実際に試してみる

構築しているものと一致するシナリオを選択します。

• アプリがAPIエラーをどのように処理するかをテストする (5 分)
• 任意の API でレート制限をシミュレート する (10 分)
• コードを変更せずに API 応答をモックする (10 分)
• 開発中に OpenAI の代わりにローカル モデルを使用する (15 分)

次のステップ