APIゲートウェイ・サービスを使用してAPIゲートウェイおよびAPIデプロイメントを正常に作成し、APIのコール時にHTTPバックエンドに送信される転送済およびホスト関連のヘッダーをトラブルシューティングする方法をご紹介します。
このトピックを使用して、HTTPバック・エンドがAPIゲートウェイを介して受信する転送およびホスト関連のヘッダーをトラブルシューティングします。ヘッダー値は、リダイレクト、URL生成、アクセス制御ロジックおよびアプリケーション・ルーティングに影響する可能性があります。
API Gatewayは、いくつかの転送ヘッダーを追加し、クライアントが提供する値を保持し、いくつかのヘッダー・チェーンに値を付加し、バックエンド・ターゲットのHostヘッダーをリライトします。アプリケーション・ロジックまたはデプロイメント構成を変更する前に、バックエンドが受信するヘッダーを確認します。
次の症状が1つ以上表示される場合があります。
バックエンド・サービスにはForwarded: host=<client-hostname>が必要ですが、値が欠落しています。
バックエンド・サービスは、Forwarded: for=...エントリのみを受信します。
バックエンド・サービスは、クライアント対応ホスト名ではなく、Hostヘッダーでバックエンド・ターゲットのホスト名を受信します。
リダイレクト、生成されたURLまたはホストベースのアクセス制御ロジックは、APIがAPIゲートウェイの背後に配置された後、動作が異なります。
バックエンド・サービスは複数のForwardedまたはX-Forwarded-For値を受け取り、アプリケーションは1つの値のみを処理します。
転送されたヘッダーとホストヘッダーの不一致は、次の理由で発生する可能性があります。
アプリケーションではForwarded: host=...またはForwarded: proto=...が必要ですが、APIゲートウェイではデフォルトでfor=...エントリのみが追加されます。
アプリケーションはHostヘッダーを読み取りますが、APIゲートウェイはバックエンド・ターゲットのそのヘッダーをリライトします。
アプリケーションは単一の転送値を想定していますが、リクエストには転送チェーンが含まれています。
デプロイメントには、クライアント対応ホストをバック・エンドに渡すリクエスト・ヘッダー変換は含まれません。
HTTPバック・エンドの場合、APIゲートウェイはクライアントIP情報を含むリクエスト・ヘッダーを追加します。
バックエンドへのリクエストには、次のヘッダーを含めることができます。
X-Real-IP
Forwarded
X-Forwarded-For
User-Agent: Oracle API Gateway
デフォルトのForwarded値はfor=...エントリです。APIゲートウェイは、host=...またはproto=...値をForwardedヘッダーに自動的に追加しません。
クライアントが既存の転送ヘッダーを送信する場合、API Gatewayはこれらの値を保持し、独自のクライアントIP情報を追加します。したがって、バックエンドはForwardedまたはX-Forwarded-For値のチェーンを受信できます。
HTTPバック・エンドの場合、バック・エンドへのリクエストのHostヘッダーは、デフォルトでは元のクライアント対応ホストではありません。APIゲートウェイは、バックエンド・ターゲットのHostヘッダーをリライトします。
アプリケーションでクライアント対応ホストが必要な場合は、受信したHost値をアプリケーションが読み取るヘッダーにコピーするリクエスト・ヘッダー変換を構成します。たとえば、request.hostコンテキスト変数を使用して、受信ホストをX-Forwarded-Hostまたはアプリケーション固有のヘッダーにコピーします。
外部ホスト名を保持するために、バックエンド・リクエストのHostヘッダーに依存しないでください。
APIゲートウェイを介してリクエストを繰り返し、バックエンドが受信するヘッダーを調べます。
次のヘッダー値をレビューします。
バックエンドの可視Forwardedヘッダー。
バックエンドの可視X-Forwarded-Forヘッダー。
バックエンドの可視Hostヘッダー。
ルートがそのヘッダーを使用する場合、バックエンドで表示されるX-Forwarded-Hostヘッダー。
デプロイメントが着信Host値から作成するカスタム・ヘッダー。
可能な場合は、リクエスト・ヘッダーをエコーする一時エンドポイントを使用します。エコーされたレスポンスには、バックエンドに到着したヘッダー値が表示されます。
APIゲートウェイのAPIデプロイメント構成を確認して、一致するルートおよびそのルート上のリクエスト・ヘッダー変換を識別します。
次の構成値を確認します。
ルートのbackend.url値。
リクエストに一致したroutes.path値。
リクエスト・ヘッダーは、一致するルートで変換されます。
バックエンドがクライアント側ホスト名に依存している場合は、受信したHost値をバックエンドが読み取ることができるヘッダーにルートがコピーすることを確認します。
バック・エンドがForwarded: host=...に依存している場合は、独自のヘッダー戦略によってその値が設定されていることを確認します。APIゲートウェイによって値が自動的に作成されるとは想定しないでください。
バックエンドに必要なヘッダー値と一致する修正を適用します。
バック・エンドでX-Forwarded-Hostを使用できる場合は、そのヘッダーを送信するようにルートを構成し、それを読み取るようにアプリケーションを更新します。
バック・エンドでカスタム・ヘッダーにクライアント対応ホストが必要な場合は、受信したHost値からリクエスト・ヘッダー変換を作成します。
バックエンドでForwarded: host=...が想定される場合は、API Gatewayが提供するヘッダーを使用するようにアプリケーションを更新するか、アプリケーションが消費できる明示的なヘッダー戦略を追加します。
バックエンドが1つのForwardedまたはX-Forwarded-For値のみを解析する場合は、転送チェーンを処理するようにアプリケーションを更新します。
デプロイメントまたはアプリケーション・ロジックを更新した後、リクエストを繰り返して結果を確認します。
次の結果を確認します。
バック・エンドは、構成済ヘッダーにクライアント対応の予期されるホスト値を受信します。
バックエンドは、複数のForwardedまたはX-Forwarded-For値を正しく処理します。
リダイレクト、生成されたURLおよびホストベースのロジックでは、予想されるホスト名とスキームが使用されます。
ホストベースのアクセス制御ロジックは、予期されるレスポンスを返します。
詳細は、次を参照してください: