API Gateway:FAQ

クラウドネイティブ API Gateway は IPv6 をサポートしていますか?

はい、クラウドネイティブ API Gateway は IPv6 をサポートしています。

クラウドネイティブ API Gateway は x-forwarded-for リクエストヘッダーをサポートしていますか?

はい、クラウドネイティブ API Gateway は x-forwarded-for リクエストヘッダーをサポートしています。

元の要求に x-forwarded-for ヘッダーが含まれている場合、ゲートウェイは前のホップの IP アドレスをリクエストヘッダーに追加します。元の要求に x-forwarded-for ヘッダーが含まれていない場合、ゲートウェイはヘッダーを要求に追加し、前のホップの IP アドレスをリクエストヘッダーに書き込みます。

クラウドネイティブ API Gateway インスタンスがリクエストを転送するときに「upstream connect error or disconnect/reset header」が報告された場合はどうすればよいですか?

この問題は、バックエンドサービスのセキュリティグループがゲートウェイインスタンスによるサービスポートへのアクセスを許可していないために発生します。

インスタンスが対応する Container Service for ACK (ACK) ポッドにリクエストを転送できるようにするセキュリティグループルールを追加することで、この問題を解決できます。セキュリティグループルールを追加するには、インスタンスの [概要] ページに移動し、[セキュリティグループの承認] タブをクリックしてから、[セキュリティグループルールの追加] をクリックします。セキュリティグループルールでは、ポッドに必要なポートを開く必要があることに注意してください。

ヘッダーを使用してドメイン名を照合するにはどうすればよいですか?

ルートを作成するときに、ヘッダー照合ルールを追加できます。

ルールを構成するときは、ヘッダー名フィールドを authority に設定し、ヘッダー値を照合するドメイン名に設定します。

リクエスト本文が大きすぎることを示すエラーが報告された場合はどうすればよいですか?

この問題は、ゲートウェイの接続バッファのサイズが小さすぎるために発生します。バッファサイズを増やすことで、この問題を解決できます。

• プロトコルが HTTP 1.x の場合は、コンソールで DownstreamConnectionBufferLimits パラメーターの値を増やします。

• プロトコルが HTTP 2.0 の場合は、コンソールで DownstreamConnectionBufferLimits パラメーターと InitialStreamWindowSize パラメーターの値を増やします。

クラウドネイティブ API Gateway でサービスを作成するために使用できるソースは何個ですか?

• 1 つのゲートウェイインスタンスは、最大 3 つの ACK クラスタに関連付けることができます。

• 1 つのゲートウェイインスタンスは、1 つの Nacos インスタンスのみに関連付けることができます。

既存の Nacos インスタンスまたは ACK クラスタをサービスを作成するためのソースとして選択できないのはなぜですか?

ゲートウェイインスタンスと同じ VPC (Virtual Private Cloud) の Nacos インスタンスまたは ACK クラスタのみをサービスソースとして選択できます。

クラウドネイティブ API Gateway は自分で準備した HTTPS 証明書をサポートしていますか?

クラウドネイティブ API Gateway は証明書をホストしません。代わりに、Alibaba Cloud 証明書管理サービスから証明書を取得します。証明書管理サービス に証明書をアップロードし、ゲートウェイインスタンスのドメイン名設定で証明書を構成できます。

コンソールのパラメーター変更は既存のビジネスにどのように影響しますか?

• XffTrustedNum の変更は、ゲートウェイインスタンスを再起動した後に有効になります。

• UpstreamIdleTimeout の変更により、アップストリーム接続が切断され、再接続されます。

• DownstreamIdleTime の変更により、ダウンストリーム接続が切断され、再接続されます。

作成したバックエンドサービスのヘルスステータスが異常な場合はどうすればよいですか?

ゲートウェイインスタンスがバックエンドサービスにリクエストを転送できるようにするには、ゲートウェイインスタンスがバックエンドサービスに接続されていることを確認する必要があります。バックエンドサービスのヘルスステータスが異常な場合は、次の操作を実行して問題のトラブルシューティングを行ってください。

• VPC 内の内部向けサービスの場合は、バックエンドサービスのセキュリティグループがゲートウェイインスタンスによる関連ポートへのアクセスを許可しているかどうかを確認します。セキュリティグループルールの構成方法の詳細については、「セキュリティグループルールを構成する」をご参照ください。

• インターネット向けサービスの場合は、VPC がインターネットにアクセスできるかどうかを確認します。インターネット NAT ゲートウェイのセキュアネットワークアドレス変換 (SNAT) 機能を有効にして、インターネットにアクセスしてみてください。詳細については、「インターネット NAT ゲートウェイの SNAT 機能を使用してインターネットにアクセスする」をご参照ください。

• HTTP ヘルスチェックの場合は、リクエストパスとリクエストドメインが正しく構成されているかどうかを確認します。

• HTTP ヘルスチェックの場合、バックエンドサービスのヘルスチェックインターフェイスに HTTPS 経由でアクセスする必要がある場合は、[ポリシー] でバックエンドサービスに対して [一方向 TLS (transport Layer Security)] を有効にします。

• HTTP ヘルスチェックの場合、上記の構成がすべて正しい場合、問題はヘルスチェック間隔がバックエンド接続の保持期間と同じであることが原因である可能性があります。この場合は、ヘルスチェック間隔を長くしてみてください。

リクエストエラーの原因を特定するにはどうすればよいですか?

• レスポンスに x-envoy-upstream-service-time ヘッダーが含まれているかどうかを確認します。レスポンスに x-envoy-upstream-service-time ヘッダーが含まれている場合、ゲートウェイインスタンスはリクエストを処理するためにバックエンドサービスに転送しており、エラーはバックエンドサービスのロジックに起因する可能性があります。

• ゲートウェイインスタンスのアクセスログで upstream_service_time フィールドが空かどうかを確認します。upstream_service_time フィールドが空でない場合、ゲートウェイインスタンスはリクエストを処理するためにバックエンドサービスに転送しており、エラーはバックエンドサービスのロジックに起因する可能性があります。

クラウドネイティブ API Gateway で更新した HTTPS 証明書が有効にならない場合はどうすればよいですか?

この問題は、ゲートウェイインスタンスに接続されている前のノードに HTTPS 証明書が構成されているために発生します。このようなノードは、Classic Load Balancer (CLB) のインスタンス、Dynamic Content Delivery Network (DCDN)、Web Application Firewall (WAF) インスタンス、または Anti-DDoS Proxy サービスのインスタンスである可能性があります。接続されているノードの HTTPS 証明書が更新されているかどうかを確認します。ベストプラクティスに基づいて、1 つのノードにのみ HTTPS 証明書を構成することをお勧めします。DCDN または WAF がゲートウェイインスタンスに接続されている場合は、DCDN または WAF にのみ HTTPS 証明書を構成し、ゲートウェイインスタンスには HTTP を使用します。

クラウドネイティブ API Gateway ではルートはどのように優先順位付けされますか?

ゲートウェイインスタンスの [ルート設定] ページでは、ルートは優先順位の高い順に表示されます。照合の優先順位は、ドメイン名またはルーティングルールに基づいて決定されます。[正確なドメイン名] は、[ワイルドカードドメイン名] よりも優先順位が高くなります。たとえば、test.example.com は *.example.com よりも優先順位が高くなります。同じドメイン名に属するパスについては、[完全一致] は 完全一致[プレフィックス一致] よりも優先順位が高く、[正規表現の一致]より多くの条件に一致するもの一致条件が少ないもの は よりも優先順位が高くなります。リクエストのドメイン名とパスが同じ場合は、 が よりも優先されます。一致条件は、リクエストの Herder セクションと Query セクションに含まれています。

DCDN がクラウドネイティブ API Gateway の前にある場合、HTTPS リクエストが失敗するのはなぜですか?

この問題は、DCDN がゲートウェイに送信されるオリジン復帰リクエストにサーバ名表示 (SNI) を含めないために発生します。この場合は、DCDN のオリジン復帰構成に SNI を追加します。

WAF がクラウドネイティブ API Gateway の前にある場合、HTTPS リクエストが失敗するのはなぜですか?

この問題は、WAF がゲートウェイに送信されるオリジン復帰リクエストに SNI を含めないために発生します。正規名 (CNAME) レコードモードで WAF に Web サイトを追加する場合は、[web サイト情報の入力] ステップで [オリジン SNI を有効にする] を選択します。

クラウドネイティブ API Gateway は WebSocket をサポートしていますか?

はい、WebSocket はクラウドネイティブ API Gateway でサポートされており、デフォルトで有効になっています。

クラウドネイティブ API Gateway は gRPC をサポートしていますか?

はい、クラウドネイティブ API Gateway は gRPC をサポートしています。gRPC は HTTP/2 を使用してデータを送信します。[パラメーター設定] ページで EnableHttp2 = true 構成が指定されていることを確認します。

クラウドネイティブ API Gateway は GZIP 展開をサポートしていますか?

はい、クラウドネイティブ API Gateway は GZIP 展開をサポートしています。[パラメーター設定] ページで EnableGzip = true 構成が指定されていることを確認します。圧縮アルゴリズム gzip と Brotli がサポートされています。ZipAlgorithm パラメーターを指定して、圧縮アルゴリズムを構成できます。デフォルトでは、ZipAlgorithm パラメーターは gzip に設定されています。

クラウドネイティブ API Gateway はリクエストヘッダーとレスポンスヘッダーの大文字と小文字のステータスの保持をサポートしていますか?

はい、リクエストヘッダーとレスポンスヘッダーでは、大文字と小文字をそのまま保持できます。ゲートウェイインスタンスの [パラメーター設定] ページで PreserveHeaderFormat = true 構成が指定されていることを確認します。PreserveHeaderFormat パラメーターは、HTTP 1.0 または 1.1 が使用されている場合にのみ有効になります。HTTP/2 プロトコルでは、すべてのリクエストヘッダーとレスポンスヘッダーを小文字にする必要があります。

クラウドネイティブ API Gateway は HTTP/3 をサポートしていますか?

はい、クラウドネイティブ API Gateway は HTTP/3 をサポートしています。ゲートウェイインスタンスの [パラメーター設定] ページで EnableHttp3 = true 構成が指定されていることを確認します。

クラウドネイティブ API Gateway に渡された後、すべてのリクエストヘッダーとレスポンスヘッダーが小文字になるのはなぜですか?

デフォルトでは、クラウドネイティブ API Gateway はすべてのリクエストヘッダーとレスポンスヘッダーを小文字に変換します。元のケースステータスを保持する場合は、[パラメーター設定] ページで PreserveHeaderFormat = true 構成を指定します。

インスタンスに DNS ドメイン名を構成した後、クラウドネイティブ API Gateway インスタンスがインターネットにアクセスできないのはなぜですか?

構成されたドメインネームシステム (DNS) ドメイン名がパブリックドメイン名である場合は、NAT ゲートウェイの SNAT を有効にして、ゲートウェイがインターネットにアクセスできるようにします。デフォルトでは、ゲートウェイはインターネットにアクセスできません。

クラウドネイティブ API Gateway でトレース分析が有効になっていますが、ARMS コンソールでのトレース情報の検索で結果が得られません。なぜですか?

ゲートウェイの構成で EnableGenerateRequestId が true に設定されているかどうかを確認します。false の場合は、準拠した x-request-id ヘッダーをリクエストに追加する必要があります。そうしないと、request-id 情報がないため、ゲートウェイインスタンスはトレース情報を報告できません。

リクエストに対して 400 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• クライアントがリクエストを送信したときにプロトコルエラーが発生しました。ゲートウェイインスタンスのアクセスログを表示します。ログに response_flags = DPE が見つかった場合、問題はプロトコルエラーが原因です。

• バックエンドサービスからステータスコード 400 が返されました。ゲートウェイインスタンスのアクセスログを表示します。response_flags が空であるが upstream_host に値がある場合、ステータスコード 400 はバックエンドサービスによって返され、ゲートウェイによって転送されたリクエスト内のバックエンド IP アドレスは upstream_host で指定された IP アドレスです。

リクエストに対して 401 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• 必要なアクセス資格情報がありません。この場合、エラーはクラウドネイティブ API Gateway によって返されます。認証機能または WebAssembly プラグインが有効になっているかどうかを確認します。

• エラーはバックエンドサービスによっても返される可能性があります。ゲートウェイインスタンスのアクセスログを確認します。response_flags が空であるが upstream_host に値がある場合、ステータスコード 401 はバックエンドサービスによって返され、ゲートウェイによって転送されたリクエスト内のバックエンド IP アドレスは upstream_host で指定された IP アドレスです。

リクエストに対して 403 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• クライアントに必要な権限がありません。この場合、エラーはクラウドネイティブ API Gateway によって返されます。IP アドレスのブラックリストまたはホワイトリスト、認証機能、または WebAssembly プラグインが有効になっているかどうかを確認します。

• エラーはバックエンドサービスによっても返される可能性があります。ゲートウェイのアクセスログを表示します。response_flags が空で upstream_host に値がある場合、ステータスコード 403 はバックエンドサービスによって返され、ゲートウェイによって転送されたリクエスト内のバックエンド IP アドレスは upstream_host で指定された IP アドレスです。

リクエストに対して 404 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• クラウドネイティブ API Gateway に対応するルーティングルールが構成されていません。ゲートウェイのアクセスログを表示します。ログに response_flags = NR が見つかった場合、ルーティングルールは構成されていません。

• エラーはバックエンドサービスによっても返される可能性があります。ゲートウェイのアクセスログを表示します。response_flags が空であるが upstream_host に値がある場合、ステータスコード 404 はバックエンドサービスによって返され、ゲートウェイによって転送されたリクエスト内のバックエンド IP アドレスは upstream_host で指定された IP アドレスです。

リクエストに対して 405 エラーが返されるのはなぜですか?

WAF 保護が有効になっており、リクエストが WAF 保護ルールにヒットした場合、ステータスコードは WAF によって返されます。

リクエストに対して 413 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• リクエストサイズがゲートウェイインスタンスの接続キャッシュのサイズを超えています。この場合、[パラメーター設定] ページで DownstreamConnectionBufferLimits パラメーターの値を増やす必要があります。

• エラーはバックエンドサービスによっても返される可能性があります。ゲートウェイのアクセスログを表示します。response_flags が空であるが upstream_host に値がある場合、ステータスコード 413 はバックエンドサービスによって返され、ゲートウェイによって転送されたリクエスト内のバックエンド IP アドレスは upstream_host で指定された IP アドレスです。

リクエストに対して 429 エラーが返されるのはなぜですか?

ゲートウェイインスタンスの速度制限ルールがトリガーされています。ゲートウェイのアクセスログを表示します。ログに response_flags = RL が見つかった場合は、ゲートウェイインスタンスの速度制限ルールを確認します。

リクエストに対して 502 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• バックエンドサービスによって返されたリクエストプロトコルエラー。ゲートウェイのアクセスログを表示します。ログに response_flags = UPE が見つかった場合、最も一般的な原因は、バックエンドサービスによって返されたヘッダーに重複する Transfer-Encoding フィールドが含まれていることです。この場合は、バックエンドサービスを確認します。

• バックエンドサービスからステータスコード 502 が返されました。ゲートウェイのアクセスログを表示します。response_flags が空であるが upstream_host に値がある場合、ステータスコード 502 はバックエンドサービスによって返され、ゲートウェイによって転送されたリクエスト内のバックエンド IP アドレスは upstream_host で指定された IP アドレスです。

リクエストに対して 503 エラーが返されるのはなぜですか?

この問題は、次の原因で発生する可能性があります。

• ゲートウェイインスタンスのルーティングルールで指定された宛先サービスに正常な IP アドレスがありません。ゲートウェイのアクセスログを表示します。ログに response_flags = UH が見つかった場合、宛先サービスで使用できる正常な IP アドレスがありません。

• ゲートウェイインスタンスがリクエストを転送するときに、バックエンドサービスによって接続が閉じられます。ゲートウェイのアクセスログを表示します。ログに response_flags = UC が見つかった場合、バックエンドサービスの idle timeout 値は、ゲートウェイに指定された UpstreamIdleTimeout の値よりも小さくなっています。この場合は、ゲートウェイインスタンスの [パラメーター設定] ページで UpstreamIdleTimeout を小さい値に設定します。

• バックエンドサービスの IP アドレスにゲートウェイからアクセスできません。ゲートウェイのアクセスログを表示します。ログに response_flags = UF または response_flags = URX が見つかった場合、バックエンドサービスのセキュリティグループはゲートウェイからのアクセスを許可していません。バックエンドサービスのセキュリティグループがゲートウェイによるポートへのアクセスを許可しているかどうかを確認します。セキュリティグループルールの構成方法の詳細については、「セキュリティグループルールを構成する」をご参照ください。

• ゲートウェイインスタンスがバックエンドサービスに関連付けられていません。ゲートウェイのアクセスログを表示します。ログに response_flags = NC が見つかった場合、問題は次の原因で発生する可能性があります。

  • サービスは存在しません。

  • バックエンドサービスの動的ポートが選択されています。バックエンドサービスに複数のポートがある場合は、ルート設定の宛先サービスを選択するときに、動的ポートではなく固定ポートを選択する必要があります。

  • バックエンドサービスによって固定ポートが選択されていますが、サービスポートが変更されています。

• バックエンドサービスからステータスコード 503 が返されました。ログの response_flags が null であるが upstream_host が null でない場合、バックエンドサービスは 503 を返し、ゲートウェイによって転送された特定のバックエンド IP アドレスは upstream_host のコンテンツです。

ログの response_code 値が 0 の場合はどうすればよいですか?

response_code 値が 0 の場合、クライアントは response code を受信していません。

この問題は、次の原因で発生する可能性があります。

• レスポンスコードを受信する前に、クライアントが接続を閉じました。この問題は、ネットワーク信号が弱い、バックエンドでの応答が遅いなどのシナリオで発生します。ログで response_flags フィールドの値が DC かどうかを確認できます。

• HTTPS リクエストにサーバ名表示 (SNI) が含まれておらず、アスタリスク (*) で始まるワイルドカードドメイン名に HTTPS 証明書が構成されていません。SNI は Transport Layer Security (TLS) プロトコルの拡張機能であり、ドメイン名情報を伝達するために使用されます。ログで requested_server_name フィールドが空かどうかを確認できます。