すべてのプロダクト
Search

このプロダクト

    API Gateway:よくある質問

    ドキュメントセンター

    API Gateway:よくある質問

    最終更新日:Jun 26, 2026

    このトピックでは、Cloud-native API Gateway に関するよくある質問 (FAQ) に回答します。

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

    はい。

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

    はい。

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

    説明

    デフォルトでは、Spring Boot の組み込み Tomcat は x-forwarded-for ヘッダーから最後の IP アドレスを削除します。これを防ぐには、設定 server.forward-headers-strategy=none を Spring Boot アプリケーションに追加します。

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

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

    これを解決するには、ゲートウェイインスタンスの [概要] ページに移動して Security Group Authorizations タブをクリックし、Add Security Group Rule をクリックしてセキュリティグループ設定を追加します。 ゲートウェイは 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 クラスターのみを追加できます。異なる VPC からのサービスソースの追加はサポートされていません。

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

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

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

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

    • UpstreamIdleTimeout を変更すると、アップストリーム接続が切断され、再接続されます。

    • DownstreamIdleTimeout を変更すると、ダウンストリーム接続が切断され、再接続されます。

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

    ヘルスチェックステータスの異常は、いくつかの問題を示している可能性があります。

    • 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 証明書も更新されているか確認してください。ベストプラクティスとして、HTTPS 証明書は 1 か所でのみ設定してください。ゲートウェイのアップストリームに DCDN または WAF がデプロイされている場合、HTTPS は DCDN または WAF でのみ設定し、ゲートウェイはバックトゥオリジンリクエストに 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 アクセスモードを使用している場合は、対応するドメインの設定を変更します。 [Web サイト情報の入力] の手順で、[オリジン 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 で示されます。 これは多くの場合、バックエンドサービスの接続 idle timeout が、ゲートウェイの 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