API Gateway:よくある質問

Cloud-native API Gateway は IPv6 をサポートしていますか？

はい。

Cloud-native API Gateway は x-forwarded-for リクエストヘッダーをサポートしていますか？

はい。

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

"upstream connect error or disconnect/reset header" エラーの解決

このエラーは、バックエンドサービスのセキュリティグループがゲートウェイインスタンスからのアクセスをブロックしていることを示します。

これを解決するには、ゲートウェイインスタンスの [概要] ページに移動し、Security Group Authorizations タブをクリックしてから、Add Security Group Rule をクリックしてセキュリティグループルールを追加します。ゲートウェイはリクエストを Container Service for Kubernetes (ACK) の Pod IP アドレスに直接転送するため、セキュリティグループルールで Pod が使用するポートを開く必要があります。

ヘッダーを使用したドメイン名の一致

ルートを作成する際に、リクエストヘッダーのマッチングルールを追加します。

ヘッダーフィールド名を「:authority」に、ヘッダー値を特定のドメイン名に設定します。

リクエストボディが大きいために発生するリクエスト失敗の解決

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

• HTTP/1.x を使用する場合：コンソールで DownstreamConnectionBufferLimits パラメーターを調整します。

• HTTP/2 を使用する場合：コンソールで DownstreamConnectionBufferLimits と InitialStreamWindowSize パラメーターを調整します。

サービスソース追加の制限

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

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

既存の Nacos または ACK サービスソースを選択できない

Cloud-native API Gateway は、同じ VPC 内にある Nacos インスタンスまたは ACK クラスターのみを追加できます。

Cloud-native API Gateway はカスタム HTTPS 証明書をサポートしていますか？

Cloud-native API Gateway は証明書を直接ホストしません。代わりに、Alibaba Cloud の Certificate Management Service から取得します。証明書を Certificate Management Service にアップロードし、ゲートウェイでドメイン名に対して設定します。

パラメーター変更が既存のトラフィックに与える影響

• XffTrustedNum への変更を有効にするには、ゲートウェイの再起動が必要です。

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

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

バックエンドサービスのヘルスチェックステータスの異常

ヘルスチェックステータスの異常には、いくつかの原因が考えられます：

• VPC 内のプライベートサービスの場合、バックエンドサービスのセキュリティグループが、ゲートウェイからの必須ポートへのアクセスを許可しているかを確認してください。詳細については、「セキュリティグループルールを追加」をご参照ください。

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

• HTTP ベースのヘルスチェックの場合、リクエストパスとリクエストドメインが正しく設定されていることを確認してください。

• HTTP ベースのヘルスチェックの場合、バックエンドサービスのヘルスチェックエンドポイントへのアクセスに HTTPS が必要な場合は、Policy Configuration でサービスのポリシーを TLS モードに設定してください。

• HTTP ベースのヘルスチェックの場合、上記のすべての設定が正しいにもかかわらず問題が解決しない場合は、ヘルスチェック間隔がバックエンドサービスの接続キープアライブ時間と同じであることが原因である可能性があります。ヘルスチェック間隔を長くしてみてください。

リクエストエラーの原因特定

• レスポンスヘッダーに x-envoy-upstream-service-time が含まれているかを確認してください。含まれている場合、ゲートウェイはすでにリクエストをバックエンドサービスに転送しています。エラーはバックエンドサービスから発生している可能性が高いです。

• ゲートウェイのアクセスログの upstream_service_time フィールドが空かどうかを確認してください。フィールドが空でない場合、ゲートウェイはすでにリクエストをバックエンドサービスに転送しています。エラーはバックエンドサービスから発生している可能性が高いです。

更新された HTTPS 証明書が有効にならない

この問題は通常、CLB、DCDN、WAF、Anti-DDoS Proxy など、ゲートウェイの上流にあるサービスにも HTTPS 証明書が設定されている場合に発生します。上流サービスの証明書も更新されているかを確認してください。ベストプラクティスとして、HTTPS 証明書は 1 箇所でのみ設定することを推奨します。上流に DCDN や WAF がデプロイされている場合、DCDN や WAF でのみ HTTPS を設定し、ゲートウェイへのバックツーオリジンリクエストに HTTP を使用できます。

ルートの優先順位

ゲートウェイインスタンスの ルーティング設定 ページでは、リスト内のルートの順序が優先順位を表しており、上にあるものほど優先度が高くなります。優先順位はドメインとルート ルールによって決まります。ドメインの一致優先度は、[完全なドメイン名] > [ワイルドカードドメイン名] です。たとえば、test.example.com は *.example.com よりも優先度が高くなります。同じドメインの場合、パスの一致優先度は、[Exact Match] > [Prefix Match] > [Match Regular Expression] です。同じドメインとパスの場合、[より多くのマッチング条件]を持つルールが、[より少ないマッチング条件]を持つルールよりも優先されます (マッチング条件には、ヘッダーとクエリパラメーターが含まれます)。

DCDN を使用した場合の HTTPS リクエストの失敗

この問題は通常、DCDN がゲートウェイへのバックツーオリジンリクエストにサーバー名表示 (SNI) を含んでいないために発生します。これを解決するには、DCDN の設定でオリジン SNI を設定します。

WAF を使用した場合の HTTPS リクエストの失敗

この問題は通常、WAF がゲートウェイへのバックツーオリジンリクエストにサーバー名表示 (SNI) を含んでいないために発生します。WAF で CNAME アクセスモードを使用している場合は、対応するドメインの設定を変更します。[ウェブサイト情報の入力] ステップで、[オリジン SNI を有効にする] を選択します。

Cloud-native API Gateway は WebSocket をサポートしていますか？

はい、WebSocket はサポートされており、デフォルトで有効になっています。

Cloud-native API Gateway は gRPC をサポートしていますか？

はい。gRPC はトランスポートプロトコルとして HTTP/2 を使用します。ゲートウェイの [パラメータ設定] ページで EnableHttp2 = true が設定されていることを確認してください。

Cloud-native API Gateway は GZIP 展開をサポートしていますか？

はい。ゲートウェイの [パラメータ設定] ページで EnableGzip = true が設定されていることを確認してください。サポートされているアルゴリズムは Gzip と Brotli で、ZipAlgorithm パラメーターで設定します。デフォルトは Gzip です。

ヘッダーの大文字/小文字の維持

はい。ゲートウェイの [パラメータ設定] ページで PreserveHeaderFormat = true が設定されていることを確認してください。このパラメーターは HTTP/1.0 と HTTP/1.1 にのみ適用されます。HTTP/2 プロトコル仕様では、すべてのリクエストおよびレスポンスヘッダーを小文字にする必要があります。

Cloud-native API Gateway は HTTP/3 をサポートしていますか？

はい。ゲートウェイの [パラメータ設定] ページで EnableHttp3 = true が設定されていることを確認してください。

ヘッダーが小文字に変換される

デフォルトでは、ゲートウェイはすべてのリクエストおよびレスポンスヘッダーを小文字に変換します。元の大文字/小文字を維持するには、ゲートウェイの [パラメータ設定] ページで PreserveHeaderFormat = true を設定してください。

DNS ドメインサービスへのリクエストが失敗する

設定された DNS ドメインがパブリックドメインである場合、インターネットアクセスを有効にするために、インターネット NAT ゲートウェイで SNAT を設定する必要があります。デフォルトでは、ゲートウェイインスタンスはインターネットにアクセスできません。

Application Real-Time Monitoring Service (ARMS) コンソールでのトレース情報の欠落

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

400 エラーの受信

このエラーは通常、次のいずれかの理由で発生します：

• クライアントがプロトコルエラーのあるリクエストを送信しました。ゲートウェイのアクセスログで response_flags = DPE を確認してください。

• バックエンドサービスが 400 エラーを返しました。ゲートウェイのアクセスログを確認してください。response_flags フィールドが空で、upstream_host フィールドに値がある場合、バックエンドサービスが 400 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

401 エラーの受信

このエラーは通常、次のいずれかの理由で発生します：

• ゲートウェイがエラーを返しました。これはアクセス認証情報が不足していることを示します。認証、認可、または WebAssembly プラグインを有効にしているかを確認してください。

• バックエンドサービスが 401 エラーを返しました。ゲートウェイのアクセスログを確認してください。response_flags フィールドが空で、upstream_host フィールドに値がある場合、バックエンドサービスが 401 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

403 エラーの受信

このエラーは通常、次のいずれかの理由で発生します：

• ゲートウェイがエラーを返しました。これはアクセス権限が不十分であることを示します。IP アドレスブラックリストまたはホワイトリスト、認証、認可、または WebAssembly プラグインを有効にしているかを確認してください。

• バックエンドサービスが 403 エラーを返しました。ゲートウェイのアクセスログを確認してください。response_flags フィールドが空で、upstream_host フィールドに値がある場合、バックエンドサービスが 403 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

404 エラーの受信

このエラーは通常、次のいずれかの理由で発生します：

• ゲートウェイに一致するルート ルールが設定されていません。ゲートウェイのアクセスログを確認してください。ログに response_flags = NR が含まれている場合、ルートが見つからなかったことを示します。

• バックエンドサービスが 404 エラーを返しました。ゲートウェイのアクセスログを確認してください。response_flags フィールドが空で、upstream_host フィールドに値がある場合、バックエンドサービスが 404 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

405 エラーの受信

WAF 保護が有効になっている場合、リクエストが WAF 保護ルールをトリガーした可能性があります。この場合、WAF は 405 ステータスコードを返します。

413 エラーの受信

このエラーは通常、次のいずれかの理由で発生します：

• リクエストサイズがゲートウェイの接続バッファの制限を超えています。[パラメータ設定] ページで DownstreamConnectionBufferLimits パラメーターの値を増やしてください。

• バックエンドサービスが 413 エラーを返しました。ゲートウェイのアクセスログを確認してください。response_flags フィールドが空で、upstream_host フィールドに値がある場合、バックエンドサービスが 413 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

429 エラーの受信

ゲートウェイのスロットリングルールがトリガーされました。ゲートウェイのアクセスログを確認してください。ログに response_flags = RL が含まれている場合は、ゲートウェイのスロットリングルールを確認してください。

502 エラーの受信

このエラーは通常、次のいずれかの理由で発生します：

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

• バックエンドサービスが 502 エラーを返しました。ゲートウェイのアクセスログを確認してください。response_flags フィールドが空で、upstream_host フィールドに値がある場合、バックエンドサービスが 502 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

503 エラーの受信

このエラーは、次の理由で発生する可能性があります：

• ルート ルールで指定されたターゲットサービスに正常な IP アドレスがありません。ゲートウェイのアクセスログを確認してください。この状況は response_flags = UH で示されます。

• ゲートウェイがリクエストを転送している間に、バックエンドサービスが接続を閉じました。ゲートウェイのアクセスログを確認してください。この状況は response_flags = UC で示されます。これは、バックエンドサービスの接続 アイドルタイムアウト がゲートウェイの UpstreamIdleTimeout の値よりも小さいことが原因であることが多いです。ゲートウェイの [パラメータ設定] ページで UpstreamIdleTimeout の値を小さくしてください。

• ゲートウェイはバックエンドサービスの IP アドレスに接続できません。ゲートウェイのアクセスログを確認してください。この状況は response_flags = UF または response_flags = URX で示されます。これは、バックエンドサービスのセキュリティグループがゲートウェイからのアクセスをブロックしていることが原因であることが多いです。バックエンドサービスのセキュリティグループがゲートウェイのポートへのアクセスを許可するように設定されているかを確認してください。詳細については、「セキュリティグループルールを追加」をご参照ください。

• バックエンドサービスがゲートウェイの設定に存在しません。ゲートウェイのアクセスログを確認してください。この状況は response_flags = NC で示されます。これにはいくつかの理由が考えられます：

  • 対応するサービスが存在しなくなった。

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

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

• バックエンドサービスが 503 エラーを返しました。ログの response_flags フィールドが空で、upstream_host フィールドが空でない場合、バックエンドサービスが 503 エラーを返したことを示します。upstream_host の値は、リクエストを受信したバックエンドサービスの IP アドレスです。

アクセスログ内の response_code が 0 になる

response_code が 0 の場合は、クライアントがレスポンスを受信しなかったことを示します。

これは通常、次の 2 つの理由のいずれかで発生します：

• クライアントが接続を途中で切断しました。たとえば、モバイルネットワークが弱い、またはバックエンドのレスポンスが遅いなどの理由が考えられます。これは、アクセスログの response_flags = "DC" で示されます。

• サーバー名表示 (SNI) なしで HTTPS リクエストが送信され、ワイルドカードドメインに HTTPS 証明書が設定されていませんでした。SNI は、ドメイン名情報を運ぶ TLS 拡張機能です。これは、アクセスログの requested_server_name フィールドが空であることで示されます。

一致しないルートリクエストによるパブリックトラフィックの消費

はい。どのルートにも一致しないリクエストを含め、ゲートウェイを通過するすべてのリクエストはパブリックトラフィックを消費します。ゲートウェイは、リクエストを受信してレスポンスを送信するために依然としてトラフィックを使用します。

ゲートウェイのアクセスログで、次のフィールドを使用してトラフィック消費量を確認できます：

• bytes_received：リクエストボディのサイズ。インバウンドトラフィックを表します。

• bytes_sent：レスポンスボディのサイズ。アウトバウンドトラフィックを表します。

ルートに一致しないリクエストは、アクセスログで response_code_details の値が route_not_found、response_flags の値が NR であることで識別できます。

一致しないルートリクエストのソースの追跡

ゲートウェイのログ配信を有効にすると、Log Service で一致しないリクエストをクエリし、ログフィールドを使用してソース IP アドレスを特定できます。アクセスログには、失敗したリクエストを含むすべてのリクエストが記録されます。ソース IP アドレスは downstream_remote_address フィールドにあります。

Log Service で、次のようなクエリを実行して、一致しないリクエストをフィルタリングしてください：

response_code_details: "route_not_found"

クエリ結果で、次のフィールドを確認してリクエストソースを特定してください：

• downstream_remote_address：ゲートウェイに接続したクライアントのアドレス。

• x-forwarded-for：HTTP リクエストヘッダーの x-forwarded-for フィールド。リクエストの元のソース IP アドレスを示します。リクエストがプロキシを通過する場合、このフィールドには複数の IP アドレスが含まれることがあります。最後の IP アドレスは、ゲートウェイの前のホップのアドレスです。

これらの異常なリクエストのトラフィック消費量を計算するには、Log Service で次のクエリを実行してください：

response_code_details: "route_not_found" | SELECT sum(bytes_sent + bytes_received) AS total_bytes

クライアントの Referer ヘッダーを Cloud-native API Gateway のリクエストログに追加する方法

Referer ヘッダーは、デフォルトではゲートウェイのアクセスログに記録されません。これをキャプチャするには、ゲートウェイコンソールでログ配信機能を有効にし、カスタムヘッダーのマッチングルールを設定して、Referer をログ出力のカスタムヘッダーフィールドとして含めてください。

ログ配信機能の詳細については、「ゲートウェイのログ配信を有効にする」をご参照ください。